jiebi/CodeConvo huggingface dataset:
Change:
<!-- [31mICE[0m: Rustc '' 'assertion failed ' left: Binder(fn(), [])' ' right: Binder(fn(), [Region(BrNamed(DefId(0:4 ~ 9CACA62BEBDE508A04F27A9C164063CBF2C6A046198481389A0AC4A29C2578C3[3bbd]::cmp::'a), 'a))])'', 'assertion failed ' left: Binder(fn(), [])' ' right: Binder(fn(), [Region(BrNamed(DefId(0:4 ~ 9CACA62BEBDE508A04F27A9C164063CBF2C6A046198481389A0AC4A29C2578C3[3bbd]::cmp::'a), 'a))])'' 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: [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
Regression in cc
that seems off :sweat_smile: this PR should not result in behavior differences
ah yes my bad :D I left in by accident from a previous bisection and that was the pr that the flag :laughing:
should exist since pretty much forever :grin: 1.48
Regression in nightly-2023-04-20 fetching (via remote github) commits from max(, 2023-04-17) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 10 commit[0] 2023-04-18: Auto merge of - petrochenkov:slimchild, r=cjgillot commit[1] 2023-04-18: Auto merge of - saethlin:encode-hashes-as-bytes, r=cjgillot commit[2] 2023-04-19: Auto merge of - jyn514:download-rustc-tests, r=albertlarsan68 commit[3] 2023-04-19: Auto merge of - miguelraz:canoodling2-electric-boogaloo, r=compiler-errors commit[4] 2023-04-19: Auto merge of - matthiaskrgr:rollup-9m7rw3u, r=matthiaskrgr commit[5] 2023-04-19: Auto merge of - Nilstrieb:fluent-macro, r=davidtwco commit[6] 2023-04-19: Auto merge of - fee1-dead-contrib:rm-const-traits, r=oli-obk commit[7] 2023-04-19: Auto merge of - WaffleLapkin:‍sound, r=compiler-errors commit[8] 2023-04-19: Auto merge of - matthiaskrgr:rollup-346kik6, r=matthiaskrgr commit[9] 2023-04-19: Auto merge of - ecnelises:big_archive, r=bjorn3
This might be related to cc one nightly before this errors with so maybe const-related
the cause is that the assert mentioned in is wrong. COmparing pointers with different bound vars is ok. This should either use actual semantic equality or just yeet the assert

Discussion:
if is_int_bool_or_char(lhs_ty) && is_int_bool_or_char(rhs_ty) { // Int, bool, and char operations are fine. } else if lhs_ty.is_fn_ptr() || lhs_ty.is_unsafe_ptr() { <del> assert_eq!(lhs_ty, rhs_ty); </del> assert!(matches!( op, BinOp::Eq

<ins> const fn cmp(x: fn(&'static ()), y: for<'a> fn(&'a ())) -> bool { x == y //~^ ERROR pointers cannot be reliably compared during const eval } fn main() {} </ins>

<ins> error: pointers cannot be reliably compared during const eval --> $DIR/different-fn-ptr-binders-during-ctfe.rs:2:5 | LL |     x == y |     ^^^^^^ | = note: see issue #53020 <https://github.com/rust-lang/rust/issues/53020> for more information error: aborting due to 1 previous error </ins>
Change:
I tried on Rust 1.76.0: I got the following error: Note that the suggestion has stripped the leading character from the enum's name.
Can confirm this is still present in nightly.
Sounds like fun. Taking a look.
So it is intended this way from what I can see in the source code: Improving the wording would be become to clear the confusion though I think.

Discussion:
{ // When the suggested binding change would be from `x` to `_x`, suggest changing the // original binding definition instead. (#60164) <del> (span, snippet, ", consider changing it") </del> <ins> let post = format!(", consider renaming `{}` into `{snippet}`", suggestion.candidate); (span, snippet, post) </ins> } else { <del> (span, suggestion.candidate.to_string(), "") </del> <ins> (span, suggestion.candidate.to_string(), String::new()) </ins> }; let msg = match suggestion.target { SuggestionTarget::SimilarlyNamed => format!(

LL |     let _y = x; |              ^ | <del> help: a local variable with a similar name exists, consider changing it </del> <ins> help: a local variable with a similar name exists, consider renaming `_x` into `x` </ins> | LL |     let x = 42; |         ~
Change:
Compilation of any code using the atomics feature flag for the wasm target fails when building the std library due to the following error: I tried this code: With these flags enabled I expected to see this happen: Compilation succesful Instead, this happened: : <details<summaryBacktrace</summary<pBacktrace doesn't seem to add useful information. </p</details
While playing around locally, adding this, in fixes the compiler error, not sure if there are undesired side effects.
That looks great! Would you be willing to submit a PR?
Definitely!

Discussion:
use crate::ffi::CStr; <ins> use crate::ffi::CString; </ins> use crate::io; use crate::num::NonZero; use crate::sys::unsupported;

pub fn yield_now() {} pub fn set_name(_name: &CStr) {} <ins> pub fn get_name() -> Option<CString> { None } </ins> pub fn sleep(dur: Duration) { use crate::arch::wasm32;
Change:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'called on an value: failed while formatting fluent string : '', 'thread 'rustc' panicked at 'called on an value: failed while formatting fluent string : '' 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: --
Slightly smaller:
cc
Somehow this subdiag enum being to a diagnostic causes but the looks okay to me...?
Also suspicious:
Seems like for the subdiag whose fluent messages contain a variable, they need to be eagerly translated via instead of using . However I'm not very familiar with this distinction.

Discussion:
{ err.note("you may be trying to write a c-string literal"); err.note("c-string literals require Rust 2021 or later"); <del> HelpUseLatestEdition::new().add_to_diagnostic(&mut err); </del> <ins> err.subdiagnostic(self.dcx(), HelpUseLatestEdition::new()); </ins> } // `pub` may be used for an item or `pub(crate)`

<ins> enum will { s#[c"owned_box"] //~^ERROR expected one of `(`, `,`, `=`, `{`, or `}`, found `#` //~|ERROR expected item, found `"owned_box"` } </ins>

<ins> error: expected one of `(`, `,`, `=`, `{`, or `}`, found `#` --> $DIR/help-set-edition-ice-122130.rs:2:6 | LL |     s#[c"owned_box"] |      ^ expected one of `(`, `,`, `=`, `{`, or `}` | = note: you may be trying to write a c-string literal = note: c-string literals require Rust 2021 or later = help: pass `--edition 2021` to `rustc` = note: for more on editions, read https://doc.rust-lang.org/edition-guide error: expected item, found `"owned_box"` --> $DIR/help-set-edition-ice-122130.rs:2:9 | LL |     s#[c"owned_box"] |         ^^^^^^^^^^^ expected item | = note: for a full list of items that can appear in modules, see <https://doc.rust-lang.org/reference/items.html> error: aborting due to 2 previous errors </ins>
Change:
I tried this code: running I expected to see this happen: Nothing Instead, this happened: wine: Unhandled page fault on read access to 726F735F at address 7AADD340 (thread 0734), starting debugger... Running with using the 64bit target, no crash happens, as expected. :
Would be helpful to get a backtrace of the crash. maybe you have ideas
Of course! This is what windbg gave me: Please note that I got a crash from a different wine version (sorry, can't recall which one) as well.
The current Wine stable version is 9.0. Please try the latest stable Wine.
Also, it's not clear from your report that you actually have full 32-bit Windows support installed. It is not enough to simply have Wine installed to get that. You have to have a fully and correctly configured multilib setup. . Do other_ 32-bit Windows applications run on the system in question and successfully perform crash reporting with dbghelp?
Yes, I have a good setup - I run a lot of 32-bit applications (mostly Starcraft 1.16.1 and 32-bit applications connecting to it). Here is an updated "program": This was with the same wine version, now let's retry with wine 9.0. I replaced the println with backtrace again: And the backtrace from winedbg: I will do another one with wine-devel 9.3.
I omitted the backtrace, its basically the same.
Aha, thanks for the followup info! We think we have a fix for this en route.

Discussion:
<del> Subproject commit 6145fe6bac65c38375f1216a565a6cc7deb89a2d </del> <ins> Subproject commit ddf1b89b861d297c6ef3f09b70d853e81ccc85ff </ins>
Change:
The following code leaks memory: Miri error: The equivalent code with , so I think this is a bug. Cc
I guess this is not too surprising... has but has nothing like that.
Oh, that's may bad. I assumed that RawWaker handled ownership. I can push a PR today in the evening.
This leads to a miri-test-libstd failure every day, would be nice to get a fix soon. :)

Discussion:
/// /// [`poll()`]: crate::future::Future::poll #[inline] <del> #[stable(feature = "futures_api", since = "1.36.0")] </del> <ins> #[unstable(feature = "local_waker", issue = "118959")] </ins> pub fn wake(self) { // The actual wakeup call is delegated through a virtual function call // to the implementation which is defined by the executor.

/// the case where an owned `Waker` is available. This method should be preferred to /// calling `waker.clone().wake()`. #[inline] <del> #[stable(feature = "futures_api", since = "1.36.0")] </del> <ins> #[unstable(feature = "local_waker", issue = "118959")] </ins> pub fn wake_by_ref(&self) { // The actual wakeup call is delegated through a virtual function call // to the implementation which is defined by the executor.

/// avoid cloning the waker when they would wake the same task anyway. #[inline] #[must_use] <del> #[stable(feature = "futures_api", since = "1.36.0")] </del> <ins> #[unstable(feature = "local_waker", issue = "118959")] </ins> pub fn will_wake(&self, other: &LocalWaker) -> bool { self.waker == other.waker }

/// Therefore this method is unsafe. #[inline] #[must_use] <del> #[stable(feature = "futures_api", since = "1.36.0")] </del> <ins> #[unstable(feature = "local_waker", issue = "118959")] </ins> #[rustc_const_unstable(feature = "const_waker", issue = "102012")] pub const unsafe fn from_raw(waker: RawWaker) -> LocalWaker { Self { waker }

} } <del> #[stable(feature = "futures_api", since = "1.36.0")] </del> <ins> #[unstable(feature = "local_waker", issue = "118959")] impl Drop for LocalWaker { #[inline] fn drop(&mut self) { // SAFETY: This is safe because `LocalWaker::from_raw` is the only way // to initialize `drop` and `data` requiring the user to acknowledge // that the contract of `RawWaker` is upheld. unsafe { (self.waker.vtable.drop)(self.waker.data) } } } #[unstable(feature = "local_waker", issue = "118959")] </ins> impl fmt::Debug for LocalWaker { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { let vtable_ptr = self.waker.vtable as *const RawWakerVTable;
Change:
<!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unhandled type: {type error}', 'error: internal compiler error: unhandled type: {type error}' 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: [mirdropselaboratedandconst_checked] elaborating drops for [analysis] running analysis passes on this crate --
cc ^^

Discussion:
<ins> type Foo = impl Send; //~^ ERROR `impl Trait` in type aliases is unstable struct A; const VALUE: Foo = value(); //~^ ERROR cannot find function `value` in this scope fn test() { match VALUE { 0 | 0 => {} //~^ ERROR mismatched types //~| ERROR mismatched types _ => (), } } fn main() {} </ins>

<ins> error[E0658]: `impl Trait` in type aliases is unstable --> $DIR/ice-unhandled-type-122191.rs:1:12 | LL | type Foo = impl Send; |            ^^^^^^^^^ | = note: see issue #63063 <https://github.com/rust-lang/rust/issues/63063> for more information = help: add `#![feature(type_alias_impl_trait)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date error[E0425]: cannot find function `value` in this scope --> $DIR/ice-unhandled-type-122191.rs:6:20 | LL | const VALUE: Foo = value(); |                    ^^^^^ not found in this scope error[E0308]: mismatched types --> $DIR/ice-unhandled-type-122191.rs:11:9 | LL | type Foo = impl Send; |            --------- the expected opaque type ... LL |     match VALUE { |           ----- this expression has type `Foo` LL |         0 | 0 => {} |         ^ expected opaque type, found integer | = note: expected opaque type `Foo` found type `{integer}` note: this item must have the opaque type in its signature in order to be able to register hidden types --> $DIR/ice-unhandled-type-122191.rs:9:4 | LL | fn test() { |    ^^^^ error[E0308]: mismatched types --> $DIR/ice-unhandled-type-122191.rs:11:13 | LL | type Foo = impl Send; |            --------- the expected opaque type ... LL |     match VALUE { |           ----- this expression has type `Foo` LL |         0 | 0 => {} |             ^ expected opaque type, found integer | = note: expected opaque type `Foo` found type `{integer}` note: this item must have the opaque type in its signature in order to be able to register hidden types --> $DIR/ice-unhandled-type-122191.rs:9:4 | LL | fn test() { |    ^^^^ error: aborting due to 4 previous errors Some errors have detailed explanations: E0308, E0425, E0658. For more information about an error, try `rustc --explain E0308`. </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. --Note that I can’t reproduce this SIGILL with , only sandybridge or higher (including native). The crate I wanted to build is , here is a minimal version: <!-- 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
LLVM assertion:
Upstream issue:
label llvm-fixed-upstream

Discussion:
<del> Subproject commit 7973f3560287d750500718314a0fd4025bd8ac0e </del> <ins> Subproject commit 84f190a4abf58bbd5301c0fc831f7a96acea246f </ins>
Change:
The output is miles of errors like this: I think this target has somehow slipped past our CI? Maybe I'm searching our codebase wrong, but I don't think I can find any tests for it? Note that this affects the target specifically, as identified by the Miri cron job that tries to build all tier 2 targets: which just failed: cc target maintainers:
I'm sorry. The is incorrectly written in the Tier 2 table in .

Discussion:
`i686-unknown-freebsd` | ✓ | 32-bit FreeBSD [^x86_32-floats-return-ABI] `i686-unknown-linux-musl` | ✓ | 32-bit Linux with musl 1.2.3 [^x86_32-floats-return-ABI] [`i686-unknown-uefi`](platform-support/unknown-uefi.md) | * | 32-bit UEFI <del> [`loongarch64-unknown-linux-musl`](platform-support/loongarch-linux.md) | ? |  | LoongArch64 Linux (LP64D ABI) with musl 1.2.3 </del> [`loongarch64-unknown-none`](platform-support/loongarch-none.md) | * |  | LoongArch64 Bare-metal (LP64D ABI) [`loongarch64-unknown-none-softfloat`](platform-support/loongarch-none.md) | * |  | LoongArch64 Bare-metal (LP64S ABI) [`nvptx64-nvidia-cuda`](platform-support/nvptx64-nvidia-cuda.md) | * | --emit=asm generates PTX code that [runs on NVIDIA GPUs]

`i686-uwp-windows-msvc` | ? |  | [^x86_32-floats-return-ABI] [`i686-win7-windows-msvc`](platform-support/win7-windows-msvc.md) | ✓ |   | 32-bit Windows 7 support [^x86_32-floats-return-ABI] `i686-wrs-vxworks` | ? |  | [^x86_32-floats-return-ABI] <ins> [`loongarch64-unknown-linux-musl`](platform-support/loongarch-linux.md) | ? |  | LoongArch64 Linux (LP64D ABI) with musl 1.2.3 </ins> [`m68k-unknown-linux-gnu`](platform-support/m68k-unknown-linux-gnu.md) | ? |  | Motorola 680x0 Linux `mips-unknown-linux-gnu` | ✓ | ✓ | MIPS Linux (kernel 4.4, glibc 2.23) `mips-unknown-linux-musl` | ✓ |  | MIPS Linux with musl 1.2.3
Change:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
Ah, of course, we want to the returned by .
I will try to remedy the situation. claim

Discussion:
prev_token_before_parsing: Token, error: &mut Diag<'_>, ) { <del> if ((style == PathStyle::Expr && self.parse_paren_comma_seq(|p| p.parse_expr()).is_ok()) || (style == PathStyle::Pat && self </del> <ins> match style { PathStyle::Expr if let Ok(_) = self .parse_paren_comma_seq(|p| p.parse_expr()) .map_err(|error| error.cancel()) => {} PathStyle::Pat if let Ok(_) = self </ins> .parse_paren_comma_seq(|p| { p.parse_pat_allow_top_alt( None,

CommaRecoveryMode::LikelyTuple, ) }) <del> .is_ok())) && !matches!(self.token.kind, token::ModSep | token::RArrow) { error.span_suggestion_verbose( prev_token_before_parsing.span, format!( "consider removing the `::` here to {}", match style { PathStyle::Expr => "call the expression", PathStyle::Pat => "turn this into a tuple struct pattern", _ => { return; } } ), "", Applicability::MaybeIncorrect, ); </del> <ins> .map_err(|error| error.cancel()) => {} _ => { return; } </ins> } <ins> if let token::ModSep | token::RArrow = self.token.kind { return; } error.span_suggestion_verbose( prev_token_before_parsing.span, format!( "consider removing the `::` here to {}", match style { PathStyle::Expr => "call the expression", PathStyle::Pat => "turn this into a tuple struct pattern", _ => { return; } } ), "", Applicability::MaybeIncorrect, ); </ins> } /// Parses generic args (within a path segment) with recovery for extra leading angle brackets.

<ins> fn main() { unsafe { dealloc(ptr2, Layout::(x: !)(1, 1)); //~ ERROR: expected one of `!`, `(`, `)`, `+`, `,`, `::`, or `<`, found `:` //~^ ERROR: expected one of `.`, `;`, `?`, `}`, or an operator, found `)` //~| while parsing this parenthesized list of type arguments starting here } } </ins>

<ins> error: expected one of `!`, `(`, `)`, `+`, `,`, `::`, or `<`, found `:` --> $DIR/diagnostics-parenthesized-type-arguments-ice-issue-122345.rs:3:33 | LL |         dealloc(ptr2, Layout::(x: !)(1, 1)); |                             --- ^ expected one of 7 possible tokens |                             | |                             while parsing this parenthesized list of type arguments starting here error: expected one of `.`, `;`, `?`, `}`, or an operator, found `)` --> $DIR/diagnostics-parenthesized-type-arguments-ice-issue-122345.rs:3:43 | LL |         dealloc(ptr2, Layout::(x: !)(1, 1)); |                                           ^ expected one of `.`, `;`, `?`, `}`, or an operator error: aborting due to 2 previous errors </ins>
Change:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: could not unify with revealed type:', 'error: internal compiler error: could not unify with revealed type:' 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: [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
crashes since cc
Note: ICEs aren't crashes, we have a separate label for crashes (they mean segfaults and similar)
ungraceful exit of the compiler has been observed since :upsidedownface:
This has nothing to do with non-lifetime binders. I somewhat expect that when a "minimized" repro is tagged with a feature tag, there has been an attempt to check that the ICE is actually dependent on the feature, since that affects the prioritization of the issue.

Discussion:
match ocx.eq(&misc_cause, param_env, opaque_ty, hidden_ty) { Ok(()) => {} Err(ty_err) => { <ins> // Some types may be left "stranded" if they can't be reached // from an astconv'd bound but they're mentioned in the HIR. This // will happen, e.g., when a nested opaque is inside of a non- // existent associated type, like `impl Trait<Missing = impl Trait>`. // See <tests/ui/impl-trait/stranded-opaque.rs>. </ins> let ty_err = ty_err.to_string(tcx); <del> tcx.dcx().span_bug( </del> <ins> let guar = tcx.dcx().span_delayed_bug( </ins> span, format!("could not unify `{hidden_ty}` with revealed type:n{ty_err}"), ); <ins> return Err(guar); </ins> } }

<ins> trait Trait {} impl Trait for i32 {} // Since `Assoc` doesn't actually exist, it's "stranded", and won't show up in // the list of opaques that may be defined by the function. Make sure we don't // ICE in this case. fn produce<T>() -> impl Trait<Assoc = impl Trait> { //~^ ERROR associated type `Assoc` not found for `Trait` 16 } fn main () {} </ins>

<ins> error[E0220]: associated type `Assoc` not found for `Trait` --> $DIR/stranded-opaque.rs:8:31 | LL | fn produce<T>() -> impl Trait<Assoc = impl Trait> { |                               ^^^^^ associated type `Assoc` not found error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0220`. </ins>