jiebi/CodeConvo huggingface dataset:
Change:
impl Callbacks for TimePassesCallbacks { fn config(&mut self, config: &mut interface::Config) { <ins> // If a --prints=... option has been given, we don't print the "total" // time because it will mess up the --prints output. See #64339. </ins> self.time_passes = <del> config.opts.debugging_opts.time_passes || config.opts.debugging_opts.time; </del> <ins> config.opts.prints.is_empty() && (config.opts.debugging_opts.time_passes || config.opts.debugging_opts.time); </ins> } }

Discussion:
I encountered this as well. What project are you trying to build? My theory is that it tries to run something like (in ?) and then fails to parse the output which is a mix of and ...
Way earlier, it runs it right at the start of a compilation to get the rustc version and enabled . Probably
Could someone use to narrow this down to a particular commit?
It looks to be caused by (I would assume it is in that rollup). It is now printing the time-passes information even for .
would you be up for a fix here?
I'll take a look on Monday. In the meantime, here's my best guess: I an extra entry to the output that prints the total time for the compilation. That extra line may not be indented at all, and it's possible this means it isn't ignored the same way as indented lines.
My theory about indentation was wrong. It was indeed a bad interaction between and , as others suggested, because they both print to . has a fix.
Change:
println!("formatting modified file {file}"); } } else { <del> println!("formatting {} modified files", files.len()); </del> <ins> let pluralized = |count| if count > 1 { "files" } else { "file" }; let untracked_msg = if untracked_count == 0 { "".to_string() } else { format!( ", skipped {} untracked {}", untracked_count, pluralized(untracked_count), ) }; println!( "formatting {} modified {}{}", files.len(), pluralized(files.len()), untracked_msg ); </ins> } for file in files { <del> ignore_fmt.add(&format!("/{file}")).expect(&file); </del> <ins> fmt_override.add(&format!("/{file}")).expect(&file); </ins> } } Ok(None) => {}

Discussion:
The skipped files are files in the repo that are not tracked by git. It looks like they might still get to the "formatted modified file" counter? I have no other changed files in the repo, so I wonder what rustfmt is saying to have formatted here :sweat_smile:
It detects X files modified, but the fact that they are not tracked means that their rustfmt invocation will be skipped.
It's better to give different counts for skipped and formatted files?
Maybe soemthing like "formatted x files, skipped y untracked files" would make more sense.
The number is actually right, but it's the number of the files that have been modified in the current branch compared to the master branch: you have 86 untracked path in this case. Anywa, we can make it more explicit here.
Change:
<ins> // build-pass #![crate_type = "lib"] #![allow(arithmetic_overflow)] pub trait BitSplit { type Half; fn merge(halves: [Self::Half; 2]) -> Self; } macro_rules! impl_ints { ($int:ty => $half:ty; $mask:expr) => { impl BitSplit for $int { type Half = $half; #[inline] fn merge(halves: [Self::Half; 2]) -> Self { const HALF_SIZE: usize = std::mem::size_of::<$half>() * 8; (halves[0] << HALF_SIZE) as $int | halves[1] as $int } } }; } impl_ints!(u128 => u64; 0x0000_0000_0000_0000_FFFF_FFFF_FFFF_FFFF); impl_ints!( u64 => u32;                     0x0000_0000_FFFF_FFFF); impl_ints!( u32 => u16;                               0x0000_FFFF); impl_ints!( u16 =>  u8;                                    0x00FF); </ins>

Discussion:
<!-- 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. --Changing the commented out snippet to the uncommented one caused a ICE when building on nightly . EDIT: Moving the integer cast to before the shift fixes the ICE. () <!-- 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
This also ICEs on beta on the playground. label regression-from-stable-to-beta
searched nightlies: from nightly-2022-03-01 to nightly-2022-04-23 regressed nightly: nightly-2022-03-25 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
cc perhaps we need to adjust where we run some of these lints you extracted in ?
It seems that this is fixed on , so I wanted to find out when that happened and ran () as described here: and it error'd out on me with: Just thought I'd mention that, I think this can be closed, but I couldn't say when or how it was fixed.
Via godbolt I can't find any stable Rust release where this fails. If it ICEd on beta that means an ICE fix must have been backported? you marked this as regression-from-stable-to-stable, was that an automatic process or did you (or someone else) actually ever see this ICE on stable Rust?
Oh wait, I didn't realize that the code posted in the OP is code that works, and one needs to adjust the code to generate an ICE. That is confusing. Sorry for the noise, it does reproduce on 1.64.0 but not 1.65.0.
Change:
let src = build.out.join(host).join("doc"); cp_r(&src, &dst); <del> let mut cmd = Command::new("sh"); </del> <ins> let mut cmd = Command::new(SH_CMD); </ins> cmd.arg(sanitize_sh(&build.src.join("src/rust-installer/gen-installer.sh"))) .arg("--product-name=Rust-Documentation") .arg("--rel-manifest-dir=rustlib")

Discussion:
The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .
Change:
Self::with_capacity_in(capacity, Global) } <del> /// Creates a `Vec<T>` directly from the raw components of another vector. </del> <ins> /// Creates a `Vec<T>` directly from a pointer, a capacity, and a length. </ins> /// /// # Safety /// /// This is highly unsafe, due to the number of invariants that aren't /// checked: /// <del> /// * `ptr` needs to have been previously allocated via [`String`]/`Vec<T>` ///   (at least, it's highly likely to be incorrect if it wasn't). </del> /// * `T` needs to have the same alignment as what `ptr` was allocated with. ///   (`T` having a less strict alignment is not sufficient, the alignment really ///   needs to be equal to satisfy the [`dealloc`] requirement that memory must be

Discussion:
has this to say about a better way to turn a into a : A strict reading, if I understand correctly, says that these two statements are contradictory. The documentation says that it is safe to create a and then use to create a out of its pointer. But the documentation says that, when creating a , must have previously been allocated via precisely and only , not for some other type —not even if happens to be transmutable from , not even if and are ABI-compatible, not only if is a wrapper around , but only itself. I suspect it was meant to say it must have previously been allocated by , not ; after all, if it could only have been allocated by in the first place, the next bullet point would be redundant (because obviously has the same alignment as ).
label A-docs
Relevant: looks like it will fix this if approved, by explicitly allowing allocation using something other than Vec<T(which can be a Vec<Uor even manual allocation)
Hm, that PR does remove the text I pointed out, but it also adds this text: Isn’t that equally problematic (albeit a slightly different but related problem, since it’s talking about the contents of the memory rather than its ), since it is actually fine for them to be properly initialized values of some other type that is suitably bytewise-compatible (for a proper choice of wording for “suitably compatible”) with but is not actually itself? Or does “properly initialized values of type ” actually also cover that (i.e. does it mean “bytes containing valid representations of ” and not “memory regions which have been constructed as s”?).
Rust doesn't have typed memory, types only have effect on accesses, so if some memory can be interpreted as some type T and it's valid at that type, it's a properly initialized value of type T. Nothing remembers the "original type" of some data. Just like how you can cast a to a and use them interchangeably. This is a safe operation if you use , too.
Change:
} // `x..=y` where `x > y` hence the range is empty => error. (RangeEnd::Included, _) => { <del> self.tcx.sess.emit_err(LowerRangeBoundMustBeLessThanOrEqualToUpper { span, teach: if self.tcx.sess.teach(&error_code!(E0030)) { Some(()) } else { None }, }); </del> <ins> let mut lower_overflow = false; let mut higher_overflow = false; if let Some(hir::Expr { kind: hir::ExprKind::Lit(lit), .. }) = lo_expr && let rustc_ast::ast::LitKind::Int(val, _) = lit.node { if lo.eval_bits(self.tcx, self.param_env, ty) != val { lower_overflow = true; self.tcx.sess.emit_err(LiteralOutOfRange { span: lit.span, ty, max: max() }); } } if let Some(hir::Expr { kind: hir::ExprKind::Lit(lit), .. }) = hi_expr && let rustc_ast::ast::LitKind::Int(val, _) = lit.node { if hi.eval_bits(self.tcx, self.param_env, ty) != val { higher_overflow = true; self.tcx.sess.emit_err(LiteralOutOfRange { span: lit.span, ty, max: max() }); } } if !lower_overflow && !higher_overflow { self.tcx.sess.emit_err(LowerRangeBoundMustBeLessThanOrEqualToUpper { span, teach: if self.tcx.sess.teach(&error_code!(E0030)) { Some(()) } else { None }, }); } </ins> PatKind::Wild } }

Discussion:
For a match where I'm matching on a , I put on accident, and then rather than saying that 256 is out of range for , it decided to wrap 256 to 0 and then error that 251 is lower than the end of the range: Clearly this is not a good situation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to fix this claim
Triage: I'm going to release assignment due to inactivity. If you're still interested in this, feel free to re-claim. release-assignment
Explanation on how to solve this in
Change:
function getSystemValue() { var property = getComputedStyle(document.documentElement).getPropertyValue('content'); <del> return property.replace(/"'/g, ""); </del> <ins> return property.replace(/["']/g, ""); </ins> } switchTheme(currentTheme, mainTheme,

Discussion:
Follow-up to , , , and . Same symptoms as . Additionally, I'm seeing styles from both and active, and the ones in are taking precedence over the ones in even though the system is in dark mode. Tested on deleting the local storage entry, and docs generated locally.
cc
Change:
<ins> // Copyright 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. #![deny(warnings)] #![allow(unused_imports)] enum Foo { A } mod bar { pub fn normal(x: ::Foo) { use A; match x { A => {} } } pub fn wrong(x: ::Foo) { match x { ::A => {} } } } pub fn main() { bar::normal(A); bar::wrong(A); } </ins>

Discussion:
That is, it's not obeying the global part of the path and instead just creating a variable with the name .
cc
Oh, and moving the out of to makes compile without warning, so I guess the global boolean is just being ignored somewhere.
Change:
<ins> error[E0596]: cannot borrow `x[..]` as mutable, as `x` is not declared as mutable --> $DIR/array_subslice.rs:7:21 | LL | pub fn subslice_array(x: [u8; 3]) { |                       - help: consider changing this to be mutable: `mut x` ... LL |         let [ref y, ref mut z @ ..] = x; |                     ^^^^^^^^^ cannot borrow as mutable error[E0596]: cannot borrow `f` as mutable, as it is not declared as mutable --> $DIR/array_subslice.rs:10:5 | LL |         let [ref y, ref mut z @ ..] = x; |                                       - calling `f` requires mutable binding due to mutable borrow of `x` ... LL |     f(); |     ^ cannot borrow as mutable | help: consider changing this to be mutable | LL |     let mut f = || { |         +++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0596`. </ins>

Discussion:
<!-- 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 fixed by (
searched nightlies: from nightly-2022-12-30 to nightly-2023-03-18 regressed nightly: nightly-2023-01-01 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegression in same as ..?
You should update your cargo-bisect-rustc version to make it bisect the contents of rollups as well^^
I already have the git version installed :o
Note that we don't have the artifacts for all rollups. I think it requires a perf bisection to be run on the pr or something?
Regression in nightly-2021-09-01 `
Ah, the rollup predates unrolled builds.
I think this is a different issue, it's not fixed by that PR anyway. I'll try and investigate anyway claim The ICE occurs while trying to report this error Changing to fails earlier:
Actually this can be reduced further -
Change:
<del> // Copyright 2012 The Rust Project Developers. See the COPYRIGHT </del> <ins> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT </ins> // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. //

Discussion:
The benchmarks for LinearMap and TreeMap should just be using the Map trait, but I encountered a strange borrow checking issue: diff: error: This seems like a borrowck bug, but I'm not sure. The same issue occurs when trying to work around it with a trait like with a method.
Change:
error: an inner attribute is not permitted in this context <del> --> $DIR/issue-45296.rs:4:7 </del> <ins> --> $DIR/issue-45296.rs:4:5 </ins> | LL |     #![allow(unused_variables)] <del> |       ^ </del> <ins> |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ </ins> | = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.

Discussion:
Given the following we currently emit We should emit at least the following We might also want to provide suggestions when it makes sense (like turning the attr into an outer attr).
Hey , I tried to solve this with a little help of on a rust meetup. I wasn't able to run because of the following message. But I started to add some code you can read here: is this going into the right direction?
thank you for taking a look at this! You should be able to run the tests with . Use to update the relevant files. The code you've written would generate the following output: Instead, we'd want this to be a single error. What you'd want to do is 1) get the span for the prior attribute from 2) expand to also hold an extra field and 3) change the following to be This lets you point at the prior span in the same error. The second part of this ticket is changing the linked code to no longer use , but rather synthesize a new span from the first 's span to the closing . You can use to do so. Finally, we change the above to be something like
Are you still working on this? I'm thinking of giving it a try.
Go on! I don’t have so much time atm so just go there step by step while learning rust. If you want so solve it - awesome
Change:
unsafe_op_in_unsafe_fn_allowed: bool, ) { match self { <del> CallToUnsafeFunction(did) if did.is_some() && unsafe_op_in_unsafe_fn_allowed => { </del> <ins> CallToUnsafeFunction(Some(did)) if unsafe_op_in_unsafe_fn_allowed => { </ins> tcx.sess.emit_err(CallToUnsafeFunctionRequiresUnsafeUnsafeOpInUnsafeFnAllowed { span, <del> function: &tcx.def_path_str(did.unwrap()), </del> <ins> function: &tcx.def_path_str(*did), </ins> }); } <del> CallToUnsafeFunction(did) if did.is_some() => { </del> <ins> CallToUnsafeFunction(Some(did)) => { </ins> tcx.sess.emit_err(CallToUnsafeFunctionRequiresUnsafe { span, <del> function: &tcx.def_path_str(did.unwrap()), </del> <ins> function: &tcx.def_path_str(*did), </ins> }); } <del> CallToUnsafeFunction(..) if unsafe_op_in_unsafe_fn_allowed => { </del> <ins> CallToUnsafeFunction(None) if unsafe_op_in_unsafe_fn_allowed => { </ins> tcx.sess.emit_err( CallToUnsafeFunctionRequiresUnsafeNamelessUnsafeOpInUnsafeFnAllowed { span }, ); } <del> CallToUnsafeFunction(..) => { </del> <ins> CallToUnsafeFunction(None) => { </ins> tcx.sess.emit_err(CallToUnsafeFunctionRequiresUnsafeNameless { span }); } UseOfInlineAssembly if unsafe_op_in_unsafe_fn_allowed => {

Discussion:
In some external crate, say : Main crate: : With , this gives the following ICE: <details<summary<strongBacktrace</strong</summary<p</p</detailsThis is because the lint to insert the name in the diagnostic message (this delays a good path bug), then the lint because it's in an external macro, which means we don't emit any diagnostic which triggers the good path bug. This ICE is currently preventing rustc from building with enabled. I see several ways to fix this: don't print the function name. It arguably carries little value, with the span already pointing to the offending function call, and brings THIR unsafeck in line with MIR unsafeck (cc ). 't trim the path. This might lead to longer messages but other lints already do this so it is probably acceptable? 't create the lint if we're in an external macro and we know the lint will be cancelled anyway. It's a little hacky and breaks down if changes are made to lint emission. the lint emission API to allow lint messages to be lazily evaluated. label +A-diagnostics +requires-nightly claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Error: Label thir-unsafeck can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Would not trimming the path also be acceptable ? (via )
It looks like some lints are already not trimming paths so this is probably acceptable? I can do that if that's the preferred option.
claim
Change:
<ins> error[E0038]: the trait `T` cannot be made into an object --> $DIR/issue-87495.rs:4:25 | LL |     const CONST: (bool, dyn T); |                         ^^^^^ `T` cannot be made into an object | = help: consider moving `CONST` to another trait note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety> --> $DIR/issue-87495.rs:4:11 | LL | trait T { |       - this trait cannot be made into an object... LL |     const CONST: (bool, dyn T); |           ^^^^^ ...because it contains this associated `const` error: aborting due to previous error For more information about this error, try `rustc --explain E0038`. </ins>

Discussion:
<!-- 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
I used this to make some warnings/errors go away: Regressed in cc modify labels: regression-from-stable-to-nightly
Change:
<ins> // Regression test for issue #72213 // Tests that we don't ICE when we have projection predicates // in our initial ParamEnv pub struct Lines<'a, L> where L: Iterator<Item = &'a ()>, { words: std::iter::Peekable<Words<'a, L>>, } pub struct Words<'a, L> { _m: std::marker::PhantomData<&'a L>, } impl<'a, L> Iterator for Words<'a, L> where L: Iterator<Item = &'a ()>, { type Item = (); fn next(&mut self) -> Option<Self::Item> { unimplemented!() } } </ins>

Discussion:
rustc panic when running . The crate otherwise seems to test, run & work fine. Checkout rev . Run . <!-- 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
somewhat minified:
Somewhat interesting: nightly-2018-01-17 gives me: and cargo check as gives me the same error message. On nightly-2019-01-17 on the other hand cargo doc panics and cargo check does not complain any more: Edit: nightly-2018-12-01 gives me exactly no output. No warning, no ICE. That is weird as well...
Regression in nightly-2018-12-08 (...) (nightly-2018-12-07 is not available) The "no output" regression (from rejecting the program as such and giving no output at all) is in nightly-2018-09-13 (...)
The latter is an intended change caused by
This is still occurring, the panic seems to come from . Updated info: : <details<summary<strongBacktrace</strong</summary<p</p</details
Assigning as and removing .
Change:
<ins> fn main() { let _map = std::hahmap::HashMap::new(); //~^ ERROR failed to resolve: could not find `hahmap` in `std } </ins>

Discussion:
Test program: This produces the following error messages: Both the error and the help seem entirely unhelpful. The error suggests that it looked for a function in the crate root, but in fact it looked for a crate . The whole "possible candidate" help seems incorrect, and adding that line would lead to a compilation failure.
cc
This is still an issue, but at least the incorrect help message is no longer displayed:
Change:
<del> Subproject commit 7a2f1cadcd5120c44eda3596053de767cd8173a2 </del> <ins> Subproject commit 035933186957cf81c488261fb48a98bf523e8006 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!