Conversation
aakoshh
changed the base branch from
master
to
af/10864-assoc-and-gen-same-name
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
⚠️ Performance Alert ⚠️
Possible performance regression was detected for benchmark 'Test Suite Duration'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.
| Benchmark suite | Current: 897b83e | Previous: 8592c53 | Ratio |
|---|---|---|---|
test_report_zkpassport_noir_rsa_ |
1 s |
0 s |
+∞ |
This comment was automatically generated by workflow using github-action-benchmark.
CC: @TomAFrench
There was a problem hiding this comment.
⚠️ Performance Alert ⚠️
Possible performance regression was detected for benchmark 'Brillig Execution Time'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.
| Benchmark suite | Current: 897b83e | Previous: 8592c53 | Ratio |
|---|---|---|---|
rollup-checkpoint-merge |
0.002 s |
0.001 s |
2 |
This comment was automatically generated by workflow using github-action-benchmark.
CC: @TomAFrench
compiler/noirc_frontend/src/tests/traits/trait_associated_items.rs
Outdated
Show resolved
Hide resolved
aakoshh
force-pushed
the
af/11347-type-eq-unbound-check-name
branch
from
32059a4 to
f3bcd40
Compare
|
We should likely remove this equality check when checking traits entirely eventually but it doesn't need to be this PR |
2 participants
Description
Problem
Resolves #11347
Summary
Changes the
PartialEqimplementation forTypeto compare thenameofNamedGenerics when both are unbound and implicitly added.Additional Context
I read the explanation in #8184 and seemed to revolve around creating named generics for the ordered generics of a trait that appears in the type bound. I'm not sure if by considering implicitly added variables different we will be rejecting something that should compile, but as it is today, it presents a soundness bug, where there are no comparisons on two generics, so we can pass invalid data to functions as long as they expect generics and the source is generic as well. Being a bit more conservative doesn't seem to hurt any tests.
Note that this builds on #11346 where the named generics were changed to be named e.g.
<A as Eggs>::Item, but without that PR their name would just beItem, in which case the test I added here would still consider them equivalent to any other type with the same name.Also noting that the ticket showcases ordered generics, but here we have associated types.
User Documentation
Check one:
PR Checklist
cargo fmton default settings.