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

Trait where clause isn't type-checked #6023

Closed
asterite opened this issue Sep 12, 2024 · 2 comments · Fixed by #6325
Closed

Trait where clause isn't type-checked #6023

asterite opened this issue Sep 12, 2024 · 2 comments · Fixed by #6325
Assignees
Labels
bug Something isn't working

Comments

@asterite
Copy link
Collaborator

Aim

This program:

trait Foo<U> where U: Uknown<U> {}

fn main( ) {}

doesn't give an error.

Expected Behavior

The compiler should say that it can't find Unknown.

Bug

The compiler doesn't error.

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

@asterite asterite added the bug Something isn't working label Sep 12, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Sep 12, 2024
@asterite
Copy link
Collaborator Author

@noir-lang/core Actually, it seems a trait's where clause is completely ignored. "Find all references" of NoirTrait.where_clause gives no results (except when it's created from parsing).

@jfecher
Copy link
Contributor

jfecher commented Sep 16, 2024

I didn't know we allowed where clauses in this position at all. Checking these is somewhat similar to trait inheritance (which we also don't support) where we'd need to check/assume it everywhere the trait is used.

@asterite asterite changed the title Trait where clause isn't type-checked until used Trait where clause isn't type-checked Sep 20, 2024
@asterite asterite moved this from 📋 Backlog to 🚧 Blocked in Noir Oct 24, 2024
github-merge-queue bot pushed a commit that referenced this issue Oct 24, 2024
# Description

## Problem

Resolves #6023

## Summary

It turns out that checking a trait's `where` clause is very similar to
checking parent traits: for parent traits the type to check if `Self`,
for where clause it's the specified type. So `trait Foo where Self:
Constraint` is the same as `trait Foo: Constraint`. I thought about
unifying the code to only have a single list of constraints but I don't
know if it's worth it (we could maybe give different errors in one case
or another, though right now the errors are the same).

There's a chance this PR is a breaking change, because when I finished
implementing it one test broke and I had to amend it.

## 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 🚧 Blocked to ✅ Done in Noir Oct 24, 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
Status: ✅ Done
Development

Successfully merging a pull request may close this issue.

2 participants