-
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
Refactor variance diagnostics to work with more types #89336
Conversation
r? @cjgillot (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 f97bb8adee90d5df2c6d27ddfec3f67a76f57d87 with merge 78c916af8206ddc392ba5affbc9f3443134ac39a... |
☀️ Try build successful - checks-actions |
Queued 78c916af8206ddc392ba5affbc9f3443134ac39a with parent 8f8092c, future comparison URL. |
Finished benchmarking commit (78c916af8206ddc392ba5affbc9f3443134ac39a): comparison url. Summary: This change led to moderate relevant mixed results 🤷 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 |
f97bb8a
to
a4fbd4d
Compare
This comment has been minimized.
This comment has been minimized.
a4fbd4d
to
85046e3
Compare
☔ The latest upstream changes (presumably #89549) made this pull request unmergeable. Please resolve the merge conflicts. |
The perf looks overall a slight regression. Do you have an idea where it comes from? I am not yet certain the current diagnostic improvement justifies it. |
src/test/ui/nll/closure-requirements/propagate-approximated-shorter-to-static-no-bound.stderr
Show resolved
Hide resolved
triage: merge conflicts and hasn't been updated for months. |
85046e3
to
96335f7
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 96335f7bef91b2fc617605e8e797eabe5ffab7ec with merge 8f5328a4aac51b855358a1acdef28b26309c47f9... |
Queued 3c38ccd60f62c2cbc57e83dc787cb23f77bad2ff with parent df96fb1, future comparison URL. |
Finished benchmarking commit (3c38ccd60f62c2cbc57e83dc787cb23f77bad2ff): comparison url. Summary: This benchmark run did not return any relevant changes. 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. @bors rollup=never |
Instead of special-casing mutable pointers/references, we now support general generic types (currently, we handle `ty::Ref`, `ty::RawPtr`, and `ty::Adt`) When a `ty::Adt` is involved, we show an additional note explaining which of the type's generic parameters is invariant (e.g. the `T` in `Cell<T>`). Currently, we don't explain *why* a particular generic parameter ends up becoming invariant. In the general case, this could require printing a long 'backtrace' of types, so doing this would be more suitable for a follow-up PR. We still only handle the case where our variance switches to `ty::Invariant`.
4c8e57c
to
b15cb29
Compare
@cjgillot I've squashed the commits after applying your suggestion |
@bors r+ |
📌 Commit b15cb29 has been approved by |
⌛ Testing commit b15cb29 with merge 420b62c47e63bf158d0e0729e4220c99c0ff8ea2... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
☀️ Test successful - checks-actions |
Finished benchmarking commit (f8d4ee7): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
…n1011 Note invariance reason for FnDef types Fixes rust-lang#95272. Is it worthwhile even printing a variance explanation here? Or should I try to track down which function parameter is responsible for the invariance? r? `@Aaron1011` since you wrote rust-lang#89336
…n1011 Note invariance reason for FnDef types Fixes rust-lang#95272. Is it worthwhile even printing a variance explanation here? Or should I try to track down which function parameter is responsible for the invariance? r? `@Aaron1011` since you wrote rust-lang#89336
…n1011 Note invariance reason for FnDef types Fixes rust-lang#95272. Is it worthwhile even printing a variance explanation here? Or should I try to track down which function parameter is responsible for the invariance? r? ``@Aaron1011`` since you wrote rust-lang#89336
Instead of special-casing mutable pointers/references, we
now support general generic types (currently, we handle
ty::Ref
,ty::RawPtr
, andty::Adt
)When a
ty::Adt
is involved, we show an additional noteexplaining which of the type's generic parameters is
invariant (e.g. the
T
inCell<T>
). Currently, we don'texplain why a particular generic parameter ends up becoming
invariant. In the general case, this could require printing
a long 'backtrace' of types, so doing this would be
more suitable for a follow-up PR.
We still only handle the case where our variance switches
to
ty::Invariant
.