jiebi/CodeConvo huggingface dataset:
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. -- (requires release mode) <!-- 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. --: 1.70.0-nightly (2023-04-02 ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details labels modify +F-specialization +requires-nightly +requires-incomplete-features
I understand how this ICE can come about, but I frankly cannot reproduce this. can you help out?
Ah, I apparently forgot to list that the ICE requires ; building without optimizations doesn't ICE.
label +F-specialization +requires-nightly +requires-incomplete-features

Discussion:
use rustc_index::bit_set::BitSet; use rustc_middle::mir::visit::{NonMutatingUseContext, PlaceContext, Visitor}; use rustc_middle::mir::{Body, Local, Location, Operand, Terminator, TerminatorKind, RETURN_PLACE}; <del> use rustc_middle::ty::{self, DeducedParamAttrs, ParamEnv, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, DeducedParamAttrs, Ty, TyCtxt}; </ins> use rustc_session::config::OptLevel; /// A visitor that determines which arguments have been mutated. We can't use the mutability field

// see [1]. // // [1]: https://github.com/rust-lang/rust/pull/103172#discussion_r999139997 <ins> let param_env = tcx.param_env_reveal_all_normalized(def_id); </ins> let mut deduced_param_attrs = tcx.arena.alloc_from_iter( body.local_decls.iter().skip(1).take(body.arg_count).enumerate().map( |(arg_index, local_decl)| DeducedParamAttrs { read_only: !deduce_read_only.mutable_args.contains(arg_index) <del> && local_decl.ty.is_freeze(tcx, ParamEnv::reveal_all()), </del> <ins> && local_decl.ty.is_freeze(tcx, param_env), </ins> }, ), );

<ins> // build-pass // compile-flags: -Copt-level=1 --crate-type=lib #![feature(specialization)] //~^ WARN the feature `specialization` is incomplete pub unsafe trait Storage { type Handle; } pub unsafe trait MultipleStorage: Storage {} default unsafe impl<S> Storage for S where S: MultipleStorage {} // Make sure that we call is_freeze on `(S::Handle,)` in the param-env of `ice`, // instead of in an empty, reveal-all param-env. pub fn ice<S: Storage>(boxed: (S::Handle,)) -> (S::Handle,) { boxed } </ins>

<ins> warning: the feature `specialization` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/freeze-on-polymorphic-projection.rs:4:12 | LL | #![feature(specialization)] |            ^^^^^^^^^^^^^^ | = note: see issue #31844 <https://github.com/rust-lang/rust/issues/31844> for more information = help: consider using `min_specialization` instead, which is more stable and complete = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </ins>
Change:
On riscv64gc linux, split-debuginfo ="unpacked" caused error: A dwo section may not contain relocations. For rust 1.64, this error occurs. For rust <=1.64, cargo didn't pass flag to rustc. For rust 1.64, a segmentation fault happens in rustc. For rust < 1.64, it builds fine I think the behavior of rust < 1.64 is correct. The following steps: caused the following failure: No response Related:
Transferred to rust-lang/rust, since this looks to be a compiler issue.
says that LLVM doesn't support this combination of flags. It's unclear to me whether it's impossible or just not implemented yet, but in the meantime, cargo should probably stop passing -C split-debuginfo to proc-macros? there's some mention of in the upstream issue, I'm not sure how that's related.
The report above doesn't mention proc-macros. It seems to happen for normal binaries. The following seems to fail for me: If split-debuginfo isn't supported on this target, then rustc should report that it isn't supported (Cargo already tests for this). I believe that is defined by the field in the target definition.
I'm getting the same issue with when cross compiling for , it seems to be all values except that causes issues.

Discussion:
features: "+m,+a,+f,+d,+c".into(), llvm_abiname: "ilp32d".into(), max_atomic_width: Some(32), <ins> supported_split_debuginfo: Cow::Borrowed(&[SplitDebuginfo::Off]), </ins> ..base::linux_gnu::opts() }, }

features: "+m,+a,+f,+d,+c".into(), llvm_abiname: "ilp32d".into(), max_atomic_width: Some(32), <ins> supported_split_debuginfo: Cow::Borrowed(&[SplitDebuginfo::Off]), </ins> ..base::linux_musl::opts() }, }

<del> use crate::spec::{base, CodeModel, SanitizerSet, Target, TargetOptions}; </del> <ins> use std::borrow::Cow; use crate::spec::{base, CodeModel, SanitizerSet, SplitDebuginfo, Target, TargetOptions}; </ins> pub fn target() -> Target { Target {

llvm_abiname: "lp64d".into(), supported_sanitizers: SanitizerSet::ADDRESS, max_atomic_width: Some(64), <ins> supported_split_debuginfo: Cow::Borrowed(&[SplitDebuginfo::Off]), </ins> ..base::android::opts() }, }

features: "+m,+a,+f,+d,+c".into(), llvm_abiname: "lp64d".into(), max_atomic_width: Some(64), <ins> supported_split_debuginfo: Cow::Borrowed(&[SplitDebuginfo::Off]), </ins> ..base::linux_gnu::opts() }, }

<del> use crate::spec::{base, CodeModel, Target, TargetOptions}; </del> <ins> use std::borrow::Cow; use crate::spec::{base, CodeModel, SplitDebuginfo, Target, TargetOptions}; </ins> pub fn target() -> Target { Target {

features: "+m,+a,+f,+d,+c".into(), llvm_abiname: "lp64d".into(), max_atomic_width: Some(64), <ins> supported_split_debuginfo: Cow::Borrowed(&[SplitDebuginfo::Off]), </ins> ..base::linux_musl::opts() }, }
Change:
Put the following code in a new crate's and call 'cargo init'. Then 'cargo c' will ICE. I've tried to reduce further but it seems like if I remove any random line (even if it is a comment) the ICE goes away. <!-- 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
I noticed there is an older bug that is probably the same: .
So like I said this ICE is extremely sensitive to the exact number of characters and lines. The contents of those lines seems to matter less; it is possible to replace most comment and identifier characters with another character (I tried 'x') as long as the total number of characters stays the same. Likewise, a tab can be replaced with a space. The code that triggers is the last code line in this function (from ): withspaninterner calls a function on the SpanInterner it gets from withsessionglobals which gets it from thread-local-storage A SpanInterner wraps a FxIndexSet of SpanData: which is just an indexmap::IndexSet with the FxHasher () The indexmap version is "1.9.2" () The latest version is 1.9.3, but it does not seem to contain any relevant changes (). indexmap uses hashbrown for its hashtable, which may mean that this bug ultimately comes from hashbrown.
A bug in hashbrown is very unlikely. Do you have a backtrace with symbol names? This may also come from incorrect logic in .
Are you able to reproduce the issue given my test case? Can you explain what goes wrong?

Discussion:
#[inline] pub fn ctxt(self) -> SyntaxContext { let ctxt_or_tag = self.ctxt_or_tag as u32; <del> if ctxt_or_tag <= MAX_CTXT { if self.len_or_tag == LEN_TAG || self.len_or_tag & PARENT_MASK == 0 { // Inline format or interned format with inline ctxt. SyntaxContext::from_u32(ctxt_or_tag) </del> <ins> // Check for interned format. if self.len_or_tag == LEN_TAG { if ctxt_or_tag == CTXT_TAG { // Fully interned format. let index = self.base_or_index; with_span_interner(|interner| interner.spans[index as usize].ctxt) </ins> } else { <del> // Inline format or interned format with inline parent. // We know that the SyntaxContext is root. SyntaxContext::root() </del> <ins> // Interned format with inline ctxt. SyntaxContext::from_u32(ctxt_or_tag) </ins> } <ins> } else if self.len_or_tag & PARENT_MASK == 0 { // Inline format with inline ctxt. SyntaxContext::from_u32(ctxt_or_tag) </ins> } else { <del> // Interned format. let index = self.base_or_index; with_span_interner(|interner| interner.spans[index as usize].ctxt) </del> <ins> // Inline format with inline parent. // We know that the SyntaxContext is root. SyntaxContext::root() </ins> } } }
Change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --When building with on nightly rust the resulting binary will segfault. This does not occur when built with stable rust. This behavior change appears to be gated by lto="thin". I tried this code: I expected to see this happen: alacritty to startup as occurs with Instead, this happened: compiled program segfaults stable-x8664-unknown-linux-gnu unchanged - rustc 1.68.2 ( 2023-03-27) nightly-x8664-unknown-linux-gnu unchanged - rustc 1.70.0-nightly ( 2023-04-11) : </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --This appears to be triggered by lto being set to "thin" in See alacritty issues: and for investigation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
NB This also appears to require that optimization is turned on to reproduce.
Hm fun, I can reproduce this with in alacritty git on x86
I tried to bisect this ` and t looks like this regressed in nightly-2023-03-26, so probably llvm upgrade? rip :(
WG-prioritization assigning priority (). label -I-prioritize +P-high
Upstream candidate patch: . Here is a reproduction example. If you change from to this will work fine.
claim

Discussion:
<del> Subproject commit 585a6eb3ebf7c40fd7c1b23e3ece557b3cc2aa36 </del> <ins> Subproject commit ea6fa9c2d43aaf0f11559719eda9b54d356d5416 </ins>
Change:
I'm trying to cross-compile the rust compiler to x86_64 on an M1 macOS machine with LTO enabled and ran into a compile error while building the stage2 compiler artifact: I also tried cross-compiling aarch64 on an Intel Mac and ran into the same issue. Here is the I used: It seems that is enabling LTO for proc-macro crates, but only when cross-compiling?
sorry for pinging, are there any updates on this issue? This bug is easily reproducible, and is preventing cross compiling the toolchain with LTO enabled.
I haven't had time to look into this, no. You can always disable LTO as a workaround.
This problem also appears when just the vendor of the target tripple changes (i.e. ).
Thank you for the additional feedback, will look into this issue in couple weeks.

Discussion:
codegen_llvm_lto_dylib = lto cannot be used for `dylib` crate type without `-Zdylib-lto` <ins> codegen_llvm_lto_proc_macro = lto cannot be used for `proc-macro` crate type without `-Zdylib-lto` </ins> codegen_llvm_missing_features = add the missing features in a `target_feature` attribute

self, bitcode_section_name, save_temp_bitcode, CodegenDiagnosticsStage, DiagnosticHandlers, }; use crate::errors::{ <del> DynamicLinkingWithLTO, LlvmError, LtoBitcodeFromRlib, LtoDisallowed, LtoDylib, </del> <ins> DynamicLinkingWithLTO, LlvmError, LtoBitcodeFromRlib, LtoDisallowed, LtoDylib, LtoProcMacro, </ins> }; use crate::llvm::{self, build_string}; use crate::{LlvmCodegenBackend, ModuleLlvm};

pub fn crate_type_allows_lto(crate_type: CrateType) -> bool { match crate_type { <del> CrateType::Executable | CrateType::Dylib | CrateType::Staticlib | CrateType::Cdylib => true, CrateType::Rlib | CrateType::ProcMacro => false, </del> <ins> CrateType::Executable | CrateType::Dylib | CrateType::Staticlib | CrateType::Cdylib | CrateType::ProcMacro => true, CrateType::Rlib => false, </ins> } }

diag_handler.emit_err(LtoDylib); return Err(FatalError); } <ins> } else if *crate_type == CrateType::ProcMacro { if !cgcx.opts.unstable_opts.dylib_lto { diag_handler.emit_err(LtoProcMacro); return Err(FatalError); } </ins> } }

pub(crate) struct LtoDylib; #[derive(Diagnostic)] <ins> #[diag(codegen_llvm_lto_proc_macro)] pub(crate) struct LtoProcMacro; #[derive(Diagnostic)] </ins> #[diag(codegen_llvm_lto_bitcode_from_rlib)] pub(crate) struct LtoBitcodeFromRlib { pub llvm_err: String,
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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing assign command in failed: ...' assign' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
searched toolchains nightly-2023-04-13 through nightly-2023-04-17 Regression in nightly-2023-04-15 searched toolchains through Regression in Attempting to search unrolled perf builds Found commits ["", "", "", "", "", "", "", "", ""] Regression in cc
claim
Thanks, I'll take a look at this

Discussion:
obligation: &TraitObligation<'tcx>, candidates: &mut SelectionCandidateSet<'tcx>, ) { <del> if obligation.has_non_region_param() { </del> <ins> if obligation.predicate.has_non_region_param() { </ins> return; }

<ins> // check-pass #![crate_type = "lib"] #![feature(transmutability)] use std::mem::BikeshedIntrinsicFrom; pub struct Context; pub fn is_maybe_transmutable<Src, Dst>() where Dst: BikeshedIntrinsicFrom<Src, Context>, { } // The `T` here should not have any effect on checking // if transmutability is allowed or not. fn function_with_generic<T>() { is_maybe_transmutable::<(), ()>(); } </ins>
Change:
When running for example, x.py would previously show the build (cargo) output when building cargo during , but that is no longer the case. Is that intentional? `
It's not intentional AFAIK, but I don't see a recent PR that could have broken this off the top of my head. Do you have a commit/timeframe where this worked correctly?
Hmm I would guess it still worked last weekend?
Are you sure cargo is actually being built? makes me think it's using cached stage 2 artifacts.
Might be
Yes, I can see rustc building cargo and its deps in htop while x.py does not print any updates :sweat_smile:
oh lol that would do it cc
Sounds like we do need there? I'll put it back then!
Is there not a way of doing things?
Yes, there's a try_run, that would be best.

Discussion:
builder.info(&msg); let mut cargo = Command::from(cargo); <del> let is_expected = builder.try_run_quiet(&mut cargo); </del> <ins> let is_expected = builder.try_run(&mut cargo); </ins> builder.save_toolstate( tool,
Change:
I believe the old behavior from nightly-2023-04-19 is correct. The repro has nothing to do with trait impls so I believe was not supposed to have affected it.
Bisects to .
How on earth did that happen? It was like a five-line change. :laughing: EDIT: got a fix, will post soon.
Probably something to do with the hygeine of the span on the versus the . if you can't fix this then ping me and I'll look at it, but we probably should fix it sooner than later.
Actually, you're probably right.
Oh, no, that's not it. You're missing a call to in the visitor.

Discussion:
} } <ins> fn assoc_item_in_trait_impl(cx: &LateContext<'_>, ii: &hir::ImplItem<'_>) -> bool { let item = cx.tcx.associated_item(ii.owner_id); item.trait_item_def_id.is_some() } </ins> declare_lint! { /// The `non_camel_case_types` lint detects types, variants, traits and /// type parameters that don't have camel case names.

// trait impls where we should have warned for the trait definition already. ast::ItemKind::Impl(box ast::Impl { of_trait: None, items, .. }) => { for it in items { <ins> // FIXME: this doesn't respect `#[allow(..)]` on the item itself. </ins> if let ast::AssocItemKind::Type(..) = it.kind { self.check_case(cx, "associated type", &it.ident); }

hir::ItemKind::Const(..) => { NonUpperCaseGlobals::check_upper_case(cx, "constant", &it.ident); } <del> // we only want to check inherent associated consts, trait consts // are linted at def-site. hir::ItemKind::Impl(hir::Impl { of_trait: None, items, .. }) => { for it in *items { if let hir::AssocItemKind::Const = it.kind { NonUpperCaseGlobals::check_upper_case(cx, "associated constant", &it.ident); } } } </del> _ => {} } }

} } <ins> fn check_impl_item(&mut self, cx: &LateContext<'_>, ii: &hir::ImplItem<'_>) { if let hir::ImplItemKind::Const(..) = ii.kind && !assoc_item_in_trait_impl(cx, ii) { NonUpperCaseGlobals::check_upper_case(cx, "associated constant", &ii.ident); } } </ins> fn check_pat(&mut self, cx: &LateContext<'_>, p: &hir::Pat<'_>) { // Lint for constants that look like binding identifiers (#7526) if let PatKind::Path(hir::QPath::Resolved(None, ref path)) = p.kind {

<ins> // check-pass #![deny(warnings)] pub struct Struct; impl Struct { #[allow(non_upper_case_globals)] pub const Const: () = (); } fn main() {} </ins>
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
That second function can be named anything, for the record. e.g.

Discussion:
let mut visitor = HirPlaceholderCollector::default(); visitor.visit_ty(ty); let mut diag = bad_placeholder(tcx, visitor.0, "return type"); let ret_ty = fn_sig.output(); <ins> // Don't leak types into signatures unless they're nameable! // For example, if a function returns itself, we don't want that // recursive function definition to leak out into the fn sig. let mut should_recover = false; </ins> if let Some(ret_ty) = ret_ty.make_suggestable(tcx, false) { diag.span_suggestion( ty.span,

ret_ty, Applicability::MachineApplicable, ); <del> } else if matches!(ret_ty.kind(), ty::FnDef(..)) && let Some(fn_sig) = ret_ty.fn_sig(tcx).make_suggestable(tcx, false) { diag.span_suggestion( ty.span, "replace with the correct return type", fn_sig, Applicability::MachineApplicable, ); </del> <ins> should_recover = true; </ins> } else if let Some(sugg) = suggest_impl_trait(tcx, ret_ty, ty.span, def_id) { diag.span_suggestion( ty.span,

https://doc.rust-lang.org/book/ch13-01-closures.html", ); } <del> diag.emit(); ty::Binder::dummy(fn_sig) </del> <ins> let guar = diag.emit(); if should_recover { ty::Binder::dummy(fn_sig) } else { ty::Binder::dummy(tcx.mk_fn_sig( fn_sig.inputs().iter().copied(), tcx.ty_error(guar), fn_sig.c_variadic, fn_sig.unsafety, fn_sig.abi, )) } </ins> } None => icx.astconv().ty_of_fn( hir_id,

<ins> fn a() -> _ { //~^ ERROR the placeholder `_` is not allowed within types on item signatures for return types &a } fn b() -> _ { //~^ ERROR the placeholder `_` is not allowed within types on item signatures for return types &a } fn main() {} </ins>

<ins> error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types --> $DIR/bad-recursive-type-sig-infer.rs:1:11 | LL | fn a() -> _ { |           ^ not allowed in type signatures error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types --> $DIR/bad-recursive-type-sig-infer.rs:6:11 | LL | fn b() -> _ { |           ^ not allowed in type signatures error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0121`. </ins>
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. --Compiling the following in release on the recent nightlies causes a crash. Note that compiling in debug succeeds. <!-- 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. --: If the function is uncommented, rustc instead crashes with an illegal instruction searched nightlies: from nightly-2023-04-17 to nightly-2023-04-23 regressed nightly: nightly-2023-04-18 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
This bisects to a MIR inlining PR, but the actual bug here is related to lowering of . It's possible to write code that gets lowered to invalid LLVM IR without MIR inlining, but the code required is rather contrived. This has been extensively discussed on the Zulip: https://rust- I'm surprised nobody else opened an issue for this. Thanks!

Discussion:
<ins> //@ build-pass //@ compile-flags: -Copt-level=3 // regression test for https://github.com/rust-lang/rust/issues/110722 // in --release we were optimizing to invalid bitcasts, due to a combination of MIR inlining and // mostly bad repr(simd) lowering which prevented even basic splats from working #![crate_type = "rlib"] #![feature(portable_simd)] use std::simd::*; use std::simd::num::*; pub unsafe fn mask_to_array(mask: u8) -> [i32; 8] { let mut output = [0; 8]; let m = masksizex8::from_bitmask(mask as _); output.copy_from_slice(&m.to_int().cast::<i32>().to_array()); output } </ins>

<ins> //@ build-pass //@ compile-flags: -Copt-level=3 //@ only-x86_64 // ignore-tidy-linelength // regression test for https://github.com/rust-lang/rust/issues/110707 // in --release we were optimizing to invalid bitcasts, due to a combination of MIR inlining and // mostly bad repr(simd) lowering which prevented even basic splats from working #![crate_type = "rlib"] #![feature(portable_simd)] use std::simd::*; use std::arch::x86_64::*; #[target_feature(enable = "sse4.1")] pub unsafe fn fast_round_sse(i: f32x8) -> f32x8 { let a = i.to_array(); let [low, high]: [[f32; 4]; 2] = unsafe { std::mem::transmute::<[f32; 8], [[f32; 4]; 2]>(a) }; let low = f32x4::from(_mm_round_ps::<{_MM_FROUND_TO_NEAREST_INT | _MM_FROUND_NO_EXC}>(f32x4::from_array(low).into())); let high = f32x4::from(_mm_round_ps::<{_MM_FROUND_TO_NEAREST_INT | _MM_FROUND_NO_EXC}>(f32x4::from_array(high).into())); let a: [f32; 8] = unsafe { std::mem::transmute::<[[f32; 4]; 2], [f32; 8]>([low.to_array(), high.to_array()]) }; f32x8::from_array(a) } </ins>