jiebi/CodeConvo huggingface dataset:
Code change:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

Related discussion:
text: self.is_const_fn_raw(def_id) && match self.is_unstable_const_fn(def_id) { Some(feature_name) => { // has a `rustc_const_unstable` attribute, check whether the user enabled the <del> // corresponding feature gate, const_constructor is not a lib feature, so has // to be checked separately. </del> <ins> // corresponding feature gate. </ins> self.features() .declared_lib_features .iter() .any(|&(sym, _)| sym == feature_name) <del> || (feature_name == sym::const_constructor && self.features().const_constructor) </del> }, // functions without const stability are either stable user written // const fn or the user is using feature gates and we thus don't
Code change:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

Related discussion:
text: /// Whether the `def_id` is an unstable const fn and what feature gate is necessary to enable it pub fn is_unstable_const_fn(self, def_id: DefId) -> Option<Symbol> { <del> if self.is_constructor(def_id) { Some(sym::const_constructor) } else if self.is_const_fn_raw(def_id) { </del> <ins> if self.is_const_fn_raw(def_id) { </ins> self.lookup_stability(def_id)?.const_stability } else { None
Code change:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

Related discussion:
text: (accepted, macros_in_extern, "1.40.0", Some(49476), None), /// Allows future-proofing enums/structs with the `#[non_exhaustive]` attribute (RFC 2008). (accepted, non_exhaustive, "1.40.0", Some(44109), None), <ins> /// Allows calling constructor functions in `const fn`. (accepted, const_constructor, "1.40.0", Some(61456), None), </ins> // ------------------------------------------------------------------------- // feature-group-end: accepted features
Code change:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

Related discussion:
text: /// Allows the user of associated type bounds. (active, associated_type_bounds, "1.34.0", Some(52662), None), <del> /// Allows calling constructor functions in `const fn`. (active, const_constructor, "1.37.0", Some(61456), None), </del> /// Allows `if/while p && let q = r && ...` chains. (active, let_chains, "1.37.0", Some(53667), None),
Code change:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

Related discussion:
text: #![cfg_attr(const_fn, feature(const_fn))] <del> #![feature(const_constructor)] </del> // Ctor(..) is transformed to Ctor { 0: ... } in HAIR lowering, so directly // calling constructors doesn't require them to be const.
Code change:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

Related discussion:
text: <ins> // revisions: min_const_fn const_fn // run-pass #![cfg_attr(const_fn, feature(const_fn))] trait ConstDefault { const DEFAULT: Self; } #[derive(PartialEq)] enum E { V(i32), W(usize), } impl ConstDefault for E { const DEFAULT: Self = Self::V(23); } impl ConstDefault for Option<i32> { const DEFAULT: Self = Self::Some(23); } impl E { const NON_DEFAULT: Self = Self::W(12); const fn local_fn() -> Self { Self::V(23) } } const fn explicit_qpath() -> E { let _x = <Option<usize>>::Some(23); <E>::W(12) } fn main() { assert!(E::DEFAULT == E::local_fn()); assert!(Option::DEFAULT == Some(23)); assert!(E::NON_DEFAULT == explicit_qpath()); } </ins>
Code change:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

Related discussion:
text: <del> error: `std::prelude::v1::Some` is not yet stable as a const fn --> $DIR/feature-gate-const_constructor.rs:9:37 | LL | const EXTERNAL_CONST: Option<i32> = {Some}(1); |                                     ^^^^^^^^^ | = help: add `#![feature(const_constructor)]` to the crate attributes to enable error: `E::V` is not yet stable as a const fn --> $DIR/feature-gate-const_constructor.rs:12:24 | LL | const LOCAL_CONST: E = {E::V}(1); |                        ^^^^^^^^^ | = help: add `#![feature(const_constructor)]` to the crate attributes to enable error: `std::prelude::v1::Some` is not yet stable as a const fn --> $DIR/feature-gate-const_constructor.rs:17:13 | LL |     let _ = {Some}(1); |             ^^^^^^^^^ | = help: add `#![feature(const_constructor)]` to the crate attributes to enable error: `E::V` is not yet stable as a const fn --> $DIR/feature-gate-const_constructor.rs:23:13 | LL |     let _ = {E::V}(1); |             ^^^^^^^^^ | = help: add `#![feature(const_constructor)]` to the crate attributes to enable error: aborting due to 4 previous errors </del>
Code change:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

Related discussion:
text: <del> // revisions: min_const_fn const_fn #![cfg_attr(const_fn, feature(const_fn))] enum E { V(i32), } const EXTERNAL_CONST: Option<i32> = {Some}(1); //[min_const_fn]~^ ERROR is not yet stable as a const fn //[const_fn]~^^ ERROR is not yet stable as a const fn const LOCAL_CONST: E = {E::V}(1); //[min_const_fn]~^ ERROR is not yet stable as a const fn //[const_fn]~^^ ERROR is not yet stable as a const fn const fn external_fn() { let _ = {Some}(1); //[min_const_fn]~^ ERROR is not yet stable as a const fn //[const_fn]~^^ ERROR is not yet stable as a const fn } const fn local_fn() { let _ = {E::V}(1); //[min_const_fn]~^ ERROR is not yet stable as a const fn //[const_fn]~^^ ERROR is not yet stable as a const fn } fn main() {} </del>
Code change:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect. But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants

Related discussion:
text: /// Free-form case. Only for errors that are never caught! Unsupported(String), <del> /// FIXME(#64506) Error used to work around accessing projections of /// uninhabited types. UninhabitedValue, </del> // -- Everything below is not categorized yet -- FunctionAbiMismatch(Abi, Abi), FunctionArgMismatch(Ty<'tcx>, Ty<'tcx>),
Code change:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect. But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants

Related discussion:
text: not a power of two"), Unsupported(ref msg) => write!(f, "{}", msg), <del> UninhabitedValue => write!(f, "tried to use an uninhabited value"), </del> } } }
Code change:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect. But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants

Related discussion:
text: }); (present_variants.next(), present_variants.next()) }; <del> if present_first.is_none() { </del> <ins> let present_first = match present_first { present_first @ Some(_) => present_first, </ins> // Uninhabited because it has no variants, or only absent ones. <del> return tcx.layout_raw(param_env.and(tcx.types.never)); } </del> <ins> None if def.is_enum() => return tcx.layout_raw(param_env.and(tcx.types.never)), // if it's a struct, still compute a layout so that we can still compute the // field offsets None => Some(VariantIdx::new(0)), }; </ins> let is_struct = !def.is_enum() || // Only one variant is present.
Code change:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect. But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants

Related discussion:
text: use rustc::mir::interpret::truncate; use rustc::ty::{self, Ty}; use rustc::ty::layout::{ <del> self, Size, Abi, Align, LayoutOf, TyLayout, HasDataLayout, VariantIdx, PrimitiveExt </del> <ins> self, Size, Align, LayoutOf, TyLayout, HasDataLayout, VariantIdx, PrimitiveExt </ins> }; use rustc::ty::TypeFoldable;
Code change:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect. But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants

Related discussion:
text: pub fn offset(&self, i: usize) -> Size { match *self { <del> FieldPlacement::Union(_) => Size::ZERO, </del> <ins> FieldPlacement::Union(count) => { assert!(i < count, "Tried to access field {} of union with {} fields", i, count); Size::ZERO }, </ins> FieldPlacement::Array { stride, count } => { let i = i as u64; assert!(i < count);