I expect the code below code to compile, but it fails. const_generics should allow more than just the types whitelisted in min_const_generics, but it seems rustc only looks at the min_const_generics flag in this case.
#![feature(const_generics)]
#![feature(min_const_generics)]
struct Contain<const S: &'static [u8]>;
The error message is:
error: `&'static [u8]` is forbidden as the type of a const generic parameter
--> src/lib.rs:4:25
|
4 | struct Contain<const S: &'static [u8]>;
| ^^^^^^^^^^^^^
|
= note: the only supported types are integers, `bool` and `char`
= note: more complex types are supported with `#[feature(const_generics)]`
but it seems rustc only looks at the
min_const_generics
You are right
But why would you want to use the two of them?
But why would you want to use the two of them?
I imagine this to happen whenever at first you only decide to use min_const_generics, but then later also switch to const_generics. You might just follow rustc, which tells you to add #![feature(const_generics)] to your project, so you do, but then you get the behaviour as described in this issue.
This could also perhaps get triggered in a more subtle way where you write a library that uses cfg_attr to enable or disable features.
what do you think @lcnr ?
It probably makes sense to instead check if we are not using feature(const_generics) here, but there are a quite a few places were we check for feature(min_const_generics), we maybe want to instead emit an error/warning when using both const_generics and min_const_generics in the same crate.
Created a way to produce an error in case of incompatible features, like this one
Created a way to produce an error in case of incompatible features, like this one
I have one question, how does using 'incompatible feature' cause _maybe_ undefined behavior?
Are there other incompatible features?
In this case, wouldn't it be better to produce an error message like "feature(const_generics) is a superset of feature(min_const_generics)"?
But why would you want to use the two of them?
Note that:
#[feature(const_generics)]
struct S<const I: usize>;
results in a compile error:
error[E0658]: const generics are unstable
--> src/lib.rs:3:16
|
3 | struct S<const I: usize>;
| ^
|
= note: see issue #74878 <https://github.com/rust-lang/rust/issues/74878> for more information
= help: add `#![feature(min_const_generics)]` to the crate attributes to enable
So currently const_generics is _not_ a superset of min_const_generics.
But why would you want to use the two of them?
Note that:
#[feature(const_generics)] struct S<const I: usize>;results in a compile error:
error[E0658]: const generics are unstable --> src/lib.rs:3:16 | 3 | struct S<const I: usize>; | ^ | = note: see issue #74878 <https://github.com/rust-lang/rust/issues/74878> for more information = help: add `#![feature(min_const_generics)]` to the crate attributes to enableSo currently
const_genericsis _not_ a superset ofmin_const_generics.
You are missing a ! in your feature. I still think const_generics are a superset of min_const_generics, _but_ rustc just suggest using the smaller one in this case becouse that's the subset aiming to be stabilized for now
Ah of course, my bad 馃槄
I was confused looking at some ui tests for const generics, and missed that those now have support differentiating between expected behavior under const_generics and min_const_generics, and thought a particular error was always being thrown, instead of only under min_const_generics.