Normalize opaque types with bound vars...... again #107620
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
|
@bors try |
|
⌛ Trying commit a96733ce878652e60c549bf14ce38610bd49cf9d with merge 0179c3cb935eb588d407cb784f436ae84d99db5c... |
|
☀️ Try build successful - checks-actions |
|
@craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
|
@craterbot cancel |
|
🚨 Error: failed to parse the command 🆘 If you have any trouble with Crater please ping |
|
@craterbot run mode=build-only |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
@craterbot abort name=pr-107620 |
|
🗑️ Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-review
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
What a cursed change. Good luck. |
compiler-errors
commented
Feb 4, 2023
|
🎉 Experiment
|
Dylan-DPC
added
S-experimental
rust-cloud-vms
bot
force-pushed
the
normalize-opaques-with-late-bounds-again
branch
from
fffca29
to
3a79842
Compare
rustbot
added
the
WG-trait-system-refactor
rust-cloud-vms
bot
force-pushed
the
normalize-opaques-with-late-bounds-again
branch
from
3a79842
to
720477f
Compare
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
craterbot
added
S-waiting-on-crater
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
rust-cloud-vms
bot
force-pushed
the
normalize-opaques-with-late-bounds-again
branch
from
720477f
to
89b56d9
Compare
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
|
@craterbot run mode=check-only p=1 crates=https://crater-reports.s3.amazonaws.com/pr-107620/retry-regressed-list.txt (p=1 because it's a really small list, shouldn't noticeably delay the other experiments queued) |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
|
Closing this to clean up and put in a new PR |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 29, 2023
…th-late-bound-vars-again, r=jackh726 Normalize opaques with late-bound vars again We have a hack in the compiler where if an opaque has escaping late-bound vars, we skip revealing it even though we *could* reveal it from a technical perspective. First of all, this is weird, since we really should be revealing all opaques in `Reveal::All` mode. Second of all, it causes subtle bugs (linked below). I attempted to fix this in rust-lang#100980, which was unfortunately reverted due to perf regressions on codebases that used really deeply nested futures in some interesting ways. The worst of which was rust-lang#103423, which caused the project to hang on build. Another one was rust-lang#104842, which was just a slow-down, but not a hang. I took some time afterwards to investigate how to rework `normalize_erasing_regions` to take advantage of better caching, but that effort kinda fizzled out (rust-lang#104133). However, recently, I was made aware of more bugs whose root cause is not revealing opaques during codegen. That made me want to fix this again -- in the process, interestingly, I took the the minimized example from rust-lang#103423 (comment), and it doesn't seem to hang any more... Thinking about this harder, there have been some changes to the way we lower and typecheck async futures that may have reduced the pathologically large number of outlives obligations (see description of rust-lang#103423) that we were encountering when normalizing opaques with bound vars the last time around: * rust-lang#104321 (lower `async { .. }` directly as a generator that implements `Future`, removing the `from_generator` shim) * rust-lang#104833 (removing an `identity_future` fn that was wrapping desugared future generators) ... so given that I can see: * No significant regression on rust perf bot (rust-lang#107620 (comment)) * No timeouts in crater run I did (rust-lang#107620 (comment), rechecked failing crates in rust-lang#107620 (comment)) ... and given that this PR: * Fixes rust-lang#104601 * Fixes rust-lang#107557 * Fixes rust-lang#109464 * Allows us to remove a `DefiningAnchor::Bubble` from codegen (75a8f68) I'm inclined to give this another shot at landing this. Best case, it just works -- worst case, we get more examples to study how we need to improve the compiler to make this work. r? types
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Jul 2, 2023
…ound-vars-again, r=jackh726 Normalize opaques with late-bound vars again We have a hack in the compiler where if an opaque has escaping late-bound vars, we skip revealing it even though we *could* reveal it from a technical perspective. First of all, this is weird, since we really should be revealing all opaques in `Reveal::All` mode. Second of all, it causes subtle bugs (linked below). I attempted to fix this in #100980, which was unfortunately reverted due to perf regressions on codebases that used really deeply nested futures in some interesting ways. The worst of which was #103423, which caused the project to hang on build. Another one was #104842, which was just a slow-down, but not a hang. I took some time afterwards to investigate how to rework `normalize_erasing_regions` to take advantage of better caching, but that effort kinda fizzled out (#104133). However, recently, I was made aware of more bugs whose root cause is not revealing opaques during codegen. That made me want to fix this again -- in the process, interestingly, I took the the minimized example from rust-lang/rust#103423 (comment), and it doesn't seem to hang any more... Thinking about this harder, there have been some changes to the way we lower and typecheck async futures that may have reduced the pathologically large number of outlives obligations (see description of #103423) that we were encountering when normalizing opaques with bound vars the last time around: * #104321 (lower `async { .. }` directly as a generator that implements `Future`, removing the `from_generator` shim) * #104833 (removing an `identity_future` fn that was wrapping desugared future generators) ... so given that I can see: * No significant regression on rust perf bot (rust-lang/rust#107620 (comment)) * No timeouts in crater run I did (rust-lang/rust#107620 (comment), rechecked failing crates in rust-lang/rust#107620 (comment)) ... and given that this PR: * Fixes #104601 * Fixes #107557 * Fixes #109464 * Allows us to remove a `DefiningAnchor::Bubble` from codegen (75a8f681837c70051e0200a14f58ae07dbe58e66) I'm inclined to give this another shot at landing this. Best case, it just works -- worst case, we get more examples to study how we need to improve the compiler to make this work. r? types
lnicola
pushed a commit
to lnicola/rust-analyzer
that referenced
this pull request
Apr 7, 2024
…ound-vars-again, r=jackh726 Normalize opaques with late-bound vars again We have a hack in the compiler where if an opaque has escaping late-bound vars, we skip revealing it even though we *could* reveal it from a technical perspective. First of all, this is weird, since we really should be revealing all opaques in `Reveal::All` mode. Second of all, it causes subtle bugs (linked below). I attempted to fix this in #100980, which was unfortunately reverted due to perf regressions on codebases that used really deeply nested futures in some interesting ways. The worst of which was #103423, which caused the project to hang on build. Another one was #104842, which was just a slow-down, but not a hang. I took some time afterwards to investigate how to rework `normalize_erasing_regions` to take advantage of better caching, but that effort kinda fizzled out (#104133). However, recently, I was made aware of more bugs whose root cause is not revealing opaques during codegen. That made me want to fix this again -- in the process, interestingly, I took the the minimized example from rust-lang/rust#103423 (comment), and it doesn't seem to hang any more... Thinking about this harder, there have been some changes to the way we lower and typecheck async futures that may have reduced the pathologically large number of outlives obligations (see description of #103423) that we were encountering when normalizing opaques with bound vars the last time around: * #104321 (lower `async { .. }` directly as a generator that implements `Future`, removing the `from_generator` shim) * #104833 (removing an `identity_future` fn that was wrapping desugared future generators) ... so given that I can see: * No significant regression on rust perf bot (rust-lang/rust#107620 (comment)) * No timeouts in crater run I did (rust-lang/rust#107620 (comment), rechecked failing crates in rust-lang/rust#107620 (comment)) ... and given that this PR: * Fixes #104601 * Fixes #107557 * Fixes #109464 * Allows us to remove a `DefiningAnchor::Bubble` from codegen (75a8f681837c70051e0200a14f58ae07dbe58e66) I'm inclined to give this another shot at landing this. Best case, it just works -- worst case, we get more examples to study how we need to improve the compiler to make this work. r? types
RalfJung
pushed a commit
to RalfJung/rust-analyzer
that referenced
this pull request
Apr 27, 2024
…ound-vars-again, r=jackh726 Normalize opaques with late-bound vars again We have a hack in the compiler where if an opaque has escaping late-bound vars, we skip revealing it even though we *could* reveal it from a technical perspective. First of all, this is weird, since we really should be revealing all opaques in `Reveal::All` mode. Second of all, it causes subtle bugs (linked below). I attempted to fix this in #100980, which was unfortunately reverted due to perf regressions on codebases that used really deeply nested futures in some interesting ways. The worst of which was #103423, which caused the project to hang on build. Another one was #104842, which was just a slow-down, but not a hang. I took some time afterwards to investigate how to rework `normalize_erasing_regions` to take advantage of better caching, but that effort kinda fizzled out (#104133). However, recently, I was made aware of more bugs whose root cause is not revealing opaques during codegen. That made me want to fix this again -- in the process, interestingly, I took the the minimized example from rust-lang/rust#103423 (comment), and it doesn't seem to hang any more... Thinking about this harder, there have been some changes to the way we lower and typecheck async futures that may have reduced the pathologically large number of outlives obligations (see description of #103423) that we were encountering when normalizing opaques with bound vars the last time around: * #104321 (lower `async { .. }` directly as a generator that implements `Future`, removing the `from_generator` shim) * #104833 (removing an `identity_future` fn that was wrapping desugared future generators) ... so given that I can see: * No significant regression on rust perf bot (rust-lang/rust#107620 (comment)) * No timeouts in crater run I did (rust-lang/rust#107620 (comment), rechecked failing crates in rust-lang/rust#107620 (comment)) ... and given that this PR: * Fixes #104601 * Fixes #107557 * Fixes #109464 * Allows us to remove a `DefiningAnchor::Bubble` from codegen (75a8f681837c70051e0200a14f58ae07dbe58e66) I'm inclined to give this another shot at landing this. Best case, it just works -- worst case, we get more examples to study how we need to improve the compiler to make this work. r? types
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #107557, which demonstrates a real-life linker error due to not normalizing opaques with escaping bound vars.
Also fixes #109464.
I'm gonna run a crater run to see if we have any crates go from success -> timeout. Hopefully that'll help us better recognize if there are any major regressions? I may then be able to integrate some of my normalization work from #104133 to bring the compile times down for these crates...
I don't expect to be able to land this even if the crater run is clean. I'll still need to check that one crate that had regressed back when I tried to land this previously.
r? @ghost