rustc_typeck: gate AnonConst's generics on feature(const_generics).#66883
Merged
bors merged 2 commits intorust-lang:masterfrom Dec 1, 2019
Merged
rustc_typeck: gate AnonConst's generics on feature(const_generics).#66883bors merged 2 commits intorust-lang:masterfrom
bors merged 2 commits intorust-lang:masterfrom
Conversation
rust-highfive
added
the
S-waiting-on-review
Contributor
I think we've always implicitly understood this would be the case, so I have no issue making that explicit. |
Contributor
|
@bors r+ |
Collaborator
|
📌 Commit 584ede5 has been approved by |
Collaborator
|
🌲 The tree is currently closed for pull requests below priority 1000, this pull request will be tested once the tree is reopened |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Nov 30, 2019
…li-obk rustc_typeck: gate AnonConst's generics on feature(const_generics). This PR employs the fix for rust-lang#43408 when `#![feature(const_generics)]` is enabled, making the feature-gate the opt-in for all the possible breakage this may incur. For example, if this PR lands, this will cause a cycle error (due to rust-lang#60471): ```rust #![feature(const_generics)] fn foo<T: Into<[u8; 4]>>() {} ``` And so will anything with type-level const expressions, in its bounds. Surprisingly, `impl`s don't seem to be affected (if they were, even libcore wouldn't compile). One thing I'm worried about is not knowing how much unstable code out there, using const-generics, will be broken. But types like `Foo<{N+1}>` never really worked, and do after this PR, just not in bounds - so ironically, it's type-level const expressions that don't depend on generics, which will break (in bounds). Also, if we do this, we'll have effectively blocked stabilization of const generics on rust-lang#60471. r? @oli-obk cc @varkor @yodaldevoid @nikomatsakis
| // HACK(eddyb) when substs contain e.g. inference variables, | ||
| // attempt using identity substs instead, that will succeed | ||
| // when the expression doesn't depend on any parameters. | ||
| // FIXME(eddyb) make `const_eval` a canonical query instead, |
There was a problem hiding this comment.
I also discovered that we need to make const_eval a canonical query as part of my work on lazy normalization(https://rust-lang.zulipchat.com/#narrow/stream/144729-wg-traits/topic/lazy-normalization.20and.20const.20generics/near/180906840). That's also partly my motivation behind #66877.
bors
added a commit
that referenced
this pull request
Dec 1, 2019
Rollup of 9 pull requests Successful merges: - #66612 (Initial implementation of or-pattern usefulness checking) - #66705 (Atomic as_mut_ptr) - #66759 (impl TrustedLen for vec::Drain) - #66858 (Use LLVMAddAnalysisPasses instead of Rust's wrapper) - #66870 (SimplifyArmIdentity only for locals with the same type) - #66883 (rustc_typeck: gate AnonConst's generics on feature(const_generics).) - #66889 (Make python-generated source files compatible with rustfmt) - #66894 (Remove unneeded prelude imports in libcore tests) - #66895 (Feature gating *declarations* => new crate `rustc_feature`) Failed merges: - #66905 (rustc_plugin: Remove some remaining plugin features) r? @ghost
This was referenced Dec 31, 2019
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
6 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.
This PR employs the fix for #43408 when
#![feature(const_generics)]is enabled, making the feature-gate the opt-in for all the possible breakage this may incur.For example, if this PR lands, this will cause a cycle error (due to #60471):
And so will anything with type-level const expressions, in its bounds.
Surprisingly,
impls don't seem to be affected (if they were, even libcore wouldn't compile).One thing I'm worried about is not knowing how much unstable code out there, using const-generics, will be broken. But types like
Foo<{N+1}>never really worked, and do after this PR, just not in bounds - so ironically, it's type-level const expressions that don't depend on generics, which will break (in bounds).Also, if we do this, we'll have effectively blocked stabilization of const generics on #60471.
r? @oli-obk cc @varkor @yodaldevoid @nikomatsakis