g internal, the contract has no public interface and thus no code is generated - that would be my gues.
one could argue that there is no function overloading going on because the functions override each other, but I would rather not touch that logic now...
my guess would be that it does overload (not override) lookup and that fails because there are no arguments provided
This seems to be the case. But not due to the lack of arguments. This fails as well:
contract A {
function f(uint, uint) virtual internal {}
function f(uint) virtual internal {}
}
contract B is A {
function h() internal { f; }
}So basically, you can't get a pointer to a function that has multiple overloads? And an overridden function looks a bit like an overload but isn't one and should technically work but currently doesn't?
Do we want to fix it at some point in the future? I could report an issue and leave it for now.
function f(uint[2] calldata x) external pure {
x[1:2]. a;
}.a doesn't exist here
copyForLocation?
TypePointer type = TypeProvider::withLocationIfReference(DataLocation::Storage, &_type);
@chriseth
if you make g internal, the contract has no public interface and thus no code is generated - that would be my gues.
That's not it. If I change the expression to a more complex one it no longer has a declaration, no matter whether the function is public or internal:
contract C {
function p(function() internal foo) internal returns(function() internal) { return foo; }
function f() internal {}
function g() public { (p(f))(); }
}Making a different method public also makes the declaration go away:
contract C {
function f() internal {}
function g() internal { (f)(); }
function h() public {}
}As far as I can tell it happens only if specifically the function containing the expression is public and if the expression consists of function name in parentheses.
It looks to me a as if the (f)() syntax was equivalent to f() in a schrizophrenic way (i.e. some part of code thinks it's the same and sets up its things this way while another one thinks it's an expression).
$ fizzy-wasi lox-repl.wasm
> fun sayHello(name) { print "Hello " + name + "!"; }
> sayHello("Fizzy");
Hello Fizzy!
> ^C
@chriseth will someone refactor the testing infra to support multiple evmc vms (evmone and hera)? If so, I can finish hera to support evmc7.
@axic @chriseth sounds interesting, I would like to work on this ethereum/solidity#8016
FunctionType.declaration() comes from threw me off. The inconsistent behavior was really bugging me so I investigated this and looks like fortunately it was just my wrong assumption, not a bug in the parser. Here's a short PR that removes it: #9032.