Normalize opaques with late-bound vars again #113108
Merged
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
|
cc @rust-lang/types, I don't think this needs an FCP since this doesn't affect the type system in an observable way other than fixing potential ICEs -- I guess should be more of a T-compiler PR (but did r? for types because y'all have context). Just letting y'all know in case someone has strong opinions about this PR. |
This comment was marked as resolved.
This comment was marked as resolved.
compiler-errors
added
the
T-types
|
@bors r+ rollup=never |
bors
added
S-waiting-on-bors
|
⌛ Testing commit bfc6ca8 with merge 7bace13bbc0bea3688dfc3e8f37f104787e05790... |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
bors
added
S-waiting-on-bors
|
⌛ Testing commit bfc6ca8 with merge ad0d2e8896479710a73570a24714b05ab5104957... |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
@bors retry mips core dump? |
bors
removed
the
S-waiting-on-review
bors
added
S-waiting-on-review
|
⌛ Testing commit bfc6ca8 with merge 4cd4b2f45634472196bf80a3945d312c9a9962cc... |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (a20a04e): comparison URL. Overall result: ✅ improvements - no action needed@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.
Binary sizeResultsThis 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.
Bootstrap: 662.766s -> 660.963s (-0.27%) |
LeanderBB
pushed a commit
to LeanderBB/proton-api-rs
that referenced
this pull request
Jul 9, 2023
Attempt to abstract sync and async requests by writing an abstraction over the flow of data that encompasses a request. The requests fill out a `RequestData` instance which then gets used as the source of future transformations. The login chain is a prime example of this. We define a series of steps that are expressed as a series of sequences which will finally produce the expected outcome. The Session now produces a `Sequence` implementation which needs to be driven by a client. Unfortunately, due to lack of Async Trait support, the async implementation is not as efficient as it could be. Attempt was made to test the code on nightly, but ran into this bug rust-lang/rust#113108
LeanderBB
pushed a commit
to LeanderBB/proton-api-rs
that referenced
this pull request
Jul 9, 2023
Attempt to abstract sync and async requests by writing an abstraction over the flow of data that encompasses a request. The requests fill out a `RequestData` instance which then gets used as the source of future transformations. The login chain is a prime example of this. We define a series of steps that are expressed as a series of sequences which will finally produce the expected outcome. The Session now produces a `Sequence` implementation which needs to be driven by a client. Unfortunately, due to lack of Async Trait support, the async implementation is not as efficient as it could be. Attempt was made to test the code on nightly, but ran into this bug rust-lang/rust#113108
compiler-errors
deleted the
normalize-opaques-with-late-bound-vars-again
branch
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.
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::Allmode. 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_regionsto 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 #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:
GenFutureshim when compiling async constructs #104321 (lowerasync { .. }directly as a generator that implementsFuture, removing thefrom_generatorshim)identity_futureindirection #104833 (removing anidentity_futurefn that was wrapping desugared future generators)... so given that I can see:
... and given that this PR:
TypeMap! #109464DefiningAnchor::Bubblefrom 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