jiebi/CodeConvo huggingface dataset:
Change:
Since , itself gets documented. Unfortunately, the package contains a binary crate called (, Shim which is passed to Cargo as “rustdoc” when running the bootstrap.) which clashes with the actual package () overwriting the latter since it gets documented last. See for yourself: (this ain't rustdoc). CC (). label C-bug T-bootstrap A-docs A-contributor-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
ah, thanks! I think the fix is to pass to cargo so it doesn't try to document the binaries, they don't have anything useful.
Alternatively - maybe better? - we could rename to , which seems more clear anyway.
claim

Discussion:
cargo.arg("-Zskip-rustdoc-fingerprint"); // Only include compiler crates, no dependencies of those, such as `libc`. cargo.arg("--no-deps"); <ins> cargo.arg("--lib"); </ins> $( cargo.arg("-p").arg($krate); )+
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 --
claim
Regression in

Discussion:
{ let opaque_ty = tcx.fold_regions(unshifted_opaque_ty, |re, _depth| { match re.kind() { <del> ty::ReEarlyBound(_) | ty::ReFree(_) | ty::ReError(_) => re, </del> <ins> ty::ReEarlyBound(_) | ty::ReFree(_) | ty::ReError(_) | ty::ReStatic => re, </ins> r => bug!("unexpected region: {r:?}"), } });

<ins> // check-pass #![allow(incomplete_features)] #![feature(adt_const_params, return_position_impl_trait_in_trait)] pub struct Element; pub trait Node { fn elements<const T: &'static str>(&self) -> impl Iterator<Item = Element>; } fn main() {} </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. --I tried this code: In windows terminal running Git Bash (also occured in Nushell, though I'm not sure if this is terminal or shell-land), I pressed Ctrl-Z + Enter to send EOF. I expected to see this happen: The application would gracefully exit the loop Instead, this happened: I saw this error message: <!-- 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<summaryBacktrace</summary<p</p</details
The underlying regression here is that the way we call does not accept zero length strings. And we're calling in a way that makes ctrl-z immediately return without reading anything after it. This is important because a zero length read is how we signal to stdlib that an eof has occurred (so ctrl-z handling is pretty indirect). The fix is simple, if anyone wants to claim this issue. needs to check for zero length input and immediately return in that case.
Seems like a good first issue, I can take a stab at it.
That would be great!
Where would be a good place to write a test for this?
Hm, this is a Windows specific issue so it should probably stay close to the affected code. Take a look at how for tests and do something similar for stdio.
Never mind, I see how things are glued together.
It's a sub module so it should be able to access the private functions of its parent (aka ) module. This is noted in the :
For sure, just misread the directory structure.

Discussion:
use crate::sys::handle::Handle; use core::str::utf8_char_width; <ins> #[cfg(test)] mod tests; </ins> // Don't cache handles but get them fresh for every read/write. This allows us to track changes to // the value over time (such as if a process calls `SetStdHandle` while it's running). See #40490. pub struct Stdin {

debug_assert!(utf16.len() <= c::c_int::MAX as usize); debug_assert!(utf8.len() <= c::c_int::MAX as usize); <ins> if utf16.is_empty() { return Ok(0); } </ins> let result = unsafe { c::WideCharToMultiByte( c::CP_UTF8,              // CodePage

<ins> use super::utf16_to_utf8; #[test] fn zero_size_read() { assert_eq!(utf16_to_utf8(&[], &mut []).unwrap(), 0); } </ins>
Change:
The reproduction is fuzzer-generated custom MIR then (somewhat) minimised. I couldn't rewrite it into surface Rust as there are back edges to non-dominating basic blocks (they can't be turned into surface Rust loops). It's possible that rustc considers such control flow invalid, though this is likely an LLVM miscompilation and such control flow is valid at LLVM IR level. Miri also does not complain. The actual execution flow has no loops, all statements are executed only once. Indented BBs are not taken, but still required for the reproduction. In Miri, the program is UB-free under both Stacked Borrows and Tree Borrows. The correct result is 1 at , it prints 255, which is clearly wrong as the value came from a bool to int cast. prevents the miscompilation, also does. Implying either the generated IR has UB or this is a bug in LLVM Only reproducible on x8664 Linux, not Apple Silicon macOS (This is still reproducible even with applied, so it's a separate bug) I tried to get a standalone LLVM IR file using approach in by having in helper C code, but I couldn't reproduce the misoptimisation with since the pre-populated passes from rustc are required for the reproduction, which does not replicate (or not in the same order) cc
Cleaned up input IR: After : After llc: So this looks like a backend bug.
Yes it's an x86 backend bug
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler
Is this a regression (from-stable-to-stable?)
Since the Rust reproduction is in custom MIR, it's hard to test using older nightlies as a lot of expressions are only parsable recently. But on the LLVM side the bug existed since LLVM 9: , which Rust started using from 1.38.0

Discussion:
[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/16.0-2023-04-05 </del> <ins> branch = rustc/16.0-2023-06-05 </ins> [submodule "src/doc/embedded-book"] path = src/doc/embedded-book url = https://github.com/rust-embedded/book.git

<del> Subproject commit 533d3f338b804d54e5d0ac4fba6276af23002d9c </del> <ins> Subproject commit 22897bce7bfedc9cd3953a33419b346936263500 </ins>
Change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
reduced a bit `
Ah another bug ^^. label T-compiler A-synthetic-impls A-auto-traits
reduce:
All three reproducers will be fixed by .
I can no longer reproduce any of these issues.

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>
Change:
In the WinAPI definitions have been replaced by windows-bindgen generated bindings. However, the project does not generate metadata for ARM32-specific items, hence the generated bindings lack a few types like and on this platform. It effectively breaks for Rust.
Unfortunately, 32-bit ARM is not being supported by Microsoft going forward. What we could do is insert our own definitions in , copied from before the changes.
Besides the issue with ARM, all UWP targets actually have problems with linkage as well. Previously the APIs forbidden on UWP are gated behind fine-grained conditional compilation flags, but it is no longer the case with generated ones. I got this when building the UWP app that links again a Rust staticlib. !
Iirc, the functions were never gated. But we loaded them lazily (and panicked if they didn't load). This did allow UWP targets to compile. No idea if they actually ran. I'm not sure who's responsible for these targets.
I think you are correct. I can reproduce the link errors with toolchain . Let me file another issue after I pinpoint the underlying problem.
Oh wait, as staticlib? You currently need to make sure to link all the libraries it depends on. You can get them using .
This will fail Windows App Cert Kit tests. !
In that case I'm surprised that lazy loading worked.
WG-prioritization assigning priority (). label -I-prioritize +P-low

Discussion:
*self } } <ins> // Begin of ARM32 shim // The raw content of this file should be processed by `generate-windows-sys` // to be merged with the generated binding. It is not supposed to be used as // a normal Rust module. cfg_if::cfg_if! { if #[cfg(target_arch = "arm")] { #[repr(C)] pub struct WSADATA { pub wVersion: u16, pub wHighVersion: u16, pub szDescription: [u8; 257], pub szSystemStatus: [u8; 129], pub iMaxSockets: u16, pub iMaxUdpDg: u16, pub lpVendorInfo: PSTR, } pub enum CONTEXT {} } } // End of ARM32 shim </ins>

<ins> // Begin of ARM32 shim // The raw content of this file should be processed by `generate-windows-sys` // to be merged with the generated binding. It is not supposed to be used as // a normal Rust module. cfg_if::cfg_if! { if #[cfg(target_arch = "arm")] { #[repr(C)] pub struct WSADATA { pub wVersion: u16, pub wHighVersion: u16, pub szDescription: [u8; 257], pub szSystemStatus: [u8; 129], pub iMaxSockets: u16, pub iMaxUdpDg: u16, pub lpVendorInfo: PSTR, } pub enum CONTEXT {} } } // End of ARM32 shim </ins>

// ignore-tidy-filelength "#; <ins> /// This is a shim for the ARM (32-bit) architecture, which is no longer supported by windows-rs. const ARM_SHIM: &str = include_str!("arm_shim.rs"); </ins> fn main() -> io::Result<()> { let mut path: PathBuf = std::env::args_os().nth(1).expect("a path to the rust repository is required").into();

let mut f = std::fs::File::create(&path)?; f.write_all(PRELUDE.as_bytes())?; f.write_all(bindings.as_bytes())?; <ins> f.write_all(ARM_SHIM.as_bytes())?; </ins> Ok(()) }
Change:
Miri detects UB when running the following program: With and With
I see the bug. We have (which means fns in std automatically trap aborts) but that doesn't apply to functions which are present in the macro expansion (some of which can't really be moved outside the macro). Ill fix in like an hour or two. We just need to guard panics in a couple places. In practice I think this should not call problems and we'd just hit an abort guard in an defined in a few frames up, although perhaps that's not true in 100% of cases (I can update on this once I implement the fix).
The is that the fix to this may need to be backported thus I am tagging this with P-high.
the fix was merged and a backport was rejected:

Discussion:
// 1 == dtor registered, dtor not run // 2 == dtor registered and is running or has run #[thread_local] <del> static mut STATE: $crate::primitive::u8 = 0; </del> <ins> static STATE: $crate::cell::Cell<$crate::primitive::u8> = $crate::cell::Cell::new(0); // Safety: Performs `drop_in_place(ptr as *mut $t)`, and requires // all that comes with it. </ins> unsafe extern "C" fn destroy(ptr: *mut $crate::primitive::u8) { <del> let ptr = ptr as *mut $t; unsafe { $crate::debug_assert_eq!(STATE, 1); STATE = 2; $crate::ptr::drop_in_place(ptr); } </del> <ins> $crate::thread::local_impl::abort_on_dtor_unwind(|| { let old_state = STATE.replace(2); $crate::debug_assert_eq!(old_state, 1); // Safety: safety requirement is passed on to caller. unsafe { $crate::ptr::drop_in_place(ptr.cast::<$t>()); } }); </ins> } unsafe { <del> match STATE { </del> <ins> match STATE.get() { </ins> // 0 == we haven't registered a destructor, so do //   so now. 0 => {

$crate::ptr::addr_of_mut!(VAL) as *mut $crate::primitive::u8, destroy, ); <del> STATE = 1; </del> <ins> STATE.set(1); </ins> $crate::option::Option::Some(&VAL) } // 1 == the destructor is registered and the value

f.debug_struct("Key").finish_non_exhaustive() } } impl<T> Key<T> { pub const fn new() -> Key<T> { Key { inner: LazyKeyInner::new(), dtor_state: Cell::new(DtorState::Unregistered) }

} } } <ins> /// Run a callback in a scenario which must not unwind (such as a `extern "C" /// fn` declared in a user crate). If the callback unwinds anyway, then /// `rtabort` with a message about thread local panicking on drop. #[inline] pub fn abort_on_dtor_unwind(f: impl FnOnce()) { // Using a guard like this is lower cost. let guard = DtorUnwindGuard; f(); core::mem::forget(guard); struct DtorUnwindGuard; impl Drop for DtorUnwindGuard { #[inline] fn drop(&mut self) { // This is not terribly descriptive, but it doesn't need to be as we'll // already have printed a panic message at this point. rtabort!("thread local panicked on drop"); } } } </ins>

#[doc(hidden)] #[unstable(feature = "thread_local_internals", issue = "none")] pub mod local_impl { <del> pub use crate::sys::common::thread_local::{thread_local_inner, Key}; </del> <ins> pub use crate::sys::common::thread_local::{thread_local_inner, Key, abort_on_dtor_unwind}; </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. --interestingly the code compiles as soon as I remove and just make it a boring <!-- 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 --
Regression in nightly-2023-06-01 Regression in cc
just needs to check for inline const along with anon consts in
claim do you mean literally just adding ? Seems to fix the ICE on my end

Discussion:
// used generic parameters is a bug of evaluation, so checking for it // here does feel somewhat sensible. if !self.features().generic_const_exprs && ct.substs.has_non_region_param() { <del> assert!(matches!(self.def_kind(ct.def), DefKind::AnonConst)); </del> <ins> assert!(matches!( self.def_kind(ct.def), DefKind::InlineConst | DefKind::AnonConst )); </ins> let mir_body = self.mir_for_ctfe(ct.def); if mir_body.is_polymorphic { let Some(local_def_id) = ct.def.as_local() else { return };

<ins> // run-pass #![feature(inline_const_pat)] #![allow(dead_code)] #![allow(incomplete_features)] fn foo<const V: usize>() { match 0 { const { 1 << 5 } | _ => {} } } fn main() {} </ins>
Change:
title. I ran and nothing opened, cc (havent actually checked that PR caused this). still works <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
whoops yeah this is definitely my fault :sweatsmile: needs to be
claim
What is in this context? Looks like it wants a and "rustcdriver" doesn't seem to do the trick.
you might need to add a temporary binding in a higher scope so you can assign a String to it
That gives me a panic over at
does fix it?
It fixes the panic, but it doesn't fix the main issue (nothing opens).
ok, you'll have to figure out why that didn't work and what the proper fix is.
Ok, some more investigation: the builder wants to open which is "rust/build/x8664-unknown-linux-gnu/compiler-" but this file doesn't exist. builds that file, except under rustcmain, however. That's not much help. Is the idea behind your suggested fix, to compile rustcdriver if nothing else is provided, or to open the (assumedly compiled) docs if nothing else is provided? Currently in that function, . If the former is true, then the fix would be to check for if and pass the arg to cargo that way. If the latter is true, then there's a further bug in that isn't being compiled when it's supposed to be. Forgive the newcomer questions! If anyone wants to fix this before me, feel free - I see the prioritize label :)
If == [], that means we should build all the compiler crates. Maybe we need to add back the logic that was there before, to treat rustc_driver as the root? I guess since they're all part of the larger workspace doesn't do the right thing by default like it does elsewhere.
Just to be sure: It should open this? !

Discussion:
/// Compiler documentation is distributed separately, so we make sure /// we do not merge it with the other documentation from std, test and /// proc_macros. This is largely just a wrapper around `cargo doc`. <del> fn run(self, builder: &Builder<'_>) { </del> <ins> fn run(mut self, builder: &Builder<'_>) { </ins> let stage = self.stage; let target = self.target;

cargo.rustdocflag("ena=https://docs.rs/ena/latest/"); let mut to_open = None; <ins> if self.crates.is_empty() { self.crates = INTERNER.intern_list(vec!["rustc_driver".to_owned()]); }; </ins> for krate in &*self.crates { // Create all crate output directories first to make sure rustdoc uses // relative links.
Change:
Fuzzer generated code: This should output : But on it prints something different. masks the bug. This is only reproducible on , but not on or . The reproducer is very sensitive to small changes. For instance, changing the length of in to prevents the bug. For these reasons I suspect it's an Apple Silicon specific calling convention bug leading to some stack corruption. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label O-aarch64 O-macos
WG-prioritization assigning priority (). label -I-prioritize +P-high
I have another reproduction of what I believe is the same bug, but this one is only 34 lines, has only safe code and doesn't need a hasher: This should print but with The value of is different. In fact, the number commented "addend" in the original code gets to in the miscompiled result. If you change it to e.g. you get
Any chance that the fix for also fixes this one? Looks kinda similar to me.
No it fixes neither program in this issue. might be related, since it also passes a vector on the stack
Does this issue still reproduce?
Running on an MBP M1, with rustc 1.81.0-nightly ( 2024-06-12), I get the same hash output for both of the executions listed: <details</details
Thanks! Would you mind also trying the other test case in
That version does reproduce the issue:
Thanks!
I can reproduce this. claim
Upstream issue:
label +llvm-fixed-upstream

Discussion:
<del> Subproject commit 5a5152f653959d14d68613a3a8a033fb65eec021 </del> <ins> Subproject commit e6a6470d1eb4c88fee4b1ea98cd8e0ac4a181c16 </ins>
Change:
All of this is yanked out of my work-in-progress bug-for-bug Misskey Flavored markdown parser, which uses the trait, as defined below, to hopefully allow the compiler to create well-optimized functions via inlining and such. Where things get messy is in the introduction of the trait, which uses the same technique used by the and crates in order to remove the generic lifetime from its associated type, , since lifetime-only generic associated types aren't object-safe (yet?), despite lifetime-only generic parameters being object-safe. Object-safety is required in this case, because the syntax doesn't support cyclic types (for obvious reasons), so boxing and dynamic dispatch is necessary in order to break said cycle. as in, it behaves identically to , regardless of if that behavior is really "correct" behavior for a markdown parser or not._ <details<summarySorry for the rather large reproduction, this was as small as I was able to get it :sweat:</summary</details: <details<summary<strongBacktrace</strong</summary<p</p</details
Reduced:
Further reduced.
Further minimized:

Discussion:
// Return types are a bit more complex. They may contain opaque `impl Trait` types. let mir_output_ty = body.local_decls[RETURN_PLACE].ty; let output_span = body.local_decls[RETURN_PLACE].source_info.span; <del> if let Err(terr) = self.eq_types( normalized_output_ty, mir_output_ty, Locations::All(output_span), ConstraintCategory::BoringNoLocation, ) { span_mirbug!( self, Location::START, "equate_inputs_and_outputs: `{:?}=={:?}` failed with `{:?}`", normalized_output_ty, mir_output_ty, terr ); }; </del> <ins> self.equate_normalized_input_or_output(normalized_output_ty, mir_output_ty, output_span); </ins> } #[instrument(skip(self), level = "debug")]

<ins> //check-pass use higher_kinded_types::*; mod higher_kinded_types { pub(crate) trait HKT { type Of<'lt>; } pub(crate) trait WithLifetime<'lt> { type T; } impl<T: ?Sized + for<'any> WithLifetime<'any>> HKT for T { type Of<'lt> = <T as WithLifetime<'lt>>::T; } } trait Trait { type Gat<'lt>; } impl Trait for () { type Gat<'lt> = (); } /// Same as `Trait`, but using HKTs rather than GATs trait HTrait { type Hat: ?Sized + HKT; } impl<T: Trait> HTrait for T { type Hat = dyn for<'lt> WithLifetime<'lt, T = T::Gat<'lt>>; } impl<Hat: ?Sized + HKT> Trait for Box<dyn '_ + HTrait<Hat = Hat>> { type Gat<'lt> = Hat::Of<'lt>; } fn existential() -> impl for<'a> Trait<Gat<'a> = ()> {} fn dyn_hoops<T: Trait>( _: T, ) -> Box<dyn HTrait<Hat = dyn for<'a> WithLifetime<'a, T = T::Gat<'a>>>> { loop {} } fn main() { let _ = || -> _ { dyn_hoops(existential()) }; } </ins>