`min_const_generic` takes precedence over `const_generics`

[DutchGhost]

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)]`

[Amjad50]

but it seems rustc only looks at the min_const_generics

You are right

rust/compiler/rustc_typeck/src/check/wfcheck.rs

Lines 293 to 310 in 08deb86

	let err = if tcx.features().min_const_generics {
	match ty.kind {
	ty::Bool | ty::Char | ty::Int(_) | ty::Uint(_) | ty::Error(_) => None,
	ty::FnPtr(_) => Some("function pointers"),
	ty::RawPtr(_) => Some("raw pointers"),
	_ => {
	is_ptr = false;
	err_ty_str = format!("`{}`", ty);
	Some(err_ty_str.as_str())
	}
	}
	} else {
	match ty.peel_refs().kind {
	ty::FnPtr(_) => Some("function pointers"),
	ty::RawPtr(_) => Some("raw pointers"),
	_ => None,
	}
	};

But why would you want to use the two of them?

[DutchGhost]

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.

[Amjad50]

what do you think @lcnr ?

[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.

[Amjad50]

Created a way to produce an error in case of incompatible features, like this one

[DutchGhost]

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)"?

[CDirkx]

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.

[DutchGhost]

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

[CDirkx]

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.