jiebi/CodeConvo huggingface dataset:
Change:
Passing rustc the flag and passing may produce different files (that is, outputs). This is true of rust-core (see below), though was not the case for a simpler ("Hello, world!") test file. Test script: Diff output indicates binary files differ. Tested with , rust-core on . rustc compiled from master on Arch Linux. If this is, in fact, expected behavior- sorry for the trouble, unexpected to me.
Can you provide a diff between the outputs? This is likely a known issue, but I would like to be sure.
.bc is a binary format, so just gives "Binary files and differ" as its output. On my machine, is 19K and is 62K. I'm not familiar enough with the format to extract much more data.
I note the difference persists when the second line is (two separate flags), though both produce both artifacts.
Can you pass and diff those outputs?
With emit flags as and respectively, there is no difference in and (according to diff.)
It seems that every bytecode is invalid only when a rlib is produced. It stopped working between rust-git-0.9.1301 and 1362 (shortly before 2014-02-23 15:37:05 -0800). Going back thorugh the log, I found I believe that creates deflated bytecode. Perhaps should be stored with extension or .

Discussion:
// For LTO purposes, the bytecode of this library is also inserted // into the archive. let bc = obj_filename.with_extension("bc"); <ins> let bc_deflated = obj_filename.with_extension("bc.deflate"); </ins> match fs::File::open(&bc).read_to_end().and_then(|data| { <del> fs::File::create(&bc).write(flate::deflate_bytes(data).as_slice()) </del> <ins> fs::File::create(&bc_deflated).write(flate::deflate_bytes(data).as_slice()) </ins> }) { Ok(()) => {} Err(e) => {

sess.abort_if_errors() } } <del> a.add_file(&bc, false); </del> <ins> a.add_file(&bc_deflated, false); remove(sess, &bc_deflated); </ins> if !sess.opts.cg.save_temps && !sess.opts.output_types.contains(&OutputTypeBitcode) { remove(sess, &bc);

let archive = ArchiveRO::open(&path).expect("wanted an rlib"); debug!("reading {}", name); <del> let bc = time(sess.time_passes(), format!("read {}.bc", name), (), |_| archive.read(format!("{}.bc", name))); let bc = bc.expect("missing bytecode in archive!"); </del> <ins> let bc = time(sess.time_passes(), format!("read {}.bc.deflate", name), (), |_| archive.read(format!("{}.bc.deflate", name))); let bc = bc.expect("missing compressed bytecode in archive!"); </ins> let bc = time(sess.time_passes(), format!("inflate {}.bc", name), (), |_| flate::inflate_bytes(bc)); let ptr = bc.as_slice().as_ptr();

rm $(TMPDIR)/bar $(RUSTC) foo.rs --emit=asm,ir,bc,obj,link --crate-type=staticlib rm $(TMPDIR)/bar.ll <del> rm $(TMPDIR)/bar.bc </del> rm $(TMPDIR)/bar.s rm $(TMPDIR)/bar.o rm $(TMPDIR)/$(call STATICLIB_GLOB,bar)

rm $(TMPDIR)/foo $(RUSTC) foo.rs --crate-type=bin -o $(TMPDIR)/foo rm $(TMPDIR)/foo <ins> mv $(TMPDIR)/bar.bc $(TMPDIR)/foo.bc </ins> $(RUSTC) foo.rs --emit=bc,link --crate-type=rlib <ins> cmp $(TMPDIR)/foo.bc $(TMPDIR)/bar.bc </ins> rm $(TMPDIR)/bar.bc <ins> rm $(TMPDIR)/foo.bc </ins> rm $(TMPDIR)/$(call RLIB_GLOB,bar)
Change:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'DefId(2: ~ core[ef64]::ops::index::Index::Output) does not have a "fnargnames"'', 'thread 'rustc' panicked at 'DefId(2: ~ core[ef64]::ops::index::Index::Output) does not have a "fnargnames"'' 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: [fnargnames] looking up function parameter names for [resolverforlowering_raw] getting the resolver for lowering --
cc

Discussion:
) { let res = binding.res(); if filter_fn(res) { <del> let def_id = res.def_id(); let has_self = match def_id.as_local() { Some(def_id) => { self.r.delegation_fn_sigs.get(&def_id).map_or(false, |sig| sig.has_self) } None => self .r .tcx .fn_arg_names(def_id) .first() .is_some_and(|ident| ident.name == kw::SelfLower), }; if has_self { return Some(AssocSuggestion::MethodWithSelf { called }); } else { match res { Res::Def(DefKind::AssocFn, _) => { </del> <ins> match res { Res::Def(DefKind::Fn | DefKind::AssocFn, def_id) => { let has_self = match def_id.as_local() { Some(def_id) => self .r .delegation_fn_sigs .get(&def_id) .map_or(false, |sig| sig.has_self), None => self .r .tcx .fn_arg_names(def_id) .first() .is_some_and(|ident| ident.name == kw::SelfLower), }; if has_self { return Some(AssocSuggestion::MethodWithSelf { called }); } else { </ins> return Some(AssocSuggestion::AssocFn { called }); } <del> Res::Def(DefKind::AssocConst, _) => { return Some(AssocSuggestion::AssocConst); } Res::Def(DefKind::AssocTy, _) => { return Some(AssocSuggestion::AssocType); } _ => {} </del> } <ins> Res::Def(DefKind::AssocConst, _) => { return Some(AssocSuggestion::AssocConst); } Res::Def(DefKind::AssocTy, _) => { return Some(AssocSuggestion::AssocType); } _ => {} </ins> } } }

<ins> //@ aux-build:foreign-trait-with-assoc.rs extern crate foreign_trait_with_assoc; use foreign_trait_with_assoc::Foo; // Make sure we don't try to call `fn_arg_names` on a non-fn item. impl Foo for Bar {} //~^ ERROR cannot find type `Bar` in this scope fn main() {} </ins>

<ins> error[E0412]: cannot find type `Bar` in this scope --> $DIR/dont-compute-arg-names-for-non-fn.rs:8:14 | LL | impl Foo for Bar {} |              ^^^ | help: you might have meant to use the associated type | LL | impl Foo for Self::Bar {} |              ++++++ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0412`. </ins>
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. --Code generation for generates an extra floating-point add that adds +0.0 to the result: The problem seems to be because the compiler uses +0.0 as the starting value of instead of -0.0. Comparing LLVM code generation for the two cases, we get the more efficient version when using -0.0: This generates the following assembly for AArch64: To me, this behaviour seems to be caused by using +0.0 instead of -0.0 here in the compiler:
This sounds somewhat related to
Yeah, this is fixed by
wait, not in the... sec, will PR.

Discussion:
}; } <del> arith_red!(simd_reduce_add_ordered: vector_reduce_add, vector_reduce_fadd, true, add, 0.0); </del> <ins> arith_red!(simd_reduce_add_ordered: vector_reduce_add, vector_reduce_fadd, true, add, -0.0); </ins> arith_red!(simd_reduce_mul_ordered: vector_reduce_mul, vector_reduce_fmul, true, mul, 1.0); arith_red!( simd_reduce_add_unordered: vector_reduce_add, vector_reduce_fadd_reassoc, false, add, <del> 0.0 </del> <ins> -0.0 </ins> ); arith_red!( simd_reduce_mul_unordered: vector_reduce_mul,

<ins> //@ revisions: x86_64 aarch64 //@ assembly-output: emit-asm //@ compile-flags: --crate-type=lib -O //@[aarch64] only-aarch64 //@[x86_64] only-x86_64 //@[x86_64] compile-flags: -Ctarget-feature=+sse3 #![feature(portable_simd)] #![feature(core_intrinsics)] use std::intrinsics::simd as intrinsics; use std::simd::*; // Regression test for https://github.com/rust-lang/rust/issues/130028 // This intrinsic produces much worse code if you use +0.0 instead of -0.0 because // +0.0 isn't as easy to algebraically reassociate, even using LLVM's reassoc attribute! // It would emit about an extra fadd, depending on the architecture. // CHECK-LABEL: reduce_fadd_negative_zero pub unsafe fn reduce_fadd_negative_zero(v: f32x4) -> f32 { // x86_64: addps // x86_64-NEXT: movshdup // x86_64-NEXT: addss // x86_64-NOT: xorps // aarch64: faddp // aarch64-NEXT: faddp // CHECK-NOT: {{f?}}add{{p?s*}} // CHECK: ret intrinsics::simd_reduce_add_unordered(v) } </ins>
Change:
Some time over the last days, this started happening: The third invocation should finish immediately, but instead it rebuilds everything. So what is usually a 1s edit-test cycle now takes a full minute. Cc
I wonder if has anything to do with this.
Yeah that sounds likely. Configuring the linker sets some env vars and when those differ between check and test builds, everything gets rebuilt.
Should we revert that PR then? Or is there some other short-term fix? This is a significant hurdle for rustc development right now.
I suppose that we could for now just skip the command from I tried the three commands that you have posted, and the last command did not rebuild anything (or rather, everything was fresh). What code should I modify between running these commands to reproduce the behavior that the third command rebuilds a lot of stuff?
Nevermind, I reproduced it. And the fix with removing check from configuring the linker works. I'll send a PR.
I think excluding is quite good short-term fix.

Discussion:
let mut cargo = builder.cargo(compiler, mode, source_type, target, cmd_kind); match cmd_kind { <del> // No need to configure the target linker for these command types. Kind::Clean | Kind::Check | Kind::Suggest | Kind::Format | Kind::Setup => {} </del> <ins> // No need to configure the target linker for these command types, // as they don't invoke rustc at all. Kind::Clean | Kind::Suggest | Kind::Format | Kind::Setup => {} </ins> _ => { cargo.configure_linker(builder); }

let targets: HashSet<_> = match build.config.cmd { // We don't need to check cross targets for these commands. crate::Subcommand::Clean { .. } <del> | crate::Subcommand::Check { .. } </del> | crate::Subcommand::Suggest { .. } | crate::Subcommand::Format { .. } | crate::Subcommand::Setup { .. } => {
Change:
Trying to run fails right now: It works fine in other checkouts though. The error is correct, there is no such file -- so I guess some other part of bootstrap failed to create that file? fails with the same error. I am on commit , is clean. Reverting back to fixes this, so seems like is the cause of the problem. Cc
I think that this is the issue: as bootstrap probably uses an old version in your checkout. Can you configure the remote? Otherwise you might be using an old/weird version of anyway, regardless of the new error.
The remote is configured. The warning just can't deal with worktrees (). But I think that's orthogonal as I got the warning already before that most recent PR. I don't think also affects fetching the right LLVM version.
Ah, I see, it's the worktree issue. Well, it is orthogonal in a way, but the issue is that bootstrap now assumes that you have a recent-ish archive, because we have some config file to it that is now being checked by bootstrap. Since in your case, bootstrap can't detect the master commit, is is probably also unable to download the correct (recent) ci-llvm archive. Therefore, it probably uses some old archive that misses the config file, and that causes bootstrap to fail. When implementing the config checking, we assumed that if you are on a commit that includes the new checks, then you also have to use a recent ci-llvm. But if git detection is somehow not working, then it's possible to be on a new commit that performs the check, but also to have an old ci-llvm archive at the same time.
Bootstrap can detect the master commit just fine I think. ci-llvm has worked perfectly fine in worktrees for years. The warning has its own logic for checking whether the master commit is outdated, and only that logic is faulty.
Sorry, then I got it wrong, it was a red herring. I actually just checked that it also doesn't work for me (nor anyone else, probably). Let's quickly revert then.
That said, something also changed with remote branch logic recently that broke it in worktrees -- did the right thing on worktrees for years, but now it formats 5k files.
How exactly can we reproduce this? Running on a fresh build works for me.
I assume you have the old directory where it was unpacked with old bootstrap logic.
I see. It works when you newly extract , but not with an already extracted directory. So removing the directory (or just doing ) is a workaround.
suffices and avoids having to re-download and re-build everything.

Discussion:
Change this file to make users of the `download-ci-llvm` configuration download a new version of LLVM from CI, even if the LLVM submodule hasn’t changed. <del> Last change is for: https://github.com/rust-lang/rust/pull/129116 </del> <ins> Last change is for: https://github.com/rust-lang/rust/pull/129788 </ins>
Change:
I tried this code: I expected to see this happen: no errors Instead, this happened: : Very likely to be related
Looks like allowed missing docs on the generated function, but didn't test having any actual s. cc
Attempt fix in

Discussion:
cx.attr_nested_word(sym::cfg, sym::test, attr_sp), // #[rustc_test_marker = "test_case_sort_key"] cx.attr_name_value_str(sym::rustc_test_marker, test_path_symbol, attr_sp), <ins> // #[doc(hidden)] cx.attr_nested_word(sym::doc, sym::hidden, attr_sp), </ins> ], // const $ident: test::TestDescAndFn = ast::ItemKind::Const(

let main_attr = ecx.attr_word(sym::rustc_main, sp); // #[coverage(off)] let coverage_attr = ecx.attr_nested_word(sym::coverage, sym::off, sp); <del> // #[allow(missing_docs)] let missing_docs_attr = ecx.attr_nested_word(sym::allow, sym::missing_docs, sp); </del> <ins> // #[doc(hidden)] let doc_hidden_attr = ecx.attr_nested_word(sym::doc, sym::hidden, sp); </ins> // pub fn main() { ... } let main_ret_ty = ecx.ty(sp, ast::TyKind::Tup(ThinVec::new()));

let main = P(ast::Item { ident: main_id, <del> attrs: thin_vec![main_attr, coverage_attr, missing_docs_attr], </del> <ins> attrs: thin_vec![main_attr, coverage_attr, doc_hidden_attr], </ins> id: ast::DUMMY_NODE_ID, kind: main, vis: ast::Visibility { span: sp, kind: ast::VisibilityKind::Public, tokens: None },

mir_unwind_unreachable, mir_variant, miri, <del> missing_docs, </del> mmx_reg, modifiers, module,

extern crate test; #[cfg(test)] #[rustc_test_marker = "m_test"] <ins> #[doc(hidden)] </ins> pub const m_test: test::TestDescAndFn = test::TestDescAndFn { desc: test::TestDesc {

extern crate test; #[cfg(test)] #[rustc_test_marker = "z_test"] <ins> #[doc(hidden)] </ins> pub const z_test: test::TestDescAndFn = test::TestDescAndFn { desc: test::TestDesc {

extern crate test; #[cfg(test)] #[rustc_test_marker = "a_test"] <ins> #[doc(hidden)] </ins> pub const a_test: test::TestDescAndFn = test::TestDescAndFn { desc: test::TestDesc {

fn a_test() {} #[rustc_main] #[coverage(off)] <del> #[allow(missing_docs)] </del> <ins> #[doc(hidden)] </ins> pub fn main() -> () { extern crate test; test::test_main_static(&[&a_test, &m_test, &z_test])

//! on the generated test harness. //@ check-pass <del> //@ compile-flags: --test -Dmissing_docs </del> <ins> //@ compile-flags: --test #![forbid(missing_docs)] #[test] fn test() {} </ins>
Change:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' File: /home/gh- --auto-reduced (treereduce-rust): original: Version information ` <!-- query stack: [typeck] type-checking [fnsig] computing function signature of --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Possibly related to , possibly somewhat related to , cc very astute assertions!
claim

Discussion:
&& let Some(node) = tcx.hir().get_if_local(def_id) && let Some(sig) = node.fn_sig() { <del> sig.decl.inputs.len() + sig.decl.implicit_self.has_implicit_self() as usize </del> <ins> sig.decl.inputs.len() </ins> } else { tcx.dcx().abort_if_errors(); unreachable!()

<ins> trait Bar { fn foo(&mut self) -> _ { //~^ ERROR the placeholder `_` is not allowed within types on item signatures for return types Self::foo() //~ ERROR  this function takes 1 argument but 0 arguments were supplied } } fn main() {} </ins>

<ins> error[E0061]: this function takes 1 argument but 0 arguments were supplied --> $DIR/mismatch-args-crash-issue-130400.rs:4:9 | LL |         Self::foo() |         ^^^^^^^^^-- argument #1 is missing | note: method defined here --> $DIR/mismatch-args-crash-issue-130400.rs:2:8 | LL |     fn foo(&mut self) -> _ { |        ^^^ --------- help: provide the argument | LL |         Self::foo(/* value */) |                  ~~~~~~~~~~~~~ error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types --> $DIR/mismatch-args-crash-issue-130400.rs:2:26 | LL |     fn foo(&mut self) -> _ { |                          ^ not allowed in type signatures error: aborting due to 2 previous errors Some errors have detailed explanations: E0061, E0121. For more information about an error, try `rustc --explain E0061`. </ins>
Change:
The repro repository has everything: Expected behavior is that the diagnostics have: , but they currently have .
cc (as per )
Thanks for opening the issue! I'm surprised since it's an issue that was supposed to be fixed in Just to confirm: which rustc version do you use? Also cc since you're the one who fixed this bug.
This happened with 1.81 most likely — I would take the few secs to check but I’m on a phone right now.
The doctest system needs to use the same infrastructure as the rest of rustdoc.
I can confirm this does fix my repro: ! Would you like a separate issue for the part where it says when really it could normalize the path and just say ?
Yes please!
filed as
Thanks! Gonna take a look in the next days if someone else didn't do it before then.

Discussion:
// anything else, this will combine them for us. let attrs = Attributes::from_ast(ast_attrs); if let Some(doc) = attrs.opt_doc_value() { <del> // Use the outermost invocation, so that doctest names come from where the docs were written. let span = ast_attrs .iter() .find(|attr| attr.doc_str().is_some()) .map(|attr| attr.span.ctxt().outer_expn().expansion_cause().unwrap_or(attr.span)) .unwrap_or(DUMMY_SP); </del> <ins> let span = span_of_fragments(&attrs.doc_strings).unwrap_or(sp); </ins> self.collector.position = span; markdown::find_testable_code( &doc, &mut self.collector, self.codes, self.enable_per_target_ignores, <del> Some(&crate::html::markdown::ExtraInfo::new( self.tcx, def_id, span_of_fragments(&attrs.doc_strings).unwrap_or(sp), )), </del> <ins> Some(&crate::html::markdown::ExtraInfo::new(self.tcx, def_id, span)), </ins> ); }

<ins> With a code sample, that has an error: ```rust fn main() { let x = 234 // no semicolon here! oh no! } ``` </ins>

<ins> //@ compile-flags:--test --test-args=--test-threads=1 //@ normalize-stdout-test: "tests/rustdoc-ui/doctest" -> "$$DIR" //@ normalize-stdout-test: "finished in d+.d+s" -> "finished in $$TIME" //@ failure-status: 101 // https://github.com/rust-lang/rust/issues/130470 #![doc = include_str!("doctest-output-include-fail.md")] </ins>

<ins> running 1 test test $DIR/doctest-output-include-fail.md - (line 3) ... FAILED failures: ---- $DIR/doctest-output-include-fail.md - (line 3) stdout ---- error: expected `;`, found `}` --> $DIR/doctest-output-include-fail.md:5:16 | LL |     let x = 234 // no semicolon here! oh no! |                ^ help: add `;` here LL | } | - unexpected token error: aborting due to 1 previous error Couldn't compile the test. failures: $DIR/doctest-output-include-fail.md - (line 3) test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in $TIME </ins>

running 3 tests test $DIR/doctest-output.rs - (line 8) ... ok <del> test $DIR/doctest-output.rs - ExpandedStruct (line 24) ... ok </del> <ins> test $DIR/doctest-output.rs - ExpandedStruct (line 25) ... ok </ins> test $DIR/doctest-output.rs - foo::bar (line 18) ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in $TIME
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. --I tried this code: . I expected to see this happen: rustc rejecting this code. We are transmuting arbitrary types without unsafe, this is clearly unsound. Instead, this happened: rustc accepted this code, and it SIGSEGVs at runtime. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to have regressed between 1.76 and 1.77. In 1.76 (and below) it gave: It's probably related to the THIR unsafeck which in .
I'll take a look at this. I think I may have found out what's going on. claim
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Reopening for beta nomination.
Fix backported via

Discussion:
warnings: self.warnings, suggest_unsafe_block: self.suggest_unsafe_block, }; <ins> // params in THIR may be unsafe, e.g. a union pattern. for param in &inner_thir.params { if let Some(param_pat) = param.pat.as_deref() { inner_visitor.visit_pat(param_pat); } } // Visit the body. </ins> inner_visitor.visit_expr(&inner_thir[expr]); // Unsafe blocks can be used in the inner body, make sure to take it into account self.safety_context = inner_visitor.safety_context;

warnings: &mut warnings, suggest_unsafe_block: true, }; <ins> // params in THIR may be unsafe, e.g. a union pattern. for param in &thir.params { if let Some(param_pat) = param.pat.as_deref() { visitor.visit_pat(param_pat); } } // Visit the body. </ins> visitor.visit_expr(&thir[expr]); warnings.sort_by_key(|w| w.block_span);

<ins> union U { a: &'static i32, b: usize, } fn fun(U { a }: U) { //~^ ERROR access to union field is unsafe dbg!(*a); } fn main() { fun(U { b: 0 }); let closure = |U { a }| { //~^ ERROR access to union field is unsafe dbg!(*a); }; closure(U { b: 0 }); } </ins>

<ins> error[E0133]: access to union field is unsafe and requires unsafe function or block --> $DIR/union-pat-in-param.rs:6:12 | LL | fn fun(U { a }: U) { |            ^ access to union field | = note: the field may not be properly initialized: using uninitialized data will cause undefined behavior error[E0133]: access to union field is unsafe and requires unsafe function or block --> $DIR/union-pat-in-param.rs:14:24 | LL |     let closure = |U { a }| { |                        ^ access to union field | = note: the field may not be properly initialized: using uninitialized data will cause undefined behavior error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0133`. </ins>