Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Errors when comparing types #4635

Closed
nventuro opened this issue Mar 25, 2024 · 0 comments · Fixed by #4648
Closed

Errors when comparing types #4635

nventuro opened this issue Mar 25, 2024 · 0 comments · Fixed by #4648
Labels
bug Something isn't working

Comments

@nventuro
Copy link
Contributor

nventuro commented Mar 25, 2024

Aim

I'm running into multiple issues related to type inference. This is one of them, but I'm not entirely sure how to title this report because I don't really know what might be the underlying issue. I produced a small exaple that triggers it instead.

Ultimately this errors out with error: Types in a binary operation should match, but found T and T, which just seems wrong.

Expected Behavior

Forgive the boiler-plate, hopefully it won't be too bad. It's just some standard utils for dealing with Fields and arrays as is done in the kernel circuits.

trait FromField {
    fn from_field(field: Field) -> Self;
}

impl FromField for Field {
    fn from_field(value: Field) -> Self {
        value
    }
}

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

global AZTEC_ADDRESS_LENGTH = 1;

struct AztecAddress {
    inner : Field
}

impl FromField for AztecAddress {
    fn from_field(value: Field) -> Self {
        Self { inner: value }
    }
}

impl Deserialize<AZTEC_ADDRESS_LENGTH> for AztecAddress {
    fn deserialize(fields: [Field; AZTEC_ADDRESS_LENGTH]) -> Self {
        AztecAddress::from_field(fields[0])
    }
}

// Custom code

struct MyStruct<T> {
    a: T
}

impl<T> Deserialize<1> for MyStruct<T> {
    fn deserialize(fields: [Field; 1]) -> Self where T: FromField {
        Self{ a: FromField::from_field(fields[0]) }
    }
}

fn main() {
    let fields = [5; 1];
    let foo = MyStruct::deserialize(fields); // Note I don't specify T here (the type of `foo.a`)

    let bar = AztecAddress { inner: 5 };

    // Here `T` is apparently inferred to be `AztecAddress`, presumably because of the comparison.
    assert(foo.a == bar);
}

This errors out with:

error: Types in a binary operation should match, but found AztecAddress and AztecAddress
   ┌─ /home/nventuro/type_error/src/main.nr:49:12
   │
49 │     assert(foo.a == bar);
   │            ------------

which feels a bit non-sensical.

Bug

Honestly I'm not sure if the issue is my code, the error message or the compiler, but something does seem off here.

Installation Method

Compiled from source

Nargo Version

nargo version = 0.25.0 noirc version = 0.25.0+7deceac68414a6c24f2c4f9ecdd36ad6ac9752e3 (git version hash: 7deceac68414a6c24f2c4f9ecdd36ad6ac9752e3, is dirty: false)

@nventuro nventuro added the bug Something isn't working label Mar 25, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Mar 25, 2024
github-merge-queue bot pushed a commit that referenced this issue Mar 29, 2024
…4648)

# Description

## Problem\*

Resolves #4635 
Resolves #4502

## Summary\*

This was more difficult to fix than it originally seemed. The main issue
was between interactions with unbound type variables, type aliases, type
rules for operators, and operator traits.

Removing the "infer unbound type variables to be numeric" rule on
operators causes a lot of stdlib code to break where it'd be
unreasonable to have type annotations. This caused unbound type
variables to be bound to the first object type whose impl it was checked
against when calling verify trait impl.

I eventually settled on just delaying the verify trait impl check for
operators until the end of a function when more types are known.

## Additional Context



## Documentation\*

Check one:
- [x] No documentation needed.
- [ ] Documentation included in this PR.
- [ ] **[For Experimental Features]** Documentation to be submitted in a
separate PR.

# PR Checklist\*

- [x] I have tested the changes locally.
- [x] I have formatted the changes with [Prettier](https://prettier.io/)
and/or `cargo fmt` on default settings.
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in Noir Mar 29, 2024
TomAFrench pushed a commit that referenced this issue Apr 3, 2024
…4648)

# Description

## Problem\*

Resolves #4635 
Resolves #4502

## Summary\*

This was more difficult to fix than it originally seemed. The main issue
was between interactions with unbound type variables, type aliases, type
rules for operators, and operator traits.

Removing the "infer unbound type variables to be numeric" rule on
operators causes a lot of stdlib code to break where it'd be
unreasonable to have type annotations. This caused unbound type
variables to be bound to the first object type whose impl it was checked
against when calling verify trait impl.

I eventually settled on just delaying the verify trait impl check for
operators until the end of a function when more types are known.

## Additional Context



## Documentation\*

Check one:
- [x] No documentation needed.
- [ ] Documentation included in this PR.
- [ ] **[For Experimental Features]** Documentation to be submitted in a
separate PR.

# PR Checklist\*

- [x] I have tested the changes locally.
- [x] I have formatted the changes with [Prettier](https://prettier.io/)
and/or `cargo fmt` on default settings.
nventuro added a commit to AztecProtocol/aztec-packages that referenced this issue Apr 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant