Method calls don't apply trait constraints

[sirasistant]

Aim

Doing code like this:

use dep::std::option::Option;

trait MySerialize<N> {
    fn serialize(self) -> [Field; N];
}

trait MyDeserialize<N> {
    fn deserialize(fields: [Field; N]) -> Self;
}

impl MySerialize<1> for Field {
    fn serialize(self) -> [Field; 1] {
        [self]
    }
}

impl MyDeserialize<1> for Field {
    fn deserialize(fields: [Field; 1]) -> Self {
        fields[0]
    }
}

#[oracle(storageRead)]
fn storage_read_oracle<N>(_storage_slot: Field, _number_of_elements: Field) -> [Field; N] {}

unconstrained fn storage_read_oracle_wrapper<N>(_storage_slot: Field) -> [Field; N] {
    storage_read_oracle(_storage_slot, N)
}

pub fn storage_read<N>(storage_slot: Field) -> [Field; N] {
    storage_read_oracle_wrapper(storage_slot)
}

struct PublicState<T> {
    storage_slot: Field,
}

impl<T> PublicState<T> {
    pub fn new(
        storage_slot: Field,
    ) -> Self {
        assert(storage_slot != 0, "Storage slot 0 not allowed. Storage slots must start from 1.");
        PublicState {
            storage_slot,
        }
    }
    pub fn read<T_SERIALIZED_LEN>(self) -> T where T: MyDeserialize<T_SERIALIZED_LEN> {
        let fields: [Field; T_SERIALIZED_LEN] = storage_read(self.storage_slot);
        T::deserialize(fields)
    }
}

fn main(value: Field) {
    let ps: PublicState<Field> = PublicState::new(27);

    assert(ps.read() == value);
}

Expected Behavior

Should compile!

Bug

The application panicked (crashed).
Message:  assertion failed: `(left == right)`
  left: `2`,
 right: `1`
Location: compiler/noirc_evaluator/src/ssa/opt/inlining.rs:420

To Reproduce

Installation Method

None

Nargo Version

No response

Additional Context

The workaround consists in passing an unused sample array with the length:

use dep::aztec::context::{Context};
use dep::std::option::Option;

trait MySerialize<N> {
    fn serialize(self) -> [Field; N];
}

trait MyDeserialize<N> {
    fn deserialize(fields: [Field; N]) -> Self;
    // Such a hackkity hack!!!!
    fn empty() -> [Field; N];
}

impl MySerialize<1> for Field {
    fn serialize(self) -> [Field; 1] {
        [self]
    }
}

impl MyDeserialize<1> for Field {
    fn deserialize(fields: [Field; 1]) -> Self {
        fields[0]
    }

    fn empty() -> [Field; 1] {
        dep::std::unsafe::zeroed()
    }
}

#[oracle(storageRead)]
fn storage_read_oracle<N>(_storage_slot: Field, _number_of_elements: Field) -> [Field; N] {}

unconstrained fn storage_read_oracle_wrapper<N>(_storage_slot: Field, _sample: [Field; N]) -> [Field; N] {
    storage_read_oracle(_storage_slot, N)
}

pub fn storage_read<N>(storage_slot: Field, _sample: [Field; N]) -> [Field; N] {
    storage_read_oracle_wrapper(storage_slot, _sample)
}

struct PublicState<T> {
    storage_slot: Field,
}

impl<T> PublicState<T> {
    pub fn new(
        storage_slot: Field,
    ) -> Self {
        assert(storage_slot != 0, "Storage slot 0 not allowed. Storage slots must start from 1.");
        PublicState {
            storage_slot,
        }
    }
    pub fn read<T_SERIALIZED_LEN>(self) -> T where T: MyDeserialize<T_SERIALIZED_LEN> {
        let fields: [Field; T_SERIALIZED_LEN] = storage_read(self.storage_slot, T::empty());
        T::deserialize(fields)
    }
}

fn main(value: Field) {
    let ps: PublicState<Field> = PublicState::new(27);

    assert(ps.read() == value);
}

The ugly part of this workaround is that it requires to modify the serialize trait, which would affect users ):

Would you like to submit a PR for this Issue?

No

Support Needs

No response

[jfecher]

#[oracle(storageRead)]
fn storage_read_oracle<N>(_storage_slot: Field, _number_of_elements: Field) -> [Field; N] {}

Glancing at this line, I'm guessing this certainly affects the problem. How would an oracle return a field of any size N for the same inputs? From the signature alone, N is independent all other parameters, so the compiler can instantiate it to anything it needs.

We should fix this so that it doesn't panic, but I think a proper fix would make this a compiler error.

[jfecher]

After looking in-depth more at the program, since the result of that function is constrained with the type annotation in the read function, this particular use should be fine. It looks like there's a bug during monomorphization since as far as I can tell type checking is correct here.

During monomorphization, the function reference to storage_read is being given an incorrect type, while the later call to T::deserialize still expects an array type. I'm not sure the reason for this discrepancy so far since during type checking these types are the same.

[jfecher]

I've found the core issue. The contents of read are correct, the bug is when read is called within main:

    assert(ps.read() == value);

On this line, the compiler is never actually applying the T: MyDeserialize<T_SERIALIZED_LEN> trait constraint from read.