jiebi/CodeConvo huggingface dataset:
Change:
Previously we had and where the first was essentially line-numbers only and the second was the full local variables etc. information. was replaced by and the former was removed. A equivalent has lower compilation and runtime overhead.
(Background: said he removed because he didn't realise there was a difference between it and .)
The differences between the old and options can be found as part of . Sorry the diff is large, I assumed that these were the same thing and didn't realize they served different purposes!
Maybehaps -Z debug-info should be renamed to something like -Z line-info? Richard Diamond , Alex Crichton :
('cause I didn't know either) Richard Diamond , Richard Diamond < :
Clang has -gline-tables-only, which seems like reasonable prior art.
GCC has where level is 0-3: means no debug info. is equivalent to . is the same as just . has some more debug info related to C macros. I think that's rather nice and short to type but one has to remember more what's what. I'm not against but I think I'd prefer with being the same as .
I just now saw that there is no more distinction between debug-info and extra-debug-info. Thanks for linking the change set here. Some of these changes need to be reverted/adapted if we want to have a line-tables-only version again (which shouldn't be much of a problem though).

Discussion:
<ins> // Copyright 2013-2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // ignore-android: FIXME(#10381) // compile-flags:-g1 // Make sure functions have proper names // debugger:info functions // check:static void limited-debuginfo::main(); // check:static void limited-debuginfo::some_function(); // check:static void limited-debuginfo::some_other_function(); // check:static void limited-debuginfo::zzz(); // debugger:rbreak zzz // debugger:run // Make sure there is no information about locals // debugger:finish // debugger:info locals // check:No locals. // debugger:continue #[allow(unused_variable)]; struct Struct { a: i64, b: i32 } fn main() { some_function(101, 202); } fn zzz() {()} fn some_function(a: int, b: int) { let some_variable = Struct { a: 11, b: 22 }; let some_other_variable = 23; zzz(); } fn some_other_function(a: int, b: int) -> bool { true } </ins>  No newline at end of file
Change:
I tried this code: I expected to see this happen: these two pieces of code produced the same assembly Instead, this happened: the first version generates worse code It most recently worked on: 1.76 :
The main branch of LLVM may have fixed this issue:
Whoops, compared against 1.76, my mistake.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
I have bisected to (). But I'm not sure if this match the backport rules. I have submitted , but it may be rejected.
label llvm-fixed-upstream

Discussion:
<del> Subproject commit 0af6c732ec6ca189cd7725e4a7d4290793046e83 </del> <ins> Subproject commit af8f9eb61a2ad4ee1f2d3f46d157b93a47c6a4bf </ins>

<ins> //@ compile-flags: -O //@ min-llvm-version: 18.1.3 #![crate_type = "lib"] #![no_std] // The code is from https://github.com/rust-lang/rust/issues/122805. // Ensure we do not generate the shufflevector instruction // to avoid complicating the code. // CHECK-LABEL: define{{.*}}void @convert( // CHECK-NOT: shufflevector // CHECK: insertelement <8 x i16> // CHECK-NEXT: insertelement <8 x i16> // CHECK-NEXT: insertelement <8 x i16> // CHECK-NEXT: insertelement <8 x i16> // CHECK-NEXT: insertelement <8 x i16> // CHECK-NEXT: insertelement <8 x i16> // CHECK-NEXT: insertelement <8 x i16> // CHECK-NEXT: insertelement <8 x i16> // CHECK-NEXT: store <8 x i16> // CHECK-NEXT: ret void #[no_mangle] pub fn convert(value: [u16; 8]) -> [u8; 16] { let addr16 = [ value[0].to_be(), value[1].to_be(), value[2].to_be(), value[3].to_be(), value[4].to_be(), value[5].to_be(), value[6].to_be(), value[7].to_be(), ]; unsafe { core::mem::transmute::<_, [u8; 16]>(addr16) } } </ins>
Change:
This is with built as a dev branch, so it's possible this is already fixed in nightly. I locally computed the command it was running, and it's: Since the input file is , this shouldn't technically require more information than what I've gathered, but I'll try to minimize this soon if nobody else immediately knows the answer.
Attached the ICE txt in case someone gets to it before I do.
We shouldn't be unwrapping the array size as a , but actually respect the size of machine.

Discussion:
"{}", &len.try_to_scalar() .unwrap() <del> .to_u64() .unwrap_or_else(|_| panic!("failed to convert length to u64")) </del> <ins> .to_target_usize(&tcx.data_layout) .expect("Array lens are defined in usize") </ins> ); s.push_str(&encode_ty(tcx, *ty0, dict, options)); compress(dict, DictKey::Ty(ty, TyQ::None), &mut s);
Change:
<!-- [31mICE[0m: Rustc '-Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: Closure arguments are not passed as a tuple', 'error: internal compiler error: Closure arguments are not passed as a tuple' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by [analysis] running analysis passes on this crate --
This one also seems to be cc

Discussion:
) -> Result<(), &'static str> { let tcx = self.tcx; <ins> if let Some(_) = callee_body.tainted_by_errors { return Err("Body is tainted"); } </ins> let mut threshold = if self.caller_is_inline_forwarder { self.tcx.sess.opts.unstable_opts.inline_mir_forwarder_threshold.unwrap_or(30) } else if cross_crate_inlinable {

<del> //@ compile-flags: -Zvalidate-mir -Zinline-mir=yes //@ known-bug: #122909 use std::sync::{Arc, Context, Weak}; pub struct WeakOnce<T>(); impl<T> WeakOnce<T> { extern "rust-call" fn try_get(&self) -> Option<Arc<T>> {} pub fn get(&self) -> Arc<T> { self.try_get() .unwrap_or_else(|| panic!("Singleton {} not available", std::any::type_name::<T>())) } } </del>

<ins> //@ compile-flags: -Zvalidate-mir -Zinline-mir=yes #![feature(unboxed_closures)] use std::sync::Arc; pub struct WeakOnce<T>(); //~^ ERROR type parameter `T` is never used impl<T> WeakOnce<T> { extern "rust-call" fn try_get(&self) -> Option<Arc<T>> {} //~^ ERROR functions with the "rust-call" ABI must take a single non-self tuple argument //~| ERROR mismatched types pub fn get(&self) -> Arc<T> { self.try_get() .unwrap_or_else(|| panic!("Singleton {} not available", std::any::type_name::<T>())) } } fn main() {} </ins>

<ins> error[E0392]: type parameter `T` is never used --> $DIR/inline-tainted-body.rs:7:21 | LL | pub struct WeakOnce<T>(); |                     ^ unused type parameter | = help: consider removing `T`, referring to it in a field, or using a marker such as `PhantomData` = help: if you intended `T` to be a const parameter, use `const T: /* Type */` instead error: functions with the "rust-call" ABI must take a single non-self tuple argument --> $DIR/inline-tainted-body.rs:11:35 | LL |     extern "rust-call" fn try_get(&self) -> Option<Arc<T>> {} |                                   ^^^^^ error[E0308]: mismatched types --> $DIR/inline-tainted-body.rs:11:45 | LL |     extern "rust-call" fn try_get(&self) -> Option<Arc<T>> {} |                           -------           ^^^^^^^^^^^^^^ expected `Option<Arc<T>>`, found `()` |                           | |                           implicitly returns `()` as its body has no tail or `return` expression | = note:   expected enum `Option<Arc<T>>` found unit type `()` error: aborting due to 3 previous errors Some errors have detailed explanations: E0308, E0392. For more information about an error, try `rustc --explain E0308`. </ins>
Change:
tries to and then expects to find a rustc in that can compile stuff. This appears to have worked, but does not work anymore. only contains the linker script, it does not contain the actual library. I'm not sure how bootstrapping works with that, but uh, it does somehow!
Ah, contains the actual libLLVM.
I don't know whether this is intended or accidental, but something is up. I'm going to change backtrace to use instead, which should hopefully still work.
I worked around it in It's probably the proper fix anyways. Still weird to have this, so I'll leave the issue open for you to figure out whether this is good and whether it matters.
Nevermind, using that doesn't appear to work correctly, I suspect that this does need . I don't really know the difference tbh so I'm happy to know what would be correct.
This is a recent regression from the bootstrap compiler bump PR .
Has anyone figured out what needs to be copied where and how? The conversation seems a bit spread out over different issues/PRs so I'm wondering what the current status is?
Not yet, I will check it around tomorrow.
Thanks! No rush, I was just uncertain where things stood.

Discussion:
t!(fs::create_dir_all(&sysroot_bin_dir)); builder.cp_link_r(&stage0_bin_dir, &sysroot_bin_dir); <del> // Copy all *.so files from stage0/lib to stage0-sysroot/lib </del> <ins> // Copy all files from stage0/lib to stage0-sysroot/lib </ins> let stage0_lib_dir = builder.out.join(host).join("stage0/lib"); if let Ok(files) = fs::read_dir(stage0_lib_dir) { for file in files { let file = t!(file); let path = file.path(); <del> if path.is_file() && is_dylib(&file.file_name().into_string().unwrap()) { </del> <ins> if path.is_file() { </ins> builder .copy_link(&path, &sysroot.join("lib").join(path.file_name().unwrap())); }
Change:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: self-type for ObjectPick never dereferenced to an object', 'error: internal compiler error: self-type for ObjectPick never dereferenced to an object' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
bisects to cc

Discussion:
use rustc_middle::ty::adjustment::{AllowTwoPhase, AutoBorrow, AutoBorrowMutability}; use rustc_middle::ty::fold::TypeFoldable; use rustc_middle::ty::{ <del> self, GenericArgs, GenericArgsRef, GenericParamDefKind, Ty, TyCtxt, UserArgs, UserType, </del> <ins> self, GenericArgs, GenericArgsRef, GenericParamDefKind, Ty, TyCtxt, TypeVisitableExt, UserArgs, UserType, </ins> }; use rustc_middle::{bug, span_bug}; use rustc_span::{Span, DUMMY_SP};

probe::ObjectPick => { let trait_def_id = pick.item.container_id(self.tcx); <ins> // This shouldn't happen for non-region error kinds, but may occur // when we have error regions. Specifically, since we canonicalize // during method steps, we may successfully deref when we assemble // the pick, but fail to deref when we try to extract the object // type from the pick during confirmation. This is fine, we're basically // already doomed by this point. if self_ty.references_error() { return ty::GenericArgs::extend_with_error(self.tcx, trait_def_id, &[]); } </ins> self.extract_existential_trait_ref(self_ty, |this, object_ty, principal| { // The object data has no entry for the Self // Type. For the purposes of this method call, we

<del> //@ known-bug: #122914 use std::future::Future; use std::pin::Pin; impl<'a, F> Poll { fn project<'_>(self: Pin<&'pin mut Future>) -> Projection<'pin, 'a, F> { me.local_set.with(|| { let _ = self.poll(cx); }) } } </del>

<ins> // Fix for issue: #122914 use std::future::Future; use std::pin::Pin; fn project(x: Pin<&'missing mut dyn Future<Output = ()>>) { //~^ ERROR use of undeclared lifetime name `'missing` let _ = x.poll(todo!()); } fn main() {} </ins>

<ins> error[E0261]: use of undeclared lifetime name `'missing` --> $DIR/dont-ice-on-object-lookup-w-error-region.rs:6:20 | LL | fn project(x: Pin<&'missing mut dyn Future<Output = ()>>) { |           -        ^^^^^^^^ undeclared lifetime |           | |           help: consider introducing lifetime `'missing` here: `<'missing>` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0261`. </ins>
Change:
Currently, core::ffi::c_char on AIX is i8, but AFAIK, the default of this platform is unsigned (u8). : Clang: Rust: cc () <!-- 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. --:
I opened and as drafts to fix this, but I want feedback from the target maintainers before undrafting/merging them.
Ideally, we could detect such a problem in CI by . However, AFAIK, most tier3 targets are not checked at all in CI at this time (), so that would need to be fixed first.
Yes, we should follow clang on AIX's behavior.

Discussion:
any(target_arch = "aarch64", target_arch = "riscv64") ), all(target_os = "nto", target_arch = "aarch64"), <del> target_os = "horizon" </del> <ins> target_os = "horizon", target_os = "aix", </ins> ))] { pub type c_char = u8; } else {
Change:
Compiling project with causes the following compilation error: See this .
cc target maintainer
I guess has the same issue? This got broken by ("unix time module now return result") which dropped I guess the way forward is to make use instead. I'm wondering if there is a way to make sure that this kind of breakage doesn't happen before a rustc release?
Our platform support policy is to avoid blocking PRs on whether tier 3 platforms build, because tier 3 platforms are not required to build.
Sure, I'm not saying to block PRs, but I'm wondering about somehow getting notified quickly enough to be able to react before a rustc release.
(as in: getting the break notice from a getrandom CI build a dozen days after the merge does not look that robust)
Hm. Does the Rust compiler for hurd get built from a stable or beta branch of rustc? My understanding was that tier 3 targets generally used the nightly compiler in any case.
In Debian we will use the stable releases to compile all rust-needing Debian packages, as the Debian policy requires.
The breaking commit is not in the current 1.77 release but is in the 1.78 beta. It will not be in a stable release for another 5 weeks-ish. Would you like your PR that fixes it to be beta-nominated, so that it gets backported and is in the stable release of 1.78?
Yes, please.
I recommend you set up a daily/weekly job on your side building master to check for regressions. ( may fix this)

Discussion:
#[cfg(any(target_os = "horizon", target_os = "hurd"))] pub fn modified(&self) -> io::Result<SystemTime> { <del> Ok(SystemTime::from(self.stat.st_mtim)) </del> <ins> SystemTime::new(self.stat.st_mtim.tv_sec as i64, self.stat.st_mtim.tv_nsec as i64) </ins> } #[cfg(not(any(

#[cfg(any(target_os = "horizon", target_os = "hurd"))] pub fn accessed(&self) -> io::Result<SystemTime> { <del> Ok(SystemTime::from(self.stat.st_atim)) </del> <ins> SystemTime::new(self.stat.st_atim.tv_sec as i64, self.stat.st_atim.tv_nsec as i64) </ins> } #[cfg(any(
Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --cc . I tried this code: I expected to see this happen: no warnings Instead, this happened: <!-- 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. --:

Discussion:
(iter, UnusedDelimsCtx::ForIterExpr, true, None, Some(body.span.lo()), true) } <del> Match(ref head, ..) if Self::LINT_EXPR_IN_PATTERN_MATCHING_CTX => { </del> <ins> Match(ref head, _, ast::MatchKind::Prefix) if Self::LINT_EXPR_IN_PATTERN_MATCHING_CTX => { </ins> let left = e.span.lo() + rustc_span::BytePos(5); (head, UnusedDelimsCtx::MatchScrutineeExpr, true, Some(left), None, true) }

<ins> //@ check-pass #![feature(postfix_match)] fn main() { (&1).match { a => a }; (1 + 2).match { b => b }; } </ins>
Change:
This is fairly easy to reproduce: (The just serves to make this take less long.) The second command shouldn't have to build anything, just run the tests. But somehow it actually rebuilds miri, cargo-miri, and rustdoc. This is a recent regression introduced by Somehow building rustdoc seems to destroy the build cache for miri and cargo-miri, and vice versa. Cc
Building rustdoc using the stage 1 compiler causes this, which is weird. I suspect that previously invoked miri related steps may have broken the cache somehow. Or we may need to improve/enhance .
I've just found this in the rustdoc sources: Maybe Miri should do something similar. Then should also Do The Right Thing without adding (since actually stage 1 would be the right stage to use). And maybe then the rebuilding issue also vanishes. Or maybe that's unrelated, not sure.
That would work actually, it seems to be the right path.
Unfortunately it doesn't help. We probably still should do it. But somehow building rustdoc seems to delete the build cache for Miri and cargo-miri, and vice versa.
Cargo has this to say about why things are rebuilt: And indeed, rustdoc sets That's a bit annoying to have this set in the tool, it means each tool needs to repeat the same logic.
iirc rustdoc sets that to not dirt the compiler builds, we should probably handle that more globally.
Yup, that's what the last commit in does now.
This issue is back now, I am again seeing rebuilds of Miri and rustdoc all the time. Did something change in bootstrap?
Couldn't reproduce it on my side with default config (without the file). There might be a specific option that triggers this. Can you share your config?
Seems like it only happens with caused by different rustflags.
The command I was running is . Running that command multiple times in a row rebuilds miri and rustdoc each time. Adding avoids that.
Found the problem and opened . I will try to add a bootstrap test (around this weekend) for ensuring this never happens again.
Thanks for the quick debugging :)

Discussion:
// See https://github.com/rust-lang/rust/issues/116538 cargo.rustflag("-Zunstable-options"); <ins> // `-Zon-broken-pipe=kill` breaks cargo tests if !path.ends_with("cargo") { // If the output is piped to e.g. `head -n1` we want the process to be killed, // rather than having an error bubble up and cause a panic. cargo.rustflag("-Zon-broken-pipe=kill"); } </ins> cargo }

features.push("jemalloc".to_string()); } <del> let mut cargo = prepare_tool_cargo( </del> <ins> // NOTE: Never modify the rustflags here, it breaks the build cache for other tools! let cargo = prepare_tool_cargo( </ins> builder, build_compiler, Mode::ToolRustc,

features.as_slice(), ); <del> // If the rustdoc output is piped to e.g. `head -n1` we want the process // to be killed, rather than having an error bubble up and cause a // panic. cargo.rustflag("-Zon-broken-pipe=kill"); </del> let _guard = builder.msg_tool( Kind::Build, Mode::ToolRustc,
Change:
Previously, clippy was using from , but since , it now prioritizes checking first. We can now set path into and avoid appending it to the chain. In the bootstrap, we have this piece of code which adds into . As indicated by the FIXME note, wasn't merged at the time. Now that we can do so, set instead of and remove the FIXME note. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
There's more weird stuff going on here... On Windows, is PATH, so this sets the PATH and then immediately overwrites it again with a different value...?!? This almost looks like it may want to call or . It's not quite equivalent though. Unfortunately there are no comments explaining why it does what it does... Cc who wrote that code, but it's been two years so not sure if they remember.^^
Yep, sorry, absolutely no clue what that code is meant to do. It's very likely that I copied that from somewhere else during the initial stages of "try everything and see if any of it works", or copied some part of that, and eventually modified to set . I have also unfortunately forgotten all of the context of the bootstrap code here, how it's meant to flow, and what it's meant to set for other programs, so I will not be of any help here :c I will try to check my messages with jyn, who i was talking to a lot about this at the time, and trying many things at their suggestion, to see if I can find any useful history.

Discussion:
} pub fn cargo_clippy_cmd(&self, run_compiler: Compiler) -> Command { <del> let initial_sysroot_bin = self.initial_rustc.parent().unwrap(); // Set PATH to include the sysroot bin dir so clippy can find cargo. // FIXME: once rust-clippy#11944 lands on beta, set `CARGO` directly instead. let path = t!(env::join_paths( // The sysroot comes first in PATH to avoid using rustup's cargo. std::iter::once(PathBuf::from(initial_sysroot_bin)) .chain(env::split_paths(&t!(env::var("PATH")))) )); </del> if run_compiler.stage == 0 { // `ensure(Clippy { stage: 0 })` *builds* clippy with stage0, it doesn't use the beta clippy. let cargo_clippy = self.build.config.download_clippy(); let mut cmd = Command::new(cargo_clippy); <del> cmd.env("PATH", &path); </del> <ins> cmd.env("CARGO", &self.initial_cargo); </ins> return cmd; }

let mut cmd = Command::new(cargo_clippy); cmd.env(helpers::dylib_path_var(), env::join_paths(&dylib_path).unwrap()); <del> cmd.env("PATH", path); </del> <ins> cmd.env("CARGO", &self.initial_cargo); </ins> cmd }
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 --
probably cc
yep yep yep, I got it :) claim

Discussion:
}) .map(|pred| { tcx.fold_regions(pred, |r, _| match *r { <del> ty::ReVar(vid) => vid_to_region[&vid], </del> <ins> // FIXME: Don't `unwrap_or`, I think we should panic if we encounter an infer var that // we can't map to a concrete region. However, `AutoTraitFinder` *does* leak those kinds // of `ReVar`s for some reason at the time of writing. See `rustdoc-ui/` tests. // This is in dire need of an investigation into `AutoTraitFinder`. ty::ReVar(vid) => vid_to_region.get(&vid).copied().unwrap_or(r), </ins> ty::ReEarlyParam(_) | ty::ReStatic | ty::ReBound(..) | ty::ReError(_) => r, <ins> // FIXME(#120606): `AutoTraitFinder` can actually leak placeholder regions which feels // incorrect. Needs investigation. </ins> ty::ReLateParam(_) | ty::RePlaceholder(_) | ty::ReErased => { bug!("unexpected region kind: {r:?}") }

<ins> // We used to ICE here while trying to synthesize auto trait impls. // issue: 112242 //@ check-pass //@ compile-flags: -Znormalize-docs pub trait MyTrait<'a> { type MyItem; } pub struct Inner<Q>(Q); pub struct Outer<Q>(Inner<Q>); impl<'a, Q> std::marker::Unpin for Inner<Q> where Q: MyTrait<'a>, <Q as MyTrait<'a>>::MyItem: Copy, { } </ins>

<ins> // We used to ICE here while trying to synthesize auto trait impls. // issue: 123370 //@ check-pass pub struct Inner<'a, Q>(&'a (), Q); pub struct Outer<'a, Q>(Inner<'a, Q>); impl<'a, Q: Trait<'a>> std::marker::Unpin for Inner<'static, Q> {} pub trait Trait<'a> {} </ins>