Function selectors accessed via contract variables are not considered constant

[cameel]

Description

A function selector accessed through this is considered compile-time constant, even though this itself is not (the address won't change at runtime but is not known at compilation time). This makes sense, because functions themselves are constant and do not depend on the address. However, even though the same reasoning applies to other contract variables, we do not consider their selectors constant.

This does work for constant contract variables though, which indicates that the check is based on the constness of the variable rather than the function and is wrong.

Environment

• Compiler version: 0.8.31

Steps to Reproduce

contract C {
    function f() external {}
}

contract D is C {
    C cvar            = C(address(0));
    C constant cconst = C(address(0));

    bytes4 constant s1 = C(address(0)).f.selector; // OK
    bytes4 constant s2 = this.f.selector;          // OK
    bytes4 constant s3 = cvar.f.selector;          // Error: Initial value for constant variable has to be compile-time constant.
    bytes4 constant s4 = cconst.f.selector;        // OK
}

There is no good reason for s3 to be invalid if both s2 and s4 are accepted.

[cameel]

A related issue is that selectors on constant function pointers are not constant either:

contract C {
    C c;
    function f() external {}
    function() external varPtr = c.f;
    function() external constant constPtr = c.f; // Error: Initial value for constant variable has to be compile-time constant.

    bytes4 constant s1 = varPtr.selector;   // Error: Initial value for constant variable has to be compile-time constant.
    bytes4 constant s2 = constPtr.selector; // Error: Initial value for constant variable has to be compile-time constant.
}

For consistency it would be better to change this so that s2 compiles. Though note that constant function pointers are unusable in practice (#16339), so constPtr it will still be an error.

[cameel]

Also note that the .address member has a similar issue (#16339 (comment)), but again, fixing it would require solving #16339 first.

[rodiazet]

Why cannot we assume that selector is always constant compile-time variable? nativeMembers for FunctionType make it available only for public or external function. It should be known in compile-time if only function declaration is know. Which is also assured by the same fragment of the code. This would mean that we do not have to look at the parent expression in parent.foo.selector to decide on the selector purity.

For errors and events we do it a little differently. We do allow access them only via a type, not an instance of a contract where their are defined.

[cameel]

Because it's not always. It does depend on the parent expression. It the parent expression is a function then sure, there's no non-constant case. But when it's a function pointer (as my example above shows), it depends on whether that pointer itself is constant or not.