min_const_generic takes precedence over const_generics

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

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?

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.

@lcnr

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.

Rollup merge of rust-lang#76293 - Amjad50:incompatible_features_error…

Navigation Menu

Repository navigation

`min_const_generic` takes precedence over `const_generics` #76280

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	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,
	}
	};

min_const_generic takes precedence over const_generics #76280

Description

Activity

Amjad50 commented on Sep 3, 2020

DutchGhost commented on Sep 3, 2020

Amjad50 commented on Sep 3, 2020

lcnr commented on Sep 3, 2020

Amjad50 commented on Sep 3, 2020

DutchGhost commented on Sep 3, 2020

CDirkx commented on Sep 4, 2020

DutchGhost commented on Sep 4, 2020

CDirkx commented on Sep 4, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`min_const_generic` takes precedence over `const_generics` #76280