Rust: `min_const_generic` takes precedence over `const_generics`

Created on 3 Sep 2020  路  9Comments  路  Source: rust-lang/rust

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)]`
A-const-generics F-const_generics F-min_const_generics T-compiler

All 9 comments

but it seems rustc only looks at the min_const_generics

You are right

https://github.com/rust-lang/rust/blob/08deb863bdebfcbbb71c18acf903eca84f1df4e7/compiler/rustc_typeck/src/check/wfcheck.rs#L293-L310

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 enable

So currently const_generics is _not_ a superset of min_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.

Was this page helpful?
0 / 5 - 0 ratings