Fix supertrait associated type unsoundness #126090
Conversation
|
@bors try |
rustbot
added
S-waiting-on-review
…unsoundness, r=<try> Fix supertrait associated type unsoundness This is built on top of rust-lang#122804 though that's really not related, it's just easier to make this modification with the changes to the object safety code that I did in that PR. The only thing is that PR may make this unsoundness slightly easier to abuse, since there are more positions that allow self-associated-types. This PR only looks for supertrait associated types *without* normalizing. I'm gonna crater this initially -- preferably we don't need to normalize unless there's a lot of breakage. I assume that most people are writing `Self::Assoc` so they don't really care about the trait ref being normalized, so somewhat tempted to believe that this will just work out and we can extend it later if needed. r? lcnr
| self.tcx.erase_regions( | ||
| self.tcx.instantiate_bound_regions_with_erased(trait_ref), | ||
| ) |
There was a problem hiding this comment.
This sucks lol. but I don't really care about regions here
This comment has been minimized.
This comment has been minimized.
|
☀️ Try build successful - checks-actions |
|
@craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
compiler-errors
added
needs-fcp
compiler-errors
force-pushed
the
supertrait-assoc-ty-unsoundness
branch
from
3c44574
to
ec21145
Compare
|
This is ready. See description. Needs fcp. |
What?
Object safety allows us to name
Self::Assocassociated types in certain positions if they come from our trait or one of our supertraits. When this check was implemented, I think it failed to consider that supertraits can have different args, and it was only checking def-id equality.This is problematic, since we can sneak different implementations in by implementing
Supertrait<NotActuallyTheSupertraitSubsts>for adyntype. This can be used to implement an unsound transmute function. See the committed test.How do we fix it?
We consider the whole trait ref when checking for supertraits. Right now, this is implemented using equality without normalization. We erase regions since those don't affect trait selection.
This is a limitation that could theoretically affect code that should be accepted, but doesn't matter in practice -- there are 0 crater regression. We could make this check stronger, but I would be worried about cycle issues. I assume that most people are writing
Self::Assocso they don't really care about the trait ref being normalized.What is up w the stacked commit
This is built on top of #122804 though that's really not related, it's just easier to make this modification with the changes to the object safety code that I did in that PR. The only thing is that PR may make this unsoundness slightly easier to abuse, since there are more positions that allow self-associated-types -- I am happy to stall that change until this PR merges.
Fixes #126079
r? lcnr