Construct closure type eagerly #120031
Merged
Construct closure type eagerly #120031
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
|
Actually, it seems like we have literally no tests that rely on 45fd3ec. I'm gonna split it out into a separate PR. |
rust-cloud-vms
bot
force-pushed
the
construct-closure-ty-eagerly
branch
from
45fd3ec to
37a5464
Compare
|
@bors r+ rollup what wouldn't I give for git diffs that are aware of code moves 😞 |
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jan 17, 2024
…ty-eagerly, r=oli-obk Construct closure type eagerly Construct the returned closure type *before* checking the body, in the same match as we were previously deducing the coroutine types based off of the closure kind. This simplifies some changes I'm doing in the async closure PR, and imo just seems easier to read (since we only need one match on closure kind, instead of two). There's no reason I can tell that we needed to create the closure type *after* the body was checked. ~~This also has the side-effect of making it so that the universe of the closure synthetic infer vars are lower than any infer vars that come from checking the body. We can also get rid of `next_root_ty_var` hack from closure checking (though in general we still need this, rust-lang#119106). cc `@lcnr` since you may care about this hack 😆~~ r? `@oli-obk`
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 17, 2024
…iaskrgr Rollup of 11 pull requests Successful merges: - rust-lang#115291 (Save liveness results for DestinationPropagation) - rust-lang#119855 (Enable Static Builds for FreeBSD) - rust-lang#119975 (Don't ICE if TAIT-defining fn contains a closure with `_` in return type) - rust-lang#119984 (Change return type of unstable `Waker::noop()` from `Waker` to `&Waker`.) - rust-lang#120001 (Consistently unset RUSTC_BOOTSTRAP when compiling bootstrap) - rust-lang#120020 (Gracefully handle missing typeck information if typeck errored) - rust-lang#120031 (Construct closure type eagerly) - rust-lang#120032 (Fix `rustc_abi` build on stable) - rust-lang#120039 (pat_analysis: Don't rely on contiguous `VariantId`s outside of rustc) - rust-lang#120044 (Fix typo in comments (in_place_collect)) - rust-lang#120056 (Use FnOnceOutput instead of FnOnce where expected) r? `@ghost` `@rustbot` modify labels: rollup
compiler-errors
added a commit
to compiler-errors/rust
that referenced
this pull request
Jan 17, 2024
…ty-eagerly, r=oli-obk Construct closure type eagerly Construct the returned closure type *before* checking the body, in the same match as we were previously deducing the coroutine types based off of the closure kind. This simplifies some changes I'm doing in the async closure PR, and imo just seems easier to read (since we only need one match on closure kind, instead of two). There's no reason I can tell that we needed to create the closure type *after* the body was checked. ~~This also has the side-effect of making it so that the universe of the closure synthetic infer vars are lower than any infer vars that come from checking the body. We can also get rid of `next_root_ty_var` hack from closure checking (though in general we still need this, rust-lang#119106). cc ``@lcnr`` since you may care about this hack 😆~~ r? ``@oli-obk``
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 17, 2024
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#115291 (Save liveness results for DestinationPropagation) - rust-lang#119855 (Enable Static Builds for FreeBSD) - rust-lang#119975 (Don't ICE if TAIT-defining fn contains a closure with `_` in return type) - rust-lang#120001 (Consistently unset RUSTC_BOOTSTRAP when compiling bootstrap) - rust-lang#120020 (Gracefully handle missing typeck information if typeck errored) - rust-lang#120031 (Construct closure type eagerly) - rust-lang#120032 (Fix `rustc_abi` build on stable) - rust-lang#120039 (pat_analysis: Don't rely on contiguous `VariantId`s outside of rustc) - rust-lang#120044 (Fix typo in comments (in_place_collect)) - rust-lang#120056 (Use FnOnceOutput instead of FnOnce where expected) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 18, 2024
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#115291 (Save liveness results for DestinationPropagation) - rust-lang#119855 (Enable Static Builds for FreeBSD) - rust-lang#119975 (Don't ICE if TAIT-defining fn contains a closure with `_` in return type) - rust-lang#120001 (Consistently unset RUSTC_BOOTSTRAP when compiling bootstrap) - rust-lang#120020 (Gracefully handle missing typeck information if typeck errored) - rust-lang#120031 (Construct closure type eagerly) - rust-lang#120032 (Fix `rustc_abi` build on stable) - rust-lang#120039 (pat_analysis: Don't rely on contiguous `VariantId`s outside of rustc) - rust-lang#120044 (Fix typo in comments (in_place_collect)) - rust-lang#120056 (Use FnOnceOutput instead of FnOnce where expected) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 18, 2024
Rollup merge of rust-lang#120031 - compiler-errors:construct-closure-ty-eagerly, r=oli-obk Construct closure type eagerly Construct the returned closure type *before* checking the body, in the same match as we were previously deducing the coroutine types based off of the closure kind. This simplifies some changes I'm doing in the async closure PR, and imo just seems easier to read (since we only need one match on closure kind, instead of two). There's no reason I can tell that we needed to create the closure type *after* the body was checked. ~~This also has the side-effect of making it so that the universe of the closure synthetic infer vars are lower than any infer vars that come from checking the body. We can also get rid of `next_root_ty_var` hack from closure checking (though in general we still need this, rust-lang#119106). cc ```@lcnr``` since you may care about this hack 😆~~ r? ```@oli-obk```
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.
Construct the returned closure type before checking the body, in the same match as we were previously deducing the coroutine types based off of the closure kind.
This simplifies some changes I'm doing in the async closure PR, and imo just seems easier to read (since we only need one match on closure kind, instead of two). There's no reason I can tell that we needed to create the closure type after the body was checked.
This also has the side-effect of making it so that the universe of the closure synthetic infer vars are lower than any infer vars that come from checking the body. We can also get rid ofnext_root_ty_varhack from closure checking (though in general we still need this, #119106). cc @lcnr since you may care about this hack 😆r? @oli-obk