rustc: don't resolve Instances which would produce malformed shims. #69036
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
|
r? @davidtwco (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
Just in case this is the cause of the regression at #68965 (comment): |
|
Awaiting bors try build completion |
bors
added a commit
that referenced
this pull request
Feb 10, 2020
rustc: don't resolve Instances which would produce malformed shims. There are some `InstanceDef` variants (shims and drop "glue") which contain a `Ty`, and that `Ty` is used in generating the shim MIR. But if that `Ty` mentions any generic parameters, the generated shim would refer to them (but they won't match the `Substs` of the `Instance`), or worse, generating the shim would fail because not enough of the type is known. Ideally we would always produce a "skeleton" of the type, e.g. `(_, _)` for dropping any tuples with two elements, or `Vec<_>` for dropping any `Vec` value, but that's a lot of work, and they would still not match the `Substs` of the `Instance` as it exists today, so `Instance` would probably need to change. By making `Instance::resolve` return `None` in the still-generic cases, we get behavior similar to specialization, where a default can only be used if there are no more generic parameters which would allow a more specialized `impl` to match. <hr/> This was found while testing the MIR inliner with #68965, because it was trying to inline shims. cc @rust-lang/wg-mir-opt
|
r? @wesleywiser |
|
@bors r- try- try Attempting to convince bors of reality... |
bors
added
S-waiting-on-author
|
@rust-timer build e369f6b Seems bors flaked @bors try- |
|
@rust-timer build e369f6b |
|
Queued e369f6b with parent 4d1241f, future comparison URL. |
|
Finished benchmarking try commit e369f6b, comparison URL. |
wesleywiser
approved these changes
Feb 11, 2020
|
Okay that's pure noise :( |
|
☔ The latest upstream changes (presumably #68679) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Triaged |
|
@eddyb Please let me know if there's anything I can do to help get this merged 🙂 |
This comment has been minimized.
This comment has been minimized.
eddyb
commented
Mar 11, 2020
nikomatsakis
approved these changes
Mar 11, 2020
bors
added
the
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
bors
added
S-waiting-on-author
|
@bors r=nikomatsakis |
|
📌 Commit bc8ff3f has been approved by |
bors
added
S-waiting-on-bors
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Mar 17, 2020
rustc: don't resolve Instances which would produce malformed shims. There are some `InstanceDef` variants (shims and drop "glue") which contain a `Ty`, and that `Ty` is used in generating the shim MIR. But if that `Ty` mentions any generic parameters, the generated shim would refer to them (but they won't match the `Substs` of the `Instance`), or worse, generating the shim would fail because not enough of the type is known. Ideally we would always produce a "skeleton" of the type, e.g. `(_, _)` for dropping any tuples with two elements, or `Vec<_>` for dropping any `Vec` value, but that's a lot of work, and they would still not match the `Substs` of the `Instance` as it exists today, so `Instance` would probably need to change. By making `Instance::resolve` return `None` in the still-generic cases, we get behavior similar to specialization, where a default can only be used if there are no more generic parameters which would allow a more specialized `impl` to match. <hr/> This was found while testing the MIR inliner with rust-lang#68965, because it was trying to inline shims. cc @rust-lang/wg-mir-opt
Centril
added a commit
to Centril/rust
that referenced
this pull request
Mar 19, 2020
rustc: don't resolve Instances which would produce malformed shims. There are some `InstanceDef` variants (shims and drop "glue") which contain a `Ty`, and that `Ty` is used in generating the shim MIR. But if that `Ty` mentions any generic parameters, the generated shim would refer to them (but they won't match the `Substs` of the `Instance`), or worse, generating the shim would fail because not enough of the type is known. Ideally we would always produce a "skeleton" of the type, e.g. `(_, _)` for dropping any tuples with two elements, or `Vec<_>` for dropping any `Vec` value, but that's a lot of work, and they would still not match the `Substs` of the `Instance` as it exists today, so `Instance` would probably need to change. By making `Instance::resolve` return `None` in the still-generic cases, we get behavior similar to specialization, where a default can only be used if there are no more generic parameters which would allow a more specialized `impl` to match. <hr/> This was found while testing the MIR inliner with rust-lang#68965, because it was trying to inline shims. cc @rust-lang/wg-mir-opt
bors
added a commit
that referenced
this pull request
Mar 19, 2020
Rollup of 9 pull requests Successful merges: - #69036 (rustc: don't resolve Instances which would produce malformed shims.) - #69443 (tidy: Better license checks.) - #69814 (Smaller and more correct generator codegen) - #69929 (Regenerate tables for Unicode 13.0.0) - #69959 (std: Don't abort process when printing panics in tests) - #69969 (unix: Set a guard page at the end of signal stacks) - #70005 ([rustdoc] Improve visibility for code blocks warnings) - #70088 (Use copy bound in atomic operations to generate simpler MIR) - #70095 (Implement -Zlink-native-libraries) Failed merges: r? @ghost
bors
added a commit
that referenced
this pull request
Mar 19, 2020
Rollup of 9 pull requests Successful merges: - #68941 (Properly handle Spans that reference imported SourceFiles) - #69036 (rustc: don't resolve Instances which would produce malformed shims.) - #69443 (tidy: Better license checks.) - #69814 (Smaller and more correct generator codegen) - #69929 (Regenerate tables for Unicode 13.0.0) - #69959 (std: Don't abort process when printing panics in tests) - #69969 (unix: Set a guard page at the end of signal stacks) - #70005 ([rustdoc] Improve visibility for code blocks warnings) - #70088 (Use copy bound in atomic operations to generate simpler MIR) Failed merges: r? @ghost
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.
There are some
InstanceDefvariants (shims and drop "glue") which contain aTy, and thatTyis used in generating the shim MIR. But if thatTymentions any generic parameters, the generated shim would refer to them (but they won't match theSubstsof theInstance), or worse, generating the shim would fail because not enough of the type is known.Ideally we would always produce a "skeleton" of the type, e.g.
(_, _)for dropping any tuples with two elements, orVec<_>for dropping anyVecvalue, but that's a lot of work, and they would still not match theSubstsof theInstanceas it exists today, soInstancewould probably need to change.By making
Instance::resolvereturnNonein the still-generic cases, we get behavior similar to specialization, where a default can only be used if there are no more generic parameters which would allow a more specializedimplto match.This was found while testing the MIR inliner with #68965, because it was trying to inline shims.
cc @rust-lang/wg-mir-opt