[WIP] Allow constants access through contract names

[kseo]

Fixes #1290.

[chriseth]

Thanks, that's a very good start!

[kseo]

@chriseth What other places do I need to change besides TypeType::nativeMembers?

[axic]

@kseo you could add test cases first and see what is not working and/or what was broken by the change and track it down from there

[axic]

At the minimum this needs tests and changelog entry.

[axic]

Since constant can contain expressions (which are copied and evaluated a the place they are used) and refer to other constants it probably makes sense to have a complex test case, such as:

contract C {
  uint constant a = 33 * b + 4; // can also mix keccak256(b) into this
  uint constant b = 44;
}

contract D {
  uint constant b = 66;
  function f() returns (uint) {
    return C.a;
  }
}

The goal here is to ensure that b is looked up from the correct contract when evaluating the constant expression.

[axic]

This reminds me (it is not strictly related to this PR), but we could add tests for storage constant and memory constant.

PR updated.

[axic]

@chriseth this needs to be reviewed

[chriseth]

Please add a test for

• cross-contract cycle checks

[chriseth]

Are there any other weird cases we have to test? Is it somehow possible to use super or this in that context?

[chriseth]

Is it possible to access constants via super? If yes, does that work correctly if that constant is accessed from another contract?

[ekpyron]

Access via super is not allowed so far - I think it'd be better to have to use the name of the base explicitly instead. I can change that, though, if you think otherwise. In any case I added a test (for now with the expectation that access through super is not possible).

[ekpyron]

@chriseth I added some more test cases, but indeed cross-contract cycle detection does not currently work. Since this PR was not originally planned for 0.4.22, I suggest that I first continue to review the other PRs and then get back to this, unless you definitely want this in the current release.

[ekpyron]

Cross contract cycle detection should work now and this is ready for review.

PR updated.

[chriseth]

Please add a test case for

contract A {
    function f() pure returns (uint) { return 1; }
}
contract B is A {
    uint constant x = super.f();
}
contract Y {
    function f() pure returns (uint) { return 2; }
    
}
contract X is Y {
    uint constant a = B.x;
}

and check what the value of a is.

[chriseth]

Note that we currently still allow non-compile-time-constant constants - we only add a warning. Because of that I would say this is too dangerous to include in the release.

[chriseth]

Did we test accessing address x = address(this) from different contracts?

[ekpyron]

I updated the PR to include @chriseth's test (before the latest changes the test contract would cause a fatal compiler error; now the expected value of a is 1).

However:

• In the meantime I agree that this PR should be postponed as long as non-compile-time-constant constants are possible.
• One might actually argue that in the new cross_contract_constants_super_call test the value of a should be 2 and not 1, so this has to be discussed. In general I think it may be a good idea to postpone this PR until e.g. Constant expression evaluation at compile time #3157 is settled.

[axic]

@ekpyron why would you argue it would be reasonable to have this return 2?

[ekpyron]

@axic I would definitely expect 1 here, but then I might also expect

solidity/test/libsolidity/SolidityEndToEndTest.cpp

Line 3027 in a244f1a

BOOST_AUTO_TEST_CASE(super)

to either result in 11 or 13 and not in 15... in that test super traverses the entire inheritance graph of the context from which it is first invoked - if I think about it that way, than I might expect it to prefer X's context, even if it occurs in B...

I would still want the result here to be 1, but I thought it might be good to discuss this wrt consistency issues anyways.

[axic]

What is the status of this? I am kind of lost.

[ekpyron]

@axic The current status of this is "postponed". We could think about re-evaluating this now, though.

[chriseth]

Closing because it got stale and there are still discussions about the underlying feature.