-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 use projection cache or candidate cache in intercrate mode #89125
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
cc @rust-lang/wg-traits |
If this is only disabling caches, the r=me with appropriate comments added |
Fixes rust-lang#88969 It appears that *just* disabling the evaluation cache (in rust-lang#88994) leads to other issues involving intercrate mode caching. I suspect that since we now always end up performing the full evaluation in intercrate mode, we end up 'polluting' the candidate and projection caches with results that depend on being in intercrate mode in some way. Previously, we might have hit a cached evaluation (stored during non-intercrate mode), and skipped doing this extra work in intercrate mode. The whole situation with intercrate mode caching is turning into a mess. Ideally, we would remove intercrate mode entirely - however, this might require waiting on Chalk.
8b70c8f
to
6dbb9d4
Compare
@bors r=jackh726 |
📌 Commit 6dbb9d4 has been approved by |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
🙅 Please do not |
@bors r- |
@bors try |
⌛ Trying commit 6dbb9d4 with merge 8d03c9c947571bf681dc63b203b921ee9f76eed5... |
☀️ Try build successful - checks-actions |
1 similar comment
☀️ Try build successful - checks-actions |
Queued 8d03c9c947571bf681dc63b203b921ee9f76eed5 with parent 3bb9eec, future comparison URL. |
Finished benchmarking commit (8d03c9c947571bf681dc63b203b921ee9f76eed5): comparison url. Summary: This change led to moderate 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 |
This is a correctness fix, so we'll need to take the performance hit (at least until we can come up with a better solution). @bors r=jackh726 |
📌 Commit 6dbb9d4 has been approved by |
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.
(Also, do we have a test case?)
// Don't use the projection cache in intercrate mode - | ||
// the `infcx` may be re-used between intercrate in non-intercrate | ||
// mode, which could lead to using incorrect cache results. | ||
let use_cache = !selcx.is_intercrate(); |
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.
Probably the right answer is that the cache key incorporates the environment, and intercrate mode is part of the environment (this is how chalk approaches it).
☀️ Test successful - checks-actions |
@Aaron1011 should this be nominated for beta-backport? |
Add regression test for issues rust-lang#88969 and rust-lang#89119 This adds a regression test to complete rust-lang#89125, and thus for issues rust-lang#88969 and rust-lang#89119, which needed a test. Used with multiple crates, [this](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f665e7e882059157e0f86cfb09c47187) minimized from `zvariant-2.8.0` reproduces the error on `nightly-2021-09-19`. The test in this PR fails on master if the commit 6dbb9d4 from rust-lang#89125 is reverted, and passes otherwise since it's now fixed. r? `@Aaron1011`
…jackh726 Don't use projection cache or candidate cache in intercrate mode Fixes rust-lang#88969 It appears that *just* disabling the evaluation cache (in rust-lang#88994) leads to other issues involving intercrate mode caching. I suspect that since we now always end up performing the full evaluation in intercrate mode, we end up 'polluting' the candidate and projection caches with results that depend on being in intercrate mode in some way. Previously, we might have hit a cached evaluation (stored during non-intercrate mode), and skipped doing this extra work in intercrate mode. The whole situation with intercrate mode caching is turning into a mess. Ideally, we would remove intercrate mode entirely - however, this might require waiting on Chalk.
[beta] Beta rollup * Fix WinUWP std compilation errors due to I/O safety rust-lang#88587 * Disable RemoveZsts in generators to avoid query cycles rust-lang#88979 * Disable the evaluation cache when in intercrate mode rust-lang#88994 * Fix linting when trailing macro expands to a trailing semi rust-lang#88996 * Don't use projection cache or candidate cache in intercrate mode rust-lang#89125 * 2229: Mark insignificant dtor in stdlib rust-lang#89144 * Temporarily rename int_roundings functions to avoid conflicts rust-lang#89184 * [rfc 2229] Drop fully captured upvars in the same order as the regular drop code rust-lang#89208 * Use the correct edition for syntax highlighting doctests rust-lang#89277 * Don't normalize opaque types with escaping late-bound regions rust-lang#89285 * Update Let's Encrypt ROOT CA certificate in dist-(i686|x86_64)-linux docker images rust-lang#89486 Cargo update: * - [beta] 1.56 backports (rust-lang/cargo#9958) * - [beta] Revert "When a dependency does not have a version, git or path… (rust-lang/cargo#9912) * - [beta] Fix rustc --profile=dev unstable check. (rust-lang/cargo#9901)
Fixes #88969
It appears that just disabling the evaluation cache (in #88994)
leads to other issues involving intercrate mode caching. I suspect
that since we now always end up performing the full evaluation
in intercrate mode, we end up 'polluting' the candidate and projection
caches with results that depend on being in intercrate mode in some way.
Previously, we might have hit a cached evaluation (stored during
non-intercrate mode), and skipped doing this extra work in
intercrate mode.
The whole situation with intercrate mode caching is turning into
a mess. Ideally, we would remove intercrate mode entirely - however,
this might require waiting on Chalk.