-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Track implicit Sized
obligations in type params
#98816
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 35c8de37a381d04518bc264b7ce77540e60248e2 with merge ad41a769c55008b2c294b5a07fecd82cb7dcba8c... |
r? @oli-obk |
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 8d080c6627d392ebb85974416bf97d00c5931105 with merge 4b74390cde4e98d80560abd60516653939311c30... |
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
Queued 4b74390cde4e98d80560abd60516653939311c30 with parent 750d6f8, future comparison URL. |
Finished benchmarking commit (4b74390cde4e98d80560abd60516653939311c30): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
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 may lead 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 Footnotes |
The
I'm guessing this is a caching issue now, as we can't ignore the new information like we could if it were part of the obligation cause. A hacky way forward would be to remove (canonicalize?) this information when invoking queries. But my root concern (adding such information to the predicate when it isn't actually used to make language decisions) still stands, and I don't have an obviously good solution for the problem here. One thing we could try is to add a magical Hmm... one thing I don't know if we talked about: have you attempted looking at the HIR to figure out if there's a |
There we go hir hiking :) |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
ty::Adt(def, _) if def.did().is_local() => { | ||
tcx.def_ident_span(def.did()).map(|span| span) | ||
} | ||
ty::Adt(def, _) => Some(tcx.def_span(def.did())), |
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.
this causes a lot of ui test noise and I don't think any of it is actually an improvement?
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 can revert.
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.
Done
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.
It still seems to be there?
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.
The only part of the change that is still there is the removal of the unnecessary map
call, the match guard is now present.
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.
you also changed def_ident_span
to def_span
, which now points to the entire item, which is what I meant originally 😆 I didn't even notice the match guard.
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 changed it to be consistent with other places where we use def_span
so that multiple span labels pointing at the same thing don't stagger. After a recent change def_span
points only at the signature and not the whole item, so it is suitable to use now. I didn't move all to be def_ident_span
because that would break the derive
suggestions (I'm planning on reducing the span in the future, but not in this PR).
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.
This is an example of what I'm saying:
error[E0599]: the method `get` exists for struct `Victim<'_, Self>`, but its trait bounds were not satisfied
--> $DIR/impl-derived-implicit-sized-bound.rs:31:19
|
LL | struct Victim<'a, T: Perpetrator + ?Sized>
| ------------------------------------------
| |
| method `get` not found for this struct
| doesn't satisfy `Victim<'_, Self>: VictimTrait`
Without the change the label for "method get
not found for this struct" would point at the ident, making the visual presentation a bit less... clean.
Suggest adding a `?Sized` bound if appropriate on E0599 by inspecting the HIR Generics. (Fix rust-lang#98539)
…`MiscObligation`
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (47575bb): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
When we evaluate
ty::GenericPredicates
we introduce the implicitSized
predicate of type params, but we do so with only thePredicate
its
Span
as context, we don't have anObligation
orObligationCauseCode
we could influence. To try and carry thisinformation through, we add a new field to
ty::GenericPredicates
thattracks both which predicates come from a type param and whether that
param has any bounds already (to use in suggestions).
We also suggest adding a
?Sized
bound if appropriate on E0599.Address part of #98539.