Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
rustc: include ParamEnv in global trait select/eval cache keys. #66963
IIUC, this is a bug fix, because before this PR, cached select/eval results:
The second case is the worse one IMO, I just hope we don't find people relying on it, on crater.
rustc: include ParamEnv in global trait select/eval cache keys. Without #66821, this doesn't cache more than before, but it *does* include `Reveal` in the trait select/eval cache keys (via `ParamEnv`), which is what caused the test failures in #66821. IIUC, this is a bug fix, because before this PR, cached select/eval results: * if `Reveal::UserFacing`, could limit what `Reveal::All` sees (and cause ICEs?) * if `Reveal::All`, could expose more to `Reveal::UserFacing` than intended The second case is the worse one IMO, I just hope we don't find people relying on it, on crater. r? @nikomatsakis cc @rust-lang/compiler
rustc: allow non-empty ParamEnv's in global trait select/eval caches. *Based on #66963* This appears to alleviate the symptoms of #65510 locally (without fixing WF directly), and is potentially easier to validate as sound (since it's a more ad-hoc version of queries we already have). I'm opening this PR primarily to test the effects on perf. r? @nikomatsakis cc @rust-lang/wg-traits
nikomatsakis left a comment
I agree this is likely a bug fix and seems pretty reasonable. I'm curious to see the performance impact. I'm also curious to understand the behavior of the test case.
The perf regression could be from one of two things: