-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
implied bounds from associated types may not actually get implied pt 2. #98543
Copy link
Copy link
Closed
Labels
A-associated-itemsArea: Associated items (types, constants & functions)Area: Associated items (types, constants & functions)A-implied-boundsArea: Implied bounds / inferred outlives-boundsArea: Implied bounds / inferred outlives-boundsC-bugCategory: This is a bug.Category: This is a bug.I-unsoundIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessP-highHigh priorityHigh priorityT-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-associated-itemsArea: Associated items (types, constants & functions)Area: Associated items (types, constants & functions)A-implied-boundsArea: Implied bounds / inferred outlives-boundsArea: Implied bounds / inferred outlives-boundsC-bugCategory: This is a bug.Category: This is a bug.I-unsoundIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessP-highHigh priorityHigh priorityT-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
revives #91068 which has been fixed by only considering implied bounds from projections if they don't normalize while typechecking the function itself
rust/compiler/rustc_borrowck/src/type_check/free_region_relations.rs
Lines 256 to 289 in 7125846
This does not mean that the projection won't normalize when getting called:
The added bound prevents
<&'a &'b () as Trait>::Typefrom getting normalized while borrowcheckingf, as we prefer param candidates over impl candidates. When callingf, we don't have the&'a &'b (): Traitin ourparam_env, so we can now freely use the impl candidate to normalize the projection. The caller therefore doesn't have to prove that&'a &'b ()is well formed, causing unsoundness.I am a bit surprised that the caller doesn't have to prove that the
&'a &'b (): Traitobligation is well formed, which would cause this example to not be unsound. It doesn't remove the general unsoundness here though. Here's an alternative test where that isn't enough: