jiebi/CodeConvo huggingface dataset:
Change:
https://crater- https://crater- https://crater- https://crater- Introduced by , most likely, cc
One reasonable fix is to stabilize these types in . That will allow using reexports instead of type aliases, which will remove the ambiguities. They are the same types as stable types in just exposed from a different (but also stable) location in the same crate. (That said, glob vs glob is an acceptable breakage according to the library policy.)
That would be a fast stabilization, but given that they're rather simple types, that seems potentially reasonable.
If we were to stabilize, presumably we'd do that on master and back out the PR from beta? I am reluctant to backport a stabilization to fix this (particularly a fast one, as you mention).
Yeah, reverting the PR on beta seems fine for now.

Discussion:
use std::borrow::Cow::{Borrowed, Owned}; <del> use std::ffi::{c_char, CStr}; </del> <ins> use std::ffi::CStr; use std::os::raw::c_char; </ins> #[test] fn to_str() {

#[stable(feature = "core_c_void", since = "1.30.0")] pub use core::ffi::c_void; <del> #[unstable(feature = "core_ffi_c", issue = "94501")] pub use core::ffi::{ c_char, c_double, c_float, c_int, c_long, c_longlong, c_schar, c_short, c_uchar, c_uint, c_ulong, c_ulonglong, c_ushort, }; #[unstable(feature = "c_size_t", issue = "88345")] pub use core::ffi::{c_ptrdiff_t, c_size_t, c_ssize_t}; </del> #[unstable( feature = "c_variadic", reason = "the `c_variadic` feature has not been properly tested on 

// Only for re-exporting: #![feature(assert_matches)] #![feature(async_iterator)] <del> #![feature(c_size_t)] </del> #![feature(c_variadic)] #![feature(cfg_accessible)] #![feature(cfg_eval)]
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. --I tried this code: I expected to see this happen: successful compilation Instead, this happened: It most recently worked on (): <!-- Provide the version you are using that has the regression. --: We've determined that is the culprit; either removing that line or replacing with both fix the compiler crashing (although this does not produce the code we want). This looks like it's possibly related to the LLVM version. modify labels: +regression-from-stable-to-stable -regression-untriaged
A bit of reducing could help here. ideally we want to be able to reproduce. label +O-wasm tagging also ping icebreakers-cleanup-crew
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
: (must be compiled with , which can be done on playground by setting to "release" and clicking "WASM" instead of "Run")
searched nightlies: from nightly-2022-01-13 to nightly-2022-05-03 regressed nightly: nightly-2022-03-11 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: </detailsThis did indeed regress in the LLVM bump (). label I-crash A-llvm
Assigning priority as discussed in the of the Prioritization Working Group. Great work thanks! label -I-prioritize +P-high -ICEBreaker-Cleanup-Crew
Looks like is the change where it starts failing. Adding does seem to work around the crash. cc
IR: Running this through crashes with LLVM 14 but works fine on main, so this was apparently already fixed in the meantime.
Bisect points to , which probably just hides the problem.
Ah no, I misread. That does look like the actual fix for the issue.
Filed backport issue:
Apologies for the noise, but did this fix make its way into 1.61? I'm still getting similar issues there.

Discussion:
<del> Subproject commit 593484fc1596707406b0b0b45b97feb08d2a1bfc </del> <ins> Subproject commit 47848665966fc7393cb6f898077994f6dec2b591 </ins>
Change:
It's very confusing that this can't actually be run through x.py itself; it tripped me up in See for the existing code and for where it should be moved. label +A-rustbuild +E-easy +E-mentor +E-help-wanted +A-contributor-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Discussion:
src/tools/cargo  src/tools/cargotest  $(BOOTSTRAP_ARGS) <del> check-bootstrap: $(Q)$(CFG_PYTHON) $(CFG_SRC_DIR)src/bootstrap/bootstrap_test.py </del> dist: $(Q)$(BOOTSTRAP) dist $(BOOTSTRAP_ARGS) distcheck:

/// Tests the build system itself. fn run(self, builder: &Builder<'_>) { <ins> let mut check_bootstrap = Command::new(&builder.python()); check_bootstrap.arg("bootstrap_test.py").current_dir(builder.src.join("src/bootstrap/")); try_run(builder, &mut check_bootstrap); </ins> let mut cmd = Command::new(&builder.initial_cargo); cmd.arg("test") .current_dir(builder.src.join("src/bootstrap"))

retry make prepare <del> make check-bootstrap </del> # Display the CPU and memory information. This helps us know why the CI timing # is fluctuating. if isMacOS; then
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. --In the situation using the genericconstexprs feature to specify the number of array elements, a linker error occurred in the Trait implementation. We minimized it as much as possible, but it could be more simplified. This is just a guess, but I think it is probably because the function signature is wrong. The error content claims that there is no "compilerbug2::Trait1::crashhere", although it should be "<compilerbug2::Struct1<[i32; 1]as compilerbug2::Trait1<[i32; 1]::crash_here". <!-- 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. --: </p</details
Triage: the issue no longer occurs with the latest nightly (I guess is related), could you check on your end?

Discussion:
<ins> // check-pass #![allow(dead_code, incomplete_features)] #![feature(generic_const_exprs)] const fn min(a: usize, b: usize) -> usize { if a < b { a } else { b } } trait Trait1<Inner1> where Self: Sized, { fn crash_here() where Inner1: Default, { Inner1::default(); } } struct Struct1<T>(T); impl<T> Trait1<T> for Struct1<T> {} trait Trait2<Inner2> where Self: Sized, { type Assoc: Trait1<Inner2>; fn call_crash() where Inner2: Default, { // if Inner2 implements Default, we can call crash_here. Self::Assoc::crash_here(); } } struct Struct2<const SIZE1: usize, const SIZE2: usize> {} /* where [(); min(SIZE1, SIZE2)]:, { elem: [i32; min(SIZE1, SIZE2)], } */ impl<const SIZE1: usize, const SIZE2: usize> Trait2<[i32; min(SIZE1, SIZE2)]> for Struct2<SIZE1, SIZE2> { type Assoc = Struct1<[i32; min(SIZE1, SIZE2)]>; // dose Struct1<[i32; min(SIZE1, SIZE2)]> implement Default? } fn main() { pattern2(); print_fully_name(<Struct2<1, 2> as Trait2<[i32; min(1, 2)]>>::Assoc::crash_here); // <compiler_bug2::Struct1<[i32; 1]> as compiler_bug2::Trait1<[i32; 1]>>::crash_here } fn pattern1() { // no crash <Struct2<1, 2> as Trait2<[i32; min(1, 2)]>>::Assoc::crash_here(); <Struct2<1, 2> as Trait2<[i32; min(1, 2)]>>::call_crash(); } fn pattern2() { // crash <Struct2<1, 2> as Trait2<[i32; min(1, 2)]>>::call_crash(); // undefined reference to `compiler_bug2::Trait1::crash_here' } fn pattern3() { // no crash <Struct2<1, 2> as Trait2<[i32; min(1, 2)]>>::Assoc::crash_here(); } fn print_fully_name<T>(_: T) { let _ = std::any::type_name::<T>(); } </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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!
Why did this get closed? https://rust-lang- says Miri is still broken.
Oh whoops. I misinterpreted the PR linking to this.

Discussion:
<del> Subproject commit a71a0083937671d79e16bfac4c7b8cab9c8ab9bb </del> <ins> Subproject commit 3b8b6aa8b689971d3b8776cefe3d809501e1b8ff </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. --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.

Discussion:
<ins> // build-pass #![crate_type = "lib"] #![feature(unsized_fn_params)] pub fn f(mut x: [i32]) { x[0] = 1; } </ins>

<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>
Change:
When running  to cross-compile for a Cortex M target, a few issues arise with the fact that the target has a in the name. There are two issues that I noticed: generates an invalid — this is easy to fix with a change to the example file. looks for compiler flags in difficult-to-name variables — this is harder to fix, but can be (painfully) worked around. To illustrate issue 1, I tried this code: I expected to see this happen: compilation should get pretty far (I'm eliding some of the things that would make it actually succeed, for brevity, but successfully building stage0 rustc is expected at least) Instead, this happened: compilation fails after one minute with the error: This is because the generated contains this line (note the problematic period): I believe this comes from , where we unconditionally replace in the . If is updated to put quotes around its target architecture, this issue is solved: Issue 2 takes more effort to reproduce, and is technically not a bug in rustc, but in the crate. Or maybe it's not a bug at all, but it's pretty darn unfortunate. In particular, the intended way to specify (and friends) for is to write to the environment variable , or . The problem: most shells do not allow users to export environment variables that contain the character: If I fix issue 1 as described above, and use the workaround to get around issue 2, I am able to build a target that has a period in it. This was tested with current top of tree (commit ) but does not appear to be a recent regression. I see the same behavior when my host is either or , which is unsurprising. I think it makes sense to split issues 1 and 2 into separate bug reports (issue 2 being reported on the crate) -- but wanted to get this out there first to simply reflect that targets with dots are currently difficult to build for. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Thanks for the bug report! I think it's unlikely we will do anything about 2 in rust-lang/rust itself (having a target with a dot and having to set CFLAGS seems rare), but 1 is definitely a bug we should fix. Mentoring instructions: in add quotes around the we're replacing the default with. label +A-rustbuild +E-easy +E-mentor +E-help-wanted
claim

Discussion:
configured_targets.append(target) for target in configured_targets: targets[target] = sections['target'][:] <del> targets[target][0] = targets[target][0].replace("x86_64-unknown-linux-gnu", target) </del> <ins> targets[target][0] = targets[target][0].replace("x86_64-unknown-linux-gnu", "'{}'".format(target)) </ins> def is_number(value):
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. --There is no code. The internal compiler error happens when building rustc itself (on MSYS2/Mingw) <!-- 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. --We are trying to build Rust 1.61.0. The error happens when building while processing the libs passed on the command line. The issue concerns native library modifiers and was most probably introduced by The line that triggers the panic is here: The code change in question broke the handling of (i.e. no bundle) which is used when building on mingw. See here for an example: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Note that we have on the rustc command line. So we have the same lib twice and one has modifiers which triggers the error. It should actually trigger an error but panics before...
Yes, the ICE is caused by used to determine the span for the error. There's a PR in progress that fixes that - Even without ICE you'll need a workaround for the error that it's masking - linking the library with modifiers either only from command line, or only from attributes. will relax these restrictions as well.
The ICE is a regression from
Fixed in

Discussion:
// involved or not, library reordering and kind overriding without // explicit `:rename` in particular. if lib.has_modifiers() || passed_lib.has_modifiers() { <del> self.tcx.sess.span_err( self.tcx.def_span(lib.foreign_module.unwrap()), "overriding linking modifiers from command line is not supported" ); </del> <ins> let msg = "overriding linking modifiers from command line is not supported"; match lib.foreign_module { Some(def_id) => self.tcx.sess.span_err(self.tcx.def_span(def_id), msg), None => self.tcx.sess.err(msg), }; </ins> } if passed_lib.kind != NativeLibKind::Unspecified { lib.kind = passed_lib.kind;

<ins> // Regression test for issue #97299, one command line library with modifiers // overrides another command line library with modifiers. // compile-flags:-lstatic:+whole-archive=foo -lstatic:+whole-archive=foo // error-pattern: overriding linking modifiers from command line is not supported fn main() {} </ins>

<ins> error: overriding linking modifiers from command line is not supported error: aborting due to previous error </ins>
Change:
If you try to do , it doesn't work: Same goes for and . label A-rustbuild
Why did you expect these to work? The following should work: , . I think currently this is by design. Or is this a feature request to make basically ?
Yeah it's a feature request. I filed it upon invitation of after he asked about pain points of bootstrap : https://rust-
Yeah this exactly.
Update: still doesn't work today (now with the tests/ dir).

Discussion:
} } <del> const PATH_REMAP: &[(&str, &str)] = &[("rust-analyzer-proc-macro-srv", "proc-macro-srv-cli")]; fn remap_paths(paths: &mut [&Path]) { for path in paths.iter_mut() { </del> <ins> const PATH_REMAP: &[(&str, &[&str])] = &[ // config.toml uses `rust-analyzer-proc-macro-srv`, but the // actual path is `proc-macro-srv-cli` ("rust-analyzer-proc-macro-srv", &["proc-macro-srv-cli"]), // Make `x test tests` function the same as `x t tests/*` ( "tests", &[ "tests/assembly", "tests/codegen", "tests/codegen-units", "tests/coverage", "tests/coverage-run-rustdoc", "tests/debuginfo", "tests/incremental", "tests/mir-opt", "tests/pretty", "tests/run-make", "tests/run-make-fulldeps", "tests/run-pass-valgrind", "tests/rustdoc", "tests/rustdoc-gui", "tests/rustdoc-js", "tests/rustdoc-js-std", "tests/rustdoc-json", "tests/rustdoc-ui", "tests/ui", "tests/ui-fulldeps", ], ), ]; fn remap_paths(paths: &mut Vec<&Path>) { let mut remove = vec![]; let mut add = vec![]; for (i, path) in paths .iter() .enumerate() .filter_map(|(i, path)| if let Some(s) = path.to_str() { Some((i, s)) } else { None }) { </ins> for &(search, replace) in PATH_REMAP { <del> if path.to_str() == Some(search) { *path = Path::new(replace) </del> <ins> // Remove leading and trailing slashes so `tests/` and `tests` are equivalent if path.trim_matches(std::path::is_separator) == search { remove.push(i); add.extend(replace.into_iter().map(Path::new)); break; </ins> } } } <ins> remove.sort(); remove.dedup(); for idx in remove.into_iter().rev() { paths.remove(idx); } paths.append(&mut add); </ins> } impl StepDescription {
Change:
We should experiment with making the field in boxed and run perf to see if that improves compilation times. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Actually, I'm not sure I understand how this (alone) could yield any improvement; is there something more to the proposed changes? As it stands, purely boxing the field will surely only add heap allocation cost?
Thanks for looking into this! It depends entirely on the access patterns. Some of the diagnostic metadata substructs we have elsewhere in the compiler are accessed very rarely, while their parent struct is moved/copied/cloned often, so moving those into the heap provides improvements due to better caching/inlining. I had a hunch that this particular case might not be too impactful, but it was worth testing (and there are a handful of cases where there seems to be benefit!).

Discussion:
current_trait_ref: Option<(Module<'a>, TraitRef)>, /// Fields used to add information to diagnostic errors. <del> diagnostic_metadata: DiagnosticMetadata<'ast>, </del> <ins> diagnostic_metadata: Box<DiagnosticMetadata<'ast>>, </ins> /// State used to know whether to ignore resolution errors for function bodies. ///

label_ribs: Vec::new(), lifetime_ribs: Vec::new(), current_trait_ref: None, <del> diagnostic_metadata: DiagnosticMetadata::default(), </del> <ins> diagnostic_metadata: Box::new(DiagnosticMetadata::default()), </ins> // errors at module scope should always be reported in_func_body: false, lifetime_uses: Default::default(),
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 on AVR (arduino Uno = atmega328p) with opt-level="z": I expected to see this happen: Instead, this happened: An alternate code that emits the correct output is This compiler error is corrupting the pixel stream transmitted via SPI to an ST7789 display from an Arduino Uno. What appears to be happening is that instead of the bytes being swapped, the LSB is being copied to the MSB. I do not have the expertise to decompile and examine the assembly code. : The malfunction also occurs with . The full code can be cloned from <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Since I looked it up, here's the expected/actual in hex, which makes the bug more clear: input: expected: actual:
Hi, Could you please check with ? It feels like a bug nonetheless, but I'm curious about the result
Also: claim
I'm analyzing the codegen bug - simplest reproduction so far:
Got it! The simplest reproduction: This prints ( in hex) instead of ( in hex), because the generated binary accidentally overwrites the high-order byte with the low-order one: ! After calling ( on the screenshot), the returned number - ( in hex) - gets stored into r23:r24 (you can see that r23=0x39, r24=0x30, and AVR being little-endian means the number is reconstructed from r24 first, r23 second). expects its parameter to be stored in , so right before calling , the codegen has a simple job: move into ; and that's where the bug comes into play. What the code generator says is: ... which always sets and to the same value () - what it should generate instead is: Overall, that's an omission on the LLVM's side (when moving register pairs, it should consider whether the registers are overlapping or not) - I'll try to prepare a patch Edit:
I just updated to nightly-2022-07-08 and some weirdness I was seeing with seems to have been fixed. Under nightly-2022-05-10 I would see this in the serial log: Under nightly-2022-07-08 I get It also fixed the problems I was having with the st7789 crate that led me to file this bug.

Discussion:
<del> Subproject commit d1ddc34c4b23468f6d2bf553084834b104e16dde </del> <ins> Subproject commit 8b6b5014fdad3a750f7242a6bfdcad83619498d4 </ins>
Change:
In code like the following, the compiler misses a possible optimization: in , the length of is equal to the length of , yet the compiler generates a call to . The compiler knows the lengths are equal (and thus, the panic is unreachable), because the following snippet optimizes the panic away: This is a regression between rustc versions 1.51 and 1.52.
label I-slow, E-needs-bisection
This seems to be fixed on nightly. label E-needs-test Bisection would still be interesting IMO, both for the regression and the fix.
Alright, that’s pretty boring in terms of rustc-bisection: it was fixed by (Update to LLVM 15), and it regressed in which includes (Upgrade[^1] to LLVM 12). label -E-needs-bisection, +A-llvm. [^1]: what’s up with the inconsistent naming, upgrade vs. update?

Discussion:
<ins> // min-llvm-version: 15.0.0 // ignore-debug: The debug assertions get in the way // compile-flags: -O #![crate_type = "lib"] // There should be no calls to panic / len_mismatch_fail. #[no_mangle] pub fn test(a: &mut [u8], offset: usize, bytes: &[u8]) { // CHECK-LABEL: @test( // CHECK-NOT: call // CHECK: call void @llvm.memcpy // CHECK-NOT: call // CHECK: } if let Some(dst) = a.get_mut(offset..offset + bytes.len()) { dst.copy_from_slice(bytes); } } </ins>