Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 02:52
    aarlt edited #7468
  • 02:49
    aarlt edited #7468
  • 02:48
    aarlt edited #7468
  • 02:46
    aarlt edited #7468
  • Sep 22 23:06
    aarlt synchronize #7358
  • Sep 22 22:37
    aarlt synchronize #7358
  • Sep 22 22:05
    aarlt synchronize #7358
  • Sep 22 21:39
    aarlt synchronize #7358
  • Sep 22 21:30
    aarlt commented #7464
  • Sep 22 21:25
    aarlt opened #7468
  • Sep 21 20:36
    theStack commented #7467
  • Sep 21 19:12
    theStack opened #7467
  • Sep 21 18:15
    krzkaczor commented #380
  • Sep 21 18:15
    krzkaczor commented #380
  • Sep 20 19:31
    erak edited #383
  • Sep 20 19:30
    erak edited #383
  • Sep 20 19:28
    erak commented #7462
  • Sep 20 19:25
    erak labeled #7350
  • Sep 20 19:23
    erak ready_for_review #7350
  • Sep 20 19:22
    erak edited #7462
Erik K
@erak
Because I think that we would have changed that particular test whenever something that affected gas costs was merged to develop_060
Leonardo
@leonardoalt
yea I think it is related
you could check what the metadata bytecode is, and see how many zeroes diff
Erik K
@erak
Ok, I will check
Erik K
@erak
@leonardoalt The encoder appends the version at the end of the CBOR metadata. For 0.5.12 the last bytes are ...00 05 0c 00 33 and for 0.6.0 of course ..00 06 00 00 33. It differs on several other bytes, but that should be the hashed contract metadata that has a different version number in it.
Leonardo
@leonardoalt
@erak the difference in gas is exactly 64, which is also the difference between sstoring 0 vs nonzero (afaik), so I think it's ok!
Erik K
@erak
Ah, true! That makes a lot of sense. Should be 5000 for SSTORE instead of 20000. How does this translate to the actual result again?
I'll fix the remaining test failure now
Erik K
@erak
@leonardoalt Tests are finally passing on ethereum/solc-js#383
Question is, if we want to merge that one to master_060 or not.
Leonardo
@leonardoalt
@erak I was about to ask you what the sequence there is
which PR goes before which PR
Sana Fatima
@SanaFatima17_twitter
Hi all...I declared some address in two different roles X, Y using Roles.sol....now I want to inherit those roles in another smart contract, with the addresses that I input to those roles in 1st contract..How can I do this?
Erik K
@erak
@leonardoalt ethereum/solidity#7462 should go before ethereum/solc-js#383
Wait, it doesn't matter.
Leonardo
@leonardoalt
I guess we can talk about all that during the call on Monday
Erik K
@erak
Great!
Leonardo
@leonardoalt
I couldn't wrap my head around all the PR/tests dependencies
Erik K
@erak
Yeah, I had to work through it as well ;-)
Alex Beregszaszi
@axic
I’d pretty much prefer to move out the language dependent tests from solc-js
It should only be really about binding tests
Leonardo
@leonardoalt
@axic would we need to keep the 040 and 050 contracts?
for these tests?
Alex Beregszaszi
@axic
For this particular test I don’t think so as it tests newer compilers, but as long as its in solc-js I’d say it should keep all, because solc-js works with all compilers.
Erik K
@erak
@axic That would it easier since we would not have the dependency on the contracts in solc-js. We could easily move them to Solidity's compilation tests. The question is, can the current contracts in solc-js be language independent? AFAICT, it's mostly about bytecode comparison and as you said, bindings
Alex Beregszaszi
@axic
The non-determinisim issue exhibited by the DAO was a bug in the compiler and not solc-js.
Erik K
@erak
Ah, ok. Now I remember what these tests we about
Alex Beregszaszi
@axic

The question is, can the current contracts in solc-js be language independent?

The only thing the bindings need to tests are:

  • smoke compilation tests
  • imports
  • and now basic smt roundtrip

These can be written in a way that they would hardly require syntax updates (but definitely not to the extent the DAO could/would in the future).

Erik K
@erak
Sounds good. Then we would only need to move the determinism test over to Solidity (if not already there)
Alex Beregszaszi
@axic
They aren’t yet. A couple of months ago I started doing it but was interrupted by something and didn’t finish it, haha :)
Also it is debatable the DAO tests can still be used to guard against that old non-determinism issue :wink: (after it has been modified so many times)
Erik K
@erak
Ok, that would need me to take a deeper look in order to have an opinion on that ;-)
Alex Beregszaszi
@axic
I think it was about AST nodes not having a deterministic identifier, but depending on the hash implementation in libstdc/compiler.
Leonardo
@leonardoalt

and now basic smt roundtrip

I think there are tests for the --standard-json double run, and my current PR also adds tests for the callback case (that don't need a solver, just fake one)

These can be written in a way that they would hardly require syntax updates

Yea this would be nice. A bunch of one line contracts that test all the bindings

Erik K
@erak
I'm also in favor of that
Erik K
@erak
Talking about all that, @axic do you think we need a separate master_060 branch in solc-js. For now, I updated the solc version switch with https://github.com/ethereum/solc-js/pull/383/, which should also work with older compilers. Right now, I don't see a particular reason to have that separated.
Alex Beregszaszi
@axic
btw #4548 was the original issue for this
Actually as long as it is in solc-js I think we should keep all versions
Erik K
@erak
Ok!
Alex Beregszaszi
@axic
When we discussed the SMT callback with @leonardoalt yesterday I’ve mentioned another issue I ran into with solc-rust. Rust doesn’t support closures with C-style argument passing (i.e. “extern C”) so there’s no way to make it work without some global variables. Unless we would add an opaque context to libsolc which would be passed down to the callbacks. Any opinions?
StackenBotten
@stackenbotten
❌ Nightly job t_ems_external_gnosis failed on develop. Please see https://circleci.com/gh/ethereum/solidity/181183 for details.
StackenBotten
@stackenbotten
✅ Nightly job t_ems_external_zeppelin succeeded on develop. Please see https://circleci.com/gh/ethereum/solidity/181182 for details.
StackenBotten
@stackenbotten
✅ Nightly job t_ems_external_colony succeeded on develop. Please see https://circleci.com/gh/ethereum/solidity/181181 for details.
StackenBotten
@stackenbotten
❌ Nightly job t_ems_external_gnosis failed on develop. Please see https://circleci.com/gh/ethereum/solidity/181206 for details.
StackenBotten
@stackenbotten
✅ Nightly job t_ems_external_zeppelin succeeded on develop. Please see https://circleci.com/gh/ethereum/solidity/181205 for details.
StackenBotten
@stackenbotten
✅ Nightly job t_ems_external_colony succeeded on develop. Please see https://circleci.com/gh/ethereum/solidity/181207 for details.
StackenBotten
@stackenbotten
✅ Nightly job t_ems_external_gnosis succeeded on develop. Please see https://circleci.com/gh/ethereum/solidity/181303 for details.
StackenBotten
@stackenbotten
✅ Nightly job t_ems_external_zeppelin succeeded on develop. Please see https://circleci.com/gh/ethereum/solidity/181301 for details.
StackenBotten
@stackenbotten
✅ Nightly job t_ems_external_colony succeeded on develop. Please see https://circleci.com/gh/ethereum/solidity/181302 for details.