[BUG] Adding a dependency in Nargo.toml breaks compilation

[xorsal]

What are you trying to do?

I'm integrating a protocol but when I add dependency in the Nargo.toml file I get the following error at compilation:

error: Attempted to fetch storage size, but SharedMutable<HTLC_Public, 180, Context> does not implement the Storage trait
    ┌─ /nargo/github.com/AztecProtocol/aztec-packages/v1.1.2/noir-projects/aztec-nr/aztec/src/macros/utils.nr:282:9
    │
282 │         typ.implements(quote { crate::state_vars::Storage<$storage_size> }.as_trait_constraint()),
    │         ----------------------------------------------------------------------------------------- Assertion failed
    │
    = Call stack:
      1. src/nr/train_bridge/src/main.nr:20:5
      2. /nargo/github.com/AztecProtocol/aztec-packages/v1.1.2/noir-projects/aztec-nr/aztec/src/macros/storage.nr:50:13
      3. /nargo/github.com/AztecProtocol/aztec-packages/v1.1.2/noir-projects/aztec-nr/aztec/src/macros/storage.nr:150:13
      4. /nargo/github.com/AztecProtocol/aztec-packages/v1.1.2/noir-projects/aztec-nr/aztec/src/macros/storage.nr:158:19

Code Reference

#[aztec::macros::aztec]
pub contract Train {
    use aztec::{
        macros::{functions::{initializer, public}, storage::storage},
        protocol_types::{address::AztecAddress, traits::{Deserialize, Packable, Serialize}},
        state_vars::{map::Map, SharedMutable},
    };

    #[derive(Eq, Packable, Serialize, Deserialize)]
    pub struct HTLC_Public {
        src_receiver: AztecAddress,
        amount: u128,
    }

    #[public]
    #[initializer]
    fn constructor() {}

    #[storage]
    struct Storage<Context> {
        contracts_public: Map<Field, SharedMutable<HTLC_Public, 180, Context>, Context>,
    }
}

I have a reference repo: https://github.com/xorsal/train-example/tree/feat/minimal.
The main branch also have the same problem but in feat/minimal I removed all references to Token, and it seems the mere inclusion of the dependency is enough to break compilation.

Aztec Version

1.1.2

OS

Linux

Browser (if relevant)

No response

Node Version

22

Additional Context

No response

[alejoamiras]

This was triaged and fixed, right @xorsal?

[asterite]

I managed to reduce this:

pub trait Storage<let N: u32> {}

pub struct Struct<T> {}

pub struct WithHash<T, let M: u32> {}

pub trait Packable<let O: u32> {}

impl<T, let N: u32> Storage<N> for Struct<T>
where
    WithHash<T, _>: Packable<N>,
{}

impl<T, let N: u32> Packable<N> for WithHash<T, N>
where
    T: Packable<N>,
{}

pub struct One {}

impl Packable<1> for One {}

pub struct Two {}

impl Packable<2> for Two {}

#[comptime_stuff]
comptime fn comptime_stuff(_: FunctionDefinition) {
    let _typ = quote { Struct<One> }.as_type();
    let length = std::meta::typ::fresh_type_variable();
    let _trait = quote { Storage<$length> }.as_trait_constraint();
    // let _implements = _typ.implements(_trait);
}

fn main() {
    bar(Struct::<Two> {});
}

fn bar<T: Storage<N>, let N: u32>(_: T) {}

The above program works. It stops compiling if we uncomment the only commented line (// let _implements = ...). The error is:

error: No matching impl found for `Two: Packable<1>`
   ┌─ src/main.nr:42:5
   │
42 │     bar(Struct::<Two, Field> {});
   │     --- No impl for `Two: Packable<1>`
   │
   = Required by `WithHash<Two, 1>: Packable<_>`
   = Required by `Struct<Two, Field>: Storage<_>`

error: Type annotation needed
   ┌─ src/main.nr:42:5
   │
42 │     bar(Struct::<Two, Field> {});
   │     --- Could not determine the value of the generic argument `N` declared on the function `bar`

I still don't know why it happens but my guess is:

1. There's a where clause that uses _: where WithHash<T, _>: Packable<N>. That for example isn't allowed in Rust and I'm almost sure there must be a good reason for that.
2. When we do typ.implements(trait) we lookup the trait implementation and commit any bindings. That's why length gets the type after an implementation was found. What I think is happening is that that _ gets bound to 1 in that call, then it's fixed to 1 and can't be bound to something else... but this is just a guess!

If I change the code to this:

impl<T, Context, let N: u32, let M: u32> Storage<N> for Struct<T, Context>
where
    WithHash<T, M>: Packable<N>,
{}

then it compiles fine in both cases. HOWEVER, that's also invalid Rust code because M doesn't appear in the impl trait (Storage) or type (Struct) because otherwise M can be anything (it's not constrained).

I'll investigate a bit more if what I think is the issue is actually the issue, but I'm thinking that going forward:

1. We should disallow _ in where clauses
2. We should error if a generic in an impl doesn't appear in either the type or trait.

I think I tried to implement 2 in the past but in the end didn't proceed with that because it would break a lot of things. Things in Aztec-Packages would probably need to be implemented in a different way. Likely associated types must be used here, though I don't know what we'd pass for the second generic of WithHash.

[asterite]

To expand on the above:

• when in the original code we imported a library, that library had the implements call and made that change that later produced the error
• if we remove a field from the HTLC_Public struct it becomes Packable<1> instead of Packable<2> and then things match
  (for an explanation of why the above cases made it compile or not)

[asterite]

Another, small repro code:

pub trait Storage<let N: u32> {}

pub struct Struct<T> {}

pub struct WithHash<T, let M: u32> {}

pub trait Packable<let O: u32> {}

impl<T, let N: u32> Storage<N> for Struct<T>
where
    WithHash<T, _>: Packable<N>,
{}

impl<T, let N: u32> Packable<N> for WithHash<T, N>
where
    T: Packable<N>,
{}

impl Packable<1> for Field {}
impl Packable<2> for i32 {}

fn main() {
    // bar(Struct::<Field> {});
    bar(Struct::<i32> {});
}

fn bar<T: Storage<N>, let N: u32>(_: T) {}

No need for comptime code. The code above compiles fine but when we uncomment the first bar call then it fails, for the same reason explained above.

[TomAFrench]

I'll investigate a bit more if what I think is the issue is actually the issue, but I'm thinking that going forward:

We should disallow _ in where clauses
We should error if a generic in an impl doesn't appear in either the type or trait.

Yep, this looks sensible. We've definitely got some holes in trait resolution with generics which we need to patch up.

[xorsal]

I bumped to v2.0.3 hoping for noir-lang/noir#9870 to be included and this issue resolved, but unfortunately the error remains the same.

workflow run: https://github.com/xorsal/train-example/actions/runs/18009910693/job/51239479879#step:10:990

[alejoamiras]

@xorsal still an issue? T_T

[xorsal]

Ahh thanks for the reminder! I talked with Nerses after the last ecosystem call, and I remembered we had this blocker, so I tried again and now it seems to compile :D

Open this PR with the required changes: TrainProtocol/contracts#5. We can close this, or wait until Nerses/Train team confirms it.

[alejoamiras]

I think we can close since the issue is solved! TY sir!