entrypoint invalid types check is unable to discriminate against nested scopes in a contract

[Maddiaa0]

Aim

Most aztec contracts define their storage at the top level of a contract e.g:

contract Test {
    struct Storage {
         ...
    }
    
    impl Storage {
        fn init(context: Context) {
            ... // initialise
        }

    }
    
    // rest of contract...
}

Right now we receive the following error:

error: Only sized types may be used in the entry point to a program
   ┌─ /mnt/user-data/sean/docs/sandbox/zybil/contracts/l2/src/main.nr:50:26
   │
50 │         fn init(context: Context) -> pub Self {
   │                          ------- Slices, references, or any type containing them may not be used in main or a contract function
   │

I was able to narrow down the issue to here,

noir/compiler/noirc_frontend/src/hir/resolution/resolver.rs

Line 818 in 2a51cb6

if self.in_contract() {

Where it checks if the method in question is within a contract scope, this returns true in the case above, however it is not an entrypoint, as it is a method nested within a struct.

It should not throw this error.

Expected Behavior

Is should not throw this error

Bug

n/a same as above

This issue was introduced in this pr: #3220

To Reproduce

1. Compile latest noir master with the aztec flag enabled
   noirup -p . -f noirc_compiler/aztec
2. Go to aztec-packages/yarn-project/noir-contracts
3. nargo compile
4. error should appear

Installation Method

None

Nargo Version

No response

Additional Context

No response

Would you like to submit a PR for this Issue?

No

Support Needs

No response

[jfecher]

impl scopes are just the weirdest thing. They define methods in a separate scope but the methods themselves have items visible as if they're defined in the parent scope.

For example, in:

fn main() {}

mod foo {
    fn bar() {
        main();
    }
}

struct T;
impl T {
    fn t() {
        main();
    }
}

We'll get an error that main isn't visible in bar, but it is visible from t. Despite both foo::bar and T::t being placed in conceptually different "modules" from main.

To implement this previously, we just defined and resolved t in its parent module then also linked it in T's module so it can be accessed via T::t. This issue highlights a problem with that approach though - if the parent module is a contract, it will look like t should be a contract method when it was not intended to be.