jiebi/CodeConvo huggingface dataset:
Code change:
I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Seems related to

Related discussion:
text: <ins> //check-pass #![feature(generic_associated_types)] trait Yokeable<'a>: 'static { type Output: 'a; } trait IsCovariant<'a> {} struct Yoke<Y: for<'a> Yokeable<'a>> { data: Y, } impl<Y: for<'a> Yokeable<'a>> Yoke<Y> { fn project<Y2: for<'a> Yokeable<'a>>(&self, _f: for<'a> fn(<Y as Yokeable<'a>>::Output, &'a ()) -> <Y2 as Yokeable<'a>>::Output) -> Yoke<Y2> { unimplemented!() } } fn _upcast<Y>(x: Yoke<Y>) -> Yoke<Box<dyn IsCovariant<'static> + 'static>> where Y: for<'a> Yokeable<'a>, for<'a> <Y as Yokeable<'a>>::Output: IsCovariant<'a> { x.project(|data, _| { Box::new(data) }) } impl<'a> Yokeable<'a> for Box<dyn IsCovariant<'static> + 'static> { type Output = Box<dyn IsCovariant<'a> + 'a>; } fn main() {} </ins>
Code change:
Source: It is worth noting that this code should not compile. This bug occurs in both beta and nightly. : <details<summary<strongBacktrace</strong</summary<p</p</details
No longer ICEs since

Related discussion:
text: <ins> // check-pass pub trait Associate { type Associated; } pub struct Wrap<'a> { pub field: &'a i32, } pub trait Create<T> { fn create() -> Self; } pub fn oh_no<'a, T>() where Wrap<'a>: Associate, <Wrap<'a> as Associate>::Associated: Create<T>, { <Wrap<'a> as Associate>::Associated::create(); } pub fn main() {} </ins>
Code change:
Source: It is worth noting that this code should not compile. This bug occurs in both beta and nightly. : <details<summary<strongBacktrace</strong</summary<p</p</details
No longer ICEs since

Related discussion:
text: <ins> // check-pass #![feature(generic_associated_types)] trait Foo<T> { type Type<'a> where T: 'a; } impl<T> Foo<T> for () { type Type<'a> where T: 'a, = (); } fn foo<T>() { let _: for<'a> fn(<() as Foo<T>>::Type<'a>, &'a T) = |_, _| (); } pub fn main() {} </ins>
Code change:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

Related discussion:
text: (active, c_unwind, "1.52.0", Some(74990), None), /// Allows using C-variadics. (active, c_variadic, "1.34.0", Some(44930), None), <ins> /// Allows the use of `#[cfg(overflow_checks)` to check if integer overflow behaviour. (active, cfg_overflow_checks, "CURRENT_RUSTC_VERSION", Some(111466), None), </ins> /// Allows the use of `#[cfg(sanitize = "option")]`; set when -Zsanitizer is used. (active, cfg_sanitize, "1.41.0", Some(39699), None), /// Allows `cfg(target_abi = "...")`.
Code change:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

Related discussion:
text: /// `cfg(...)`'s that are feature gated. const GATED_CFGS: &[GatedCfg] = &[ // (name in cfg, feature, function to check if the feature is enabled) <ins> (sym::overflow_checks, sym::cfg_overflow_checks, cfg_fn!(cfg_overflow_checks)), </ins> (sym::target_abi, sym::cfg_target_abi, cfg_fn!(cfg_target_abi)), (sym::target_thread_local, sym::cfg_target_thread_local, cfg_fn!(cfg_target_thread_local)), (
Code change:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

Related discussion:
text: if sess.opts.debug_assertions { ret.insert((sym::debug_assertions, None)); } <ins> if sess.overflow_checks() { ret.insert((sym::overflow_checks, None)); } </ins> // JUSTIFICATION: before wrapper fn is available #[allow(rustc::bad_opt_access)] if sess.opts.crate_types.contains(&CrateType::ProcMacro) {
Code change:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

Related discussion:
text: sym::windows, sym::proc_macro, sym::debug_assertions, <ins> sym::overflow_checks, </ins> sym::target_thread_local, ] { self.expecteds.entry(name).or_insert_with(no_values);
Code change:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

Related discussion:
text: cfg_doctest, cfg_eval, cfg_hide, <ins> cfg_overflow_checks, </ins> cfg_panic, cfg_sanitize, cfg_target_abi,
Code change:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

Related discussion:
text: or_patterns, other, out, <ins> overflow_checks, </ins> overlapping_marker_traits, owned_box, packed,
Code change:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

Related discussion:
text: <ins> #![crate_type = "lib"] #[cfg(overflow_checks)] //~ ERROR `cfg(overflow_checks)` is experimental pub fn cast(v: i64)->u32{ todo!() } </ins>
Code change:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

Related discussion:
text: <ins> error[E0658]: `cfg(overflow_checks)` is experimental and subject to change --> $DIR/feature-gate-cfg_overflow_checks.rs:3:7 | LL | #[cfg(overflow_checks)] |       ^^^^^^^^^^^^^^^ | = note: see issue #111466 <https://github.com/rust-lang/rust/issues/111466> for more information = help: add `#![feature(cfg_overflow_checks)]` to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0658`. </ins>
Code change:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

Related discussion:
text: <ins> // run-pass // compile-flags: -C overflow_checks=true #![feature(cfg_overflow_checks)] fn main() { assert!(cfg!(overflow_checks)); assert!(compiles_differently()); } #[cfg(overflow_checks)] fn compiles_differently()->bool { true } #[cfg(not(overflow_checks))] fn compiles_differently()->bool { false } </ins>
Code change:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:

Related discussion:
text: <ins> // run-pass // compile-flags: -C overflow_checks=false #![feature(cfg_overflow_checks)] fn main() { assert!(!cfg!(overflow_checks)); assert!(!compiles_differently()); } #[cfg(overflow_checks)] fn compiles_differently()->bool { true } #[cfg(not(overflow_checks))] fn compiles_differently()->bool { false } </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

Related discussion:
text: // substitutions. use crate::check::FnCtxt; use hir::def_id::LocalDefId; use rustc_data_structures::fx::FxHashMap; use rustc_errors::ErrorGuaranteed;
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

Related discussion:
text: use rustc_middle::ty::adjustment::{Adjust, Adjustment, PointerCast}; use rustc_middle::ty::fold::{TypeFoldable, TypeFolder, TypeSuperFoldable}; use rustc_middle::ty::visit::{TypeSuperVisitable, TypeVisitable}; <ins> use rustc_middle::ty::TypeckResults; </ins> use rustc_middle::ty::{self, ClosureSizeProfileData, Ty, TyCtxt}; use rustc_span::symbol::sym; use rustc_span::Span;
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

Related discussion:
text: } } <ins> // (ouz-a 1005988): Normally `[T] : std::ops::Index<usize>` should be normalized // into [T] but currently `Where` clause stops the normalization process for it, // here we compare types of expr and base in a code without `Where` clause they would be equal // if they are not we don't modify the expr, hence we bypass the ICE fn is_builtin_index( &mut self, typeck_results: &TypeckResults<'tcx>, e: &hir::Expr<'_>, base_ty: Ty<'tcx>, index_ty: Ty<'tcx>, ) -> bool { if let Some(elem_ty) = base_ty.builtin_index() { let Some(exp_ty) = typeck_results.expr_ty_opt(e) else {return false;}; let resolved_exp_ty = self.resolve(exp_ty, &e.span); elem_ty == resolved_exp_ty && index_ty == self.fcx.tcx.types.usize } else { false } } </ins> // Similar to operators, indexing is always assumed to be overloaded // Here, correct cases where an indexing expression can be simplified // to use builtin indexing because the index type is known to be
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

Related discussion:
text: ) }); let index_ty = self.fcx.resolve_vars_if_possible(index_ty); <ins> let resolved_base_ty = self.resolve(*base_ty, &base.span); </ins> <del> if base_ty.builtin_index().is_some() && index_ty == self.fcx.tcx.types.usize { </del> <ins> if self.is_builtin_index(&typeck_results, e, resolved_base_ty, index_ty) { </ins> // Remove the method call record typeck_results.type_dependent_defs_mut().remove(e.hir_id); typeck_results.node_substs_mut().remove(e.hir_id);
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

Related discussion:
text: <ins> // compile-flags: -Z mir-opt-level=0 // EMIT_MIR issue_91633.hey.mir_map.0.mir fn hey<T> (it: &[T]) where [T] : std::ops::Index<usize>, { let _ = &it[0]; } // EMIT_MIR issue_91633.bar.mir_map.0.mir fn bar<T> (it: Box<[T]>) where [T] : std::ops::Index<usize>, { let _ = it[0]; } // EMIT_MIR issue_91633.fun.mir_map.0.mir fn fun<T> (it: &[T]) -> &T { let f = &it[0]; f } // EMIT_MIR issue_91633.foo.mir_map.0.mir fn foo<T: Clone> (it: Box<[T]>) -> T { let f = it[0].clone(); f } fn main(){} </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

Related discussion:
text: <ins> // check-pass fn f<T> (it: &[T]) where [T] : std::ops::Index<usize>, { let _ = &it[0]; } fn main(){} </ins>
Code change:
In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .

Related discussion:
text: db.span_note(glob_reexport_span, format!("the name `{}` in the {} namespace is supposed to be publicly re-exported here", name, namespace)); db.span_note(private_item_span, "but the private item here shadows it".to_owned()); } <ins> BuiltinLintDiagnostics::UnusedQualifications { path_span, unqualified_path } => { db.span_suggestion_verbose( path_span, "replace it with the unqualified path", unqualified_path, Applicability::MachineApplicable ); } </ins> } // Rewrap `db`, and pass control to the user. decorate(db)