Remove a HACK by instead inferring opaque types during expected/formal type checking#123864
Merged
bors merged 2 commits intorust-lang:masterfrom Apr 15, 2024
Merged
Remove a HACK by instead inferring opaque types during expected/formal type checking#123864bors merged 2 commits intorust-lang:masterfrom
bors merged 2 commits intorust-lang:masterfrom
Conversation
rustbot
added
S-waiting-on-review
Contributor
Author
|
@bors try let's still crater it |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 12, 2024
Remove a HACK by instead inferring opaque types during expected/formal type checking I was wondering why I couldn't come up with a test that hits the code path of the argument check checking the types we inferred from the return type... Turns out we reject those attempts early during fudging. I have absolutely no information for you as to what kind of type inference changes this may incur, but I think we should just land this out of two reasons: * had I found the other place to use opaque type inference on before I added the hack, we'd be using that today and this PR would never have happened * if it is possible to hit this path, it requires some god awful recursive RPIT logic that I doubt anyone would have written without actively trying to write obscure code r? `@ghost`
Collaborator
Collaborator
|
☀️ Try build successful - checks-actions |
Contributor
Author
|
@craterbot check |
Collaborator
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
Collaborator
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
Collaborator
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
Contributor
Author
|
All of the regressions are spurious (either repro on master or are just disk out of space) |
Contributor
Author
Contributor
|
Yeah, I'm happy with landing this now. @bors r+ |
Collaborator
bors
added
S-waiting-on-bors
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this pull request
Apr 15, 2024
…mpiler-errors Remove a HACK by instead inferring opaque types during expected/formal type checking I was wondering why I couldn't come up with a test that hits the code path of the argument check checking the types we inferred from the return type... Turns out we reject those attempts early during fudging. I have absolutely no information for you as to what kind of type inference changes this may incur, but I think we should just land this out of two reasons: * had I found the other place to use opaque type inference on before I added the hack, we'd be using that today and this PR would never have happened * if it is possible to hit this path, it requires some god awful recursive RPIT logic that I doubt anyone would have written without actively trying to write obscure code r? `@ghost`
This was referenced Apr 15, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 15, 2024
Rollup of 12 pull requests Successful merges: - rust-lang#123423 (Distribute LLVM bitcode linker as a preview component) - rust-lang#123548 (libtest: also measure time in Miri) - rust-lang#123666 (Fix some typos in doc) - rust-lang#123864 (Remove a HACK by instead inferring opaque types during expected/formal type checking) - rust-lang#123896 (Migrate some diagnostics in `rustc_resolve` to session diagnostic) - rust-lang#123919 (builtin-derive: tag → discriminant) - rust-lang#123922 (Remove magic constants when using `base_n`.) - rust-lang#123931 (Don't leak unnameable types in `-> _` recover) - rust-lang#123933 (move the LargeAssignments lint logic into its own file) - rust-lang#123934 (`rustc_data_structures::graph` mini refactor) - rust-lang#123941 (Fix UB in LLVM FFI when passing zero or >1 bundle) - rust-lang#123957 (disable create_dir_all_bare test on all(miri, windows)) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 15, 2024
Rollup merge of rust-lang#123864 - oli-obk:define_opaque_types3, r=compiler-errors Remove a HACK by instead inferring opaque types during expected/formal type checking I was wondering why I couldn't come up with a test that hits the code path of the argument check checking the types we inferred from the return type... Turns out we reject those attempts early during fudging. I have absolutely no information for you as to what kind of type inference changes this may incur, but I think we should just land this out of two reasons: * had I found the other place to use opaque type inference on before I added the hack, we'd be using that today and this PR would never have happened * if it is possible to hit this path, it requires some god awful recursive RPIT logic that I doubt anyone would have written without actively trying to write obscure code r? ``@ghost``
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
I was wondering why I couldn't come up with a test that hits the code path of the argument check checking the types we inferred from the return type... Turns out we reject those attempts early during fudging.
I have absolutely no information for you as to what kind of type inference changes this may incur, but I think we should just land this out of two reasons:
r? @ghost