-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
simplify_type
: don't simplify projections
#92721
Conversation
3106bea
to
7323d0d
Compare
7323d0d
to
13f7edc
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 13f7edc with merge be79c364343564bbcc7f36d4b3d932f2b49f3482... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is a proposed change to your comment-- does this seem right?
@@ -60,29 +60,23 @@ pub enum StripReferences { | |||
No, | |||
} | |||
|
|||
/// Tries to simplify a type by only returning the outermost injective¹ layer, if one exists. | |||
/// Tries to simplify a type by only returning the outermost layer of an inductive type, if one exists. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really know what "inductive" type means here, and I expect other readers won't either =)
/// | ||
/// When using `SimplifyParams::Yes`, we still return a simplified type for params and projections², | ||
/// the reasoning for this can be seen at the places doing this. | ||
/// When using `SimplifyParams::Yes`, we still return a simplified type for params. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if a better name for this would be TreatParamsAsPlaceholders
-- I've been trying to push the "placeholder" terminology for "universally bound free variable".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or something like
enum TreatParams {
AsPlaceholderTypes,
AsBoundTypes,
}
// Returning a simplified for projections can end up being unsound as it would | ||
// stop us from considering not consider non blanket impls for `<_ as Trait>::Assoc` even | ||
// though `_` can be inferred to a concrete type later at which point a concrete impl | ||
// could actually apply. | ||
// | ||
// We could return `Some` here in cases where the input type is fully normalized, but | ||
// I (@lcnr) don't know how to guarantee that. | ||
None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// Returning a simplified for projections can end up being unsound as it would | |
// stop us from considering not consider non blanket impls for `<_ as Trait>::Assoc` even | |
// though `_` can be inferred to a concrete type later at which point a concrete impl | |
// could actually apply. | |
// | |
// We could return `Some` here in cases where the input type is fully normalized, but | |
// I (@lcnr) don't know how to guarantee that. | |
None | |
// Returning a simplified for projections can end up being unsound. Consider this example: | |
// | |
// ```rust | |
// trait Foo { } | |
// impl Foo for u32 { } | |
// | |
// trait Bar { type Assoc; } | |
// impl Bar for f32 { type Assoc = u32; } | |
// impl Bar for f64 { type Assoc = u64; } | |
// ``` | |
// If we are matching `<_ as Bar>::Assoc` against `Foo`, we might rule out the impl even though `_` could be inferred to `f32` and hence it might match. | |
None |
☀️ Try build successful - checks-actions |
Queued be79c364343564bbcc7f36d4b3d932f2b49f3482 with parent df035a3, future comparison URL. |
Finished benchmarking commit (be79c364343564bbcc7f36d4b3d932f2b49f3482): comparison url. Summary: This change led to very large relevant regressions 😿 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never |
triage: returning to author to address comments |
is this expected? |
improve comments for `simplify_type` Should now correctly describe what's going on. Experimented with checking the invariant for projections but that ended up requiring fairly involved changes. I assume that it is not possible to get unsoundness here, at least for now and I can pretty much guarantee that it's impossible to trigger it by accident. r? ````@nikomatsakis```` cc rust-lang#92721
improve comments for `simplify_type` Should now correctly describe what's going on. Experimented with checking the invariant for projections but that ended up requiring fairly involved changes. I assume that it is not possible to get unsoundness here, at least for now and I can pretty much guarantee that it's impossible to trigger it by accident. r? `````@nikomatsakis````` cc rust-lang#92721
cc #86986 (comment)
r? @nikomatsakis