-
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
don't succeed evaluate_obligation
query if new opaque types were registered
#98614
Conversation
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit b5c69c28e7c6bc516bcd2a3da1f041127305ee50 with merge 1456cc0b7aca695b7c1ccea221577f816127e562... |
e0bee8d
to
8a10a11
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 8a10a1153dd020a97c988ebe49805dbe2162dbb5 with merge e0f6bec5731bbf3046e9fcef78660e2a4a2d2ee8... |
☀️ Try build successful - checks-actions |
Queued e0f6bec5731bbf3046e9fcef78660e2a4a2d2ee8 with parent 00ebeb8, future comparison URL. |
Finished benchmarking commit (e0f6bec5731bbf3046e9fcef78660e2a4a2d2ee8): 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 |
Oof |
8a10a11
to
bb2e623
Compare
@bors try @rust-timer queue while this has a real impact in secondary benchmarks, the primary ones could be due to other commits, so I've only pushed the actual soundness fix commit |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit bb2e623870d2d12adcf320489e689c191899081d with merge 11ffe800cb85b4ba2042596b0f857b463df891ab... |
This comment has been minimized.
This comment has been minimized.
bb2e623
to
9dbfcbc
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Testing commit 0b863e0 with merge ed511e32a055a69d2fda3cbbf32cebe37e43cdd9... |
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
…othing else would work anyway.
@bors r=wesleywiser |
☀️ Test successful - checks-actions |
Finished benchmarking commit (052495d): 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 |
…ulacrum [beta] backport rollup * Return a FxIndexSet in is_late_bound query. rust-lang#98959 * rustdoc: filter '_ lifetimes from ty::PolyTraitRef rust-lang#98727 * don't succeed evaluate_obligation query if new opaque types were registered rust-lang#98614 * Update llvm-project rust-lang#98567 There's a few more as-yet-unapproved/unmerged PRs that'll land later, but creating a partial rollup for now so that we can include at least some PRs in the first crater run. r? `@Mark-Simulacrum`
…imulacrum [stable] 1.62.1 release This bundles: * Windows: Fallback for overlapped I/O rust-lang#98950 * don't succeed evaluate_obligation query if new opaque types were registered rust-lang#98614 * Mitigate MMIO stale data vulnerability rust-lang#98126 * Return a FxIndexSet in is_late_bound query. rust-lang#99219 Also bumps the version number to 1.62.1 and includes a short release notes section for the release. r? `@Mark-Simulacrum`
fixes #98608
fixes #98604
The root cause of all this is that in type flag computation we entirely ignore nongeneric things like struct fields and the signature of function items. So if a flag had to be set for a struct if it is set for a field, that will only happen if the field is generic, as only the generic parameters are checked.
I now believe we cannot use type flags to handle opaque types. They seem like the wrong tool for this.
Instead, this PR replaces the previous logic by adding a new variant of
EvaluatedToOk
:EvaluatedToOkModuloOpaqueTypes
, which says that there were some opaque types that got hidden types bound, but that binding may not have been legal (because we don't know if the opaque type was in its defining scope or not).