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

Incorrect private warning #7039

Closed
jfecher opened this issue Jan 13, 2025 · 1 comment · Fixed by #7026
Closed

Incorrect private warning #7039

jfecher opened this issue Jan 13, 2025 · 1 comment · Fixed by #7026
Labels
bug Something isn't working

Comments

@jfecher
Copy link
Contributor

jfecher commented Jan 13, 2025

Aim

In the associated_types_implicit example:

trait Foo {
    type Bar;

    fn foo(self) -> Self::Bar;
}

impl Foo for u64 {
    type Bar = u8;

    fn foo(self) -> Self::Bar {
        self as u8
    }
}

fn main() {
    let three: u64 = 3;
    call_foo(three);

    let x: Option<Option<u64>> = Option::some(Option::some(0));
    let x_foo = x.foo(); // private warning here
    assert_eq(x_foo, x_foo);
    assert_eq(x.foo(), 0 as u8); // private warning here
}

fn call_foo<T>(x: T) where
    T: Foo,
    <T as Foo>::Bar: Eq
{
    let y = x.foo();
    assert_eq(y, y);
}

impl<T> Foo for Option<T> where
    T: Foo,
    <T as Foo>::Bar: Eq
{
    type Bar = <T as Foo>::Bar;

    fn foo(self) -> Self::Bar {
        self.unwrap().foo()
    }
}

Expected Behavior

The program to compile without warnings

Bug

We get two warnings, one for each x.foo() call in main that read: foo is private and not visible from the current module despite foo and Foo being defined in the same module main is in.

To Reproduce

Workaround

None

Workaround Description

No response

Additional Context

No response

Project Impact

None

Blocker Context

No response

Nargo Version

No response

NoirJS Version

No response

Proving Backend Tooling & Version

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response

@jfecher jfecher added the bug Something isn't working label Jan 13, 2025
@jfecher
Copy link
Contributor Author

jfecher commented Jan 13, 2025

I think this is blocking #7026 currently due to a CI check causing a test to fail if there are any warnings emitted.

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
None yet
Development

Successfully merging a pull request may close this issue.

1 participant