-
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
Normalize before erasing late-bound regions in equal_up_to_regions
#101437
Normalize before erasing late-bound regions in equal_up_to_regions
#101437
Conversation
I wonder if a crater run would shed some light on real-world crates that are fixed by this PR, since it's very likely that something is broken out in the wild due to this. @bors try |
⌛ Trying commit 76b494a with merge e3fba958e26aa56a364ba6d36376f1800cd40fa5... |
// FIXME: We erase all late-bound lifetimes, but this is not fully correct. | ||
// If you have a type like `<for<'a> fn(&'a u32) as SomeTrait>::Assoc`, | ||
// this is not necessarily equivalent to `<fn(&'static u32) as SomeTrait>::Assoc`, | ||
// since one may have an `impl SomeTrait for fn(&32)` and |
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 FIXME can be removed now, right? Since we now normalize before erasing, so the <for<'a> fn(&'a u32) as SomeTrait>::Assoc
will be normalized to the correct type.
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 still applies to the can_eq call that happens below
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 normalizing the associated type might fail if this is in a generic context.
☀️ Try build successful - checks-actions |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
@rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
@rust-timer build e3fba958e26aa56a364ba6d36376f1800cd40fa5 |
Queued e3fba958e26aa56a364ba6d36376f1800cd40fa5 with parent 406e03f, future comparison URL. |
Finished benchmarking commit (e3fba958e26aa56a364ba6d36376f1800cd40fa5): comparison URL. Overall result: no relevant changes - no action neededBenchmarking 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. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Footnotes |
🎉 Experiment
|
I don't think these regressions are related to my PR. I checked the regressions based on syn locally, e.g. https://crater-reports.s3.amazonaws.com/pr-101437/try%23e3fba958e26aa56a364ba6d36376f1800cd40fa5/reg/prefer-dynamic-0.1.2/log.txt and I can't reproduce them. |
@compiler-errors Have you rebased on 406e03f? crater tested with that commit and with this PR merged into that commit. I haven't done very much crater triage, but I don't think I've seen spurious failures like this from syn before and wouldn't expect them. |
Yes, I just cherry-picked my change back onto the base 406e03f and still can't repro when I run with Worthwhile re-checking the regressed crates to see if they're spurious I guess 🤷 @craterbot run mode=check-only list=https://crater-reports.s3.amazonaws.com/pr-101437/retry-regressed-list.txt |
🚨 Error: failed to parse the command 🆘 If you have any trouble with Crater please ping |
@craterbot run mode=check-only crates=https://crater-reports.s3.amazonaws.com/pr-101437/retry-regressed-list.txt |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
Ok I'm pretty certain craterbot is broken -- these are definitely failing due to I am going to test this in #101509 with a no-op change. |
Ok, this is a crater bug. |
Cc rust-lang/crater#663 (similar in shape at least, though maybe not exactly this case) |
Should we go ahead and land this PR then? |
@bors rollup=never |
☀️ Test successful - checks-actions |
Finished benchmarking commit (1120c5e): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Footnotes |
@rustbot label: +perf-regression-triaged |
Normalize erasing regions first, before passing the type through a
BottomUpFolder
which erases late-bound regions too.The root cause of this issue is due to 96d4137, which removes a
normalize_erasing_regions
that happens before this call toequal_up_to_regions
. While reverting that commit might be a fix, I think it was suspicious to be erasing late-bound regions first then normalizing types in the first place inequal_up_to_regions
.I am tempted to ask the reviewer to review and
r+
this without a UI test, since the existing issues that I think this fixes are all incredibly difficult to minimize (anything hyper/warp related, given the nature of those libraries 😓) or impossible to reproduce locally (the miri test), namely:miri
no longer builds after rust-lang/rust#101333 #101344miri
no longer builds after rust-lang/rust#101333 #101344 (comment)I have locally verified that the repro in #101430 is fixed with this PR, but after a couple of hours of attempting to minimize this error and either failing to actually repro the ICE, or being overwhelmed with the number of traits and functions I need to inline into a UI test, I have basically given up. Thoughts are appreciated on how best to handle this.
r? @oli-obk who is at the intersection of MIR and types-related stuff who may be able to give advice 😅