jiebi/CodeConvo huggingface dataset:
Change:
The diesel benchmark has been broken in some recent commit: ref:
The error seems to be caused (cc Curiously, this only happens in . Here's the error: The line where the error triggers is: You can reproduce this issue by: cloning the rustc-perf repo going to diesel-1.4.8 benchmark in that repo installing commit using running
How can I run this(rustc-perf repo) via locally built rustc?
might be related as well?
That indeed looks related, so should fix this ?
The comment also makes it look like will fix this.
Unfortunately, did not fix the issue. Using the build bors creates after merge , leads to the same error as above. to reproduce this, you just need to clone the rustc-perf repo and cd into . Then run and
Thanks, I will try to push a fix today.
I'm just gonna revert my original PR that introduced this overflow until I can create a version that works with diesel, given the perf regression of my "fix" and the remaining existence of this issue, so don't waste too much time on this.
I already found a fix
cc
I've started on minimizing this in , with the goal of removing the rustdoc special casing once I finish If someone could finish it up that would be extremely helpful - I think it's related to one of the impls on , if I define an identical trait in it doesn't overflow anymore. You can reproduce the overflow with .

Discussion:
// For cases like #95134 we would like to catch overflows early // otherwise they slip away away and cause ICE. let recursion_limit = self.tcx().recursion_limit(); <del> if !recursion_limit.value_within_limit(self.depth) { </del> <ins> if !recursion_limit.value_within_limit(self.depth) // HACK: Don't overflow when running cargo doc see #100991 && !self.tcx().sess.opts.actually_rustdoc { </ins> let obligation = Obligation::with_depth( self.cause.clone(), recursion_limit.0,
Change:
started ICEing between nightly-2022-07-15 and nightly-2022-07-16, looking at diff it's probably , so ? <!-- 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
Looks like file is created write-only here: and is trying to be read here: I haven't contributed here yet, but it looks to me like instead of would fix this. Should I make a PR? ~I unfortunately don't have a computer good enough to compile locally atm.~
That should probably works, , but looks little hacky.
I agree it looks wonky, but the only other option would be storing the path in and then creating a new read handle on it later, AFAIK. <-- I like this option much less.
bash mvce `

Discussion:
// shaves an instruction off those code paths (on x86 at least). assert!(capacity <= usize::MAX - max_leb128_len()); <del> let file = File::create(path)?; </del> <ins> // Create the file for reading and writing, because some encoders do both // (e.g. the metadata encoder when -Zmeta-stats is enabled) let file = File::options().read(true).write(true).create(true).truncate(true).open(path)?; </ins> Ok(FileEncoder { buf: Box::new_uninit_slice(capacity),
Change:
rustc version: rustc 1.65.0-nightly ( 2022-08-25) I have a very small reproducer for a weird fix advice from rustc when the two branches of an if had a type mismatch: This will produce the following output: Applying this fix obviously doesn't help:
label +A-diagnostics +T-compiler +D-invalid-suggestion

Discussion:
hir::def::CtorKind::Const => unreachable!(), }; <ins> // Suggest constructor as deep into the block tree as possible. // This fixes https://github.com/rust-lang/rust/issues/101065, // and also just helps make the most minimal suggestions. let mut expr = expr; while let hir::ExprKind::Block(block, _) = &expr.kind && let Some(expr_) = &block.expr { expr = expr_ } </ins> vec![ (expr.span.shrink_to_lo(), format!("{prefix}{variant}{open}")), (expr.span.shrink_to_hi(), close.to_owned()),

<ins> // check-fail // run-rustfix enum FakeResult<T> { Ok(T) } fn main() { let _x = if true { FakeResult::Ok(FakeResult::Ok(())) } else { FakeResult::Ok(FakeResult::Ok(())) //~ERROR E0308 }; } </ins>

<ins> // check-fail // run-rustfix enum FakeResult<T> { Ok(T) } fn main() { let _x = if true { FakeResult::Ok(FakeResult::Ok(())) } else { FakeResult::Ok(()) //~ERROR E0308 }; } </ins>

<ins> error[E0308]: `if` and `else` have incompatible types --> $DIR/issue-101065.rs:12:9 | LL |       let _x = if true { |  ______________- LL | |         FakeResult::Ok(FakeResult::Ok(())) | |         ---------------------------------- expected because of this LL | |     } else { LL | |         FakeResult::Ok(()) | |         ^^^^^^^^^^^^^^^^^^ expected enum `FakeResult`, found `()` LL | |     }; | |_____- `if` and `else` have incompatible types | = note: expected enum `FakeResult<FakeResult<()>>` found enum `FakeResult<()>` help: try wrapping the expression in `FakeResult::Ok` | LL |         FakeResult::Ok(FakeResult::Ok(())) |         +++++++++++++++                  + error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
Change:
The UEFI targets (x8664-unknown-uefi, i686-unknown-uefi, and aarch64-unknown-uefi) started failing to compile in the latest nightly when using , failing with "LLVM ERROR: dwo only supported with ELF and Wasm". : : Build: searched nightlies: from nightly-2022-08-25 to nightly-2022-08-27 regressed nightly: nightly-2022-08-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsCC since bisect pointed to
Can confirm. Definitely needs to be looked into by the team — can you reproduce this?
I see in that is set in . I think that needs to be in , or maybe directly in ? I tested this out locally by using a custom target JSON that matches except adds , and that seems to fix the bug.

Discussion:
<del> use crate::spec::{LinkerFlavor, LldFlavor, SplitDebuginfo, TargetOptions}; </del> <ins> use crate::spec::{DebuginfoKind, LinkerFlavor, LldFlavor, SplitDebuginfo, TargetOptions}; </ins> use std::borrow::Cow; pub fn opts() -> TargetOptions {

// where `*.pdb` files show up next to the final artifact. split_debuginfo: SplitDebuginfo::Packed, supported_split_debuginfo: Cow::Borrowed(&[SplitDebuginfo::Packed]), <ins> debuginfo_kind: DebuginfoKind::Pdb, </ins> ..Default::default() }

<del> use crate::spec::{cvs, DebuginfoKind, TargetOptions}; </del> <ins> use crate::spec::{cvs, TargetOptions}; </ins> pub fn opts() -> TargetOptions { let base = super::msvc_base::opts();

// not ever be possible for us to pass this flag. no_default_libraries: false, has_thread_local: true, <del> debuginfo_kind: DebuginfoKind::Pdb, </del> ..base }
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. --The  crate compiles on nightlies before (the LLVM 15 upgrade), but now it fails with this: The error happens both when natively compiling on Arch Linux, and when cross compiling from macOS as shown 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. --: searched nightlies: from nightly-2022-08-12 to nightly-2022-08-14 [originally searched from 2022-07-01; reduced range shown here because I restarted bisect due to a crash half way through] regressed nightly: nightly-2022-08-13 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
WG-prioritization assigning priority (). label -I-prioritize +P-high T-compiler
Upstream issue: Not sure why this starts with LLVM 15, as the issue itself is not new.

Discussion:
<del> Subproject commit e3be3f64ecac101d14ceda759ba078ad0aaf3747 </del> <ins> Subproject commit 670e5f673acb736acbfce65e0ffe2c8cd115b93f </ins>
Change:
Given the following code: The current output is: Ideally the output should look like: The code is already being compiled for the 2021 edition, there's no need to issue any warnings about behaviour that was different in 2018. The compiler should assume that the code is working as expected. This might affect other warnings in the same category, I'm not sure. Tested in 1.63, beta and nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
So, it seems that there are 3 warnings in this category and the issue only affects the closure one: is not affected because it checks that auto-ref happens, which doesn't in rust 2021 is not affected because the linted code simply doesn't compile in rust 2021 is affected
seems to be needed, because is marked with and the lint wants a significant impl MRE:

Discussion:
/// /// ### Example of drop reorder /// <del> /// ```rust,compile_fail </del> <ins> /// ```rust,edition2018,compile_fail </ins> /// #![deny(rust_2021_incompatible_closure_captures)] /// # #![allow(unused)] ///

/// /// ### Example of auto-trait /// <del> /// ```rust,compile_fail </del> <ins> /// ```rust,edition2018,compile_fail </ins> /// #![deny(rust_2021_incompatible_closure_captures)] /// use std::thread; ///

tcx: TyCtxt<'_>, closure_id: hir::HirId, ) -> bool { <ins> if tcx.sess.rust_2021() { return false; } </ins> let (level, _) = tcx.lint_level_at_node(lint::builtin::RUST_2021_INCOMPATIBLE_CLOSURE_CAPTURES, closure_id);

<ins> // check-pass // edition:2021 #![deny(rust_2021_compatibility)] pub struct Warns { // `Arc` has significant drop _significant_drop: std::sync::Arc<()>, field: String, } pub fn test(w: Warns) { _ = || drop(w.field); } fn main() {} </ins>
Change:
As of is not downloaded until the user runs . The rustc dev guide suggests setting the formatter to the rustfmt that is downloaded for stage0 in the build directory, but that is no longer downloaded with any other commands. (sorry for the delay in making this issue) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Hi have you had time to work on this? Let me know if anything is confusing and I'm happy to help out :)
Thank you!! Sorry for the delay in catching up. Am I correct that this Issue is about "at some point, make sure to automatically download rustfmt"? If so, I'm still not sure which file to fix. I think I somehow understood that this Issue is related to (i.e., no dependence on python scripts?)
That was the motivation for , right, we want to move all the logic out of the python script eventually. Not just at some point - it should be done on every invocation of bootstrap (assuming it hasn't been downloaded yet). Right now we only download it when someone runs x.py fmt. If you look at the PR I linked, it's currently in - I think moving it a line early to would be a good approach.
Is this picked up or shall i work on it?
no, is already working on it.
cool

Discussion:
job::setup(self); } <ins> // Download rustfmt early so that it can be used in rust-analyzer configs. let _ = &builder::Builder::new(&self).initial_rustfmt(); </ins> self.maybe_update_submodules(); if let Subcommand::Format { check, paths } = &self.config.cmd {
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!
Ah damn it, we keep getting broken so there's still no nightly with Miri. :(
Building std now ICEs on windows...? The same target works fine on my system, so it is host-specific. Sounds like one of the PRs in that rollup is buggy...
do you have a stack trace for that ICE?
Nope, I cannot reproduce so all we got is the . The ICE is .
Miri CI , not even in a Windows host. It's a 32bit host though. Would be great if someone with an x86_64 windows host could try to clone the Miri repo and do .
We're seeing a related-looking issue on Fuchsia on the same commit:
I'm unable to reproduce the ICE with on Btw the advice of results in a build error, because Miri was broken again by another PR.
This does look like my PR causes this.
Yeah when I wrote that, the other PR had not landed yet. ;)
Hm, that is odd. Not sure what the tools builder does differently, maybe it has debug assertions enabled? The line number in the ICE is so bad due to
Not sure how related they really are, the original ICE is some kind of out-of-bounds slice access within rustc itself... Could someone try upgrading Miri to current git master? Miri CI passes with latest rustc, after all... even if it fails again, we'll at least get better line numbers since was fixed. Maybe there is a way to run the windows tools runner without using up a full bors slot?
on it
Turns out the strange Windows-only ICE was caused by a buggy debug assertion:

Discussion:
/// It's guaranteed to be in the first place pub fn has_deref(&self) -> bool { // To make sure this is not accidently used in wrong mir phase <del> debug_assert!(!self.projection[1..].contains(&PlaceElem::Deref)); </del> <ins> debug_assert!( self.projection.is_empty() || !self.projection[1..].contains(&PlaceElem::Deref) ); </ins> self.projection.first() == Some(&PlaceElem::Deref) }

<del> Subproject commit dba35d2be72f4b78343d1a0f0b4737306f310672 </del> <ins> Subproject commit ef3f649e49607a1fad64eb0a5139110df3efa2a7 </ins>
Change:
: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(update, I've reproduced it on smaller example)
Error -ICE regression in 1.63 label regression-from-stable-to-stable
searched nightlies: from nightly-2022-05-01 to nightly-2022-07-01 regressed nightly: nightly-2022-05-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegresses in rollup , most likely , cc
claim

Discussion:
) .is_ok() { <del> // Suppress this error, since we already emitted // a deref suggestion in check_overloaded_binop err.downgrade_to_delayed_bug(); </del> <ins> // If LHS += RHS is an error, but *LHS += RHS is successful, then we will have // emitted a better suggestion during error handling in check_overloaded_binop. if self .lookup_op_method( lhs_ty, Some(rhs_ty), Some(rhs), Op::Binary(op, IsAssign::Yes), expected, ) .is_err() { err.downgrade_to_delayed_bug(); } else { // Otherwise, it's valid to suggest dereferencing the LHS here. err.span_suggestion_verbose( lhs.span.shrink_to_lo(), "consider dereferencing the left-hand side of this operation", "*", Applicability::MaybeIncorrect, ); } </ins> } } });

<ins> // issue #101376 use std::ops::AddAssign; struct Foo; impl AddAssign<()> for Foo { fn add_assign(&mut self, _: ()) {} } impl AddAssign<()> for &mut Foo { fn add_assign(&mut self, _: ()) {} } fn main() { (&mut Foo) += (); //~^ ERROR invalid left-hand side of assignment //~| NOTE cannot assign to this expression //~| HELP consider dereferencing the left-hand side of this operation } </ins>

<ins> error[E0067]: invalid left-hand side of assignment --> $DIR/assign-non-lval-needs-deref.rs:15:16 | LL |     (&mut Foo) += (); |     ---------- ^^ |     | |     cannot assign to this expression | help: consider dereferencing the left-hand side of this operation | LL |     *(&mut Foo) += (); |     + error: aborting due to previous error For more information about this error, try `rustc --explain E0067`. </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest replacing the with where appropriate as the suggestion for incorrect usage of in place of already exist. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Discussion:
parser_remove_let = expected pattern, found `let` .suggestion = remove the unnecessary `let` keyword <ins> parser_use_eq_instead = unexpected `==` .suggestion = try using `=` instead </ins>

pub span: Span, } <ins> #[derive(SessionDiagnostic)] #[diag(parser::use_eq_instead)] pub(crate) struct UseEqInstead { #[primary_span] #[suggestion_short(applicability = "machine-applicable", code = "=")] pub span: Span, } </ins> // SnapshotParser is used to create a snapshot of the parser // without causing duplicate errors being emitted when the `Parser` // is dropped.

} } <ins> if self.token.kind == TokenKind::EqEq && self.prev_token.is_ident() && expected.iter().any(|tok| matches!(tok, TokenType::Token(TokenKind::Eq))) { // Likely typo: `=` → `==` in let expr or enum item return Err(self.sess.create_err(UseEqInstead { span: self.token.span })); } </ins> let expect = tokens_to_string(&expected); let actual = super::token_descr(&self.token); let (msg_exp, (label_sp, label_exp)) = if expected.len() > 1 {

<ins> // run-rustfix #[allow(dead_code)] enum Demo { A = 1, B = 2 //~ ERROR unexpected `==` //~^ expected item, found `==` } fn main() {} </ins>

<ins> // run-rustfix #[allow(dead_code)] enum Demo { A = 1, B == 2 //~ ERROR unexpected `==` //~^ expected item, found `==` } fn main() {} </ins>

<ins> error: unexpected `==` --> $DIR/issue-101477-enum.rs:6:7 | LL |     B == 2 |       ^^ help: try using `=` instead error: expected item, found `==` --> $DIR/issue-101477-enum.rs:6:7 | LL |     B == 2 |       ^^ expected item error: aborting due to 2 previous errors </ins>

<ins> // run-rustfix fn main() { let x = 2; //~ ERROR unexpected `==` println!("x: {}", x) } </ins>

<ins> // run-rustfix fn main() { let x == 2; //~ ERROR unexpected `==` println!("x: {}", x) } </ins>

<ins> error: unexpected `==` --> $DIR/issue-101477-let.rs:4:11 | LL |     let x == 2; |           ^^ help: try using `=` instead error: aborting due to previous error </ins>
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: with rustc this runs in a couple ms: with rustc this seems to hang somewhere in ( I killed the process after waiting for 5 minutes :upsidedownface: )
reduced: RIP
I think this is caused by cc
Clearly a well tested feature :stuckouttongue: I'll take a look.
The old code looked like this: The new code looks like this: because is no longer optional. The infinite recursion happens because the call returns a that is the same as the . When I printed that ID out it looks like this: An easy fix is to check if is the same as and return if so. But I don't know if that's just papering over a deeper problem. Is it an underlying bug that can return the same node it is given?

Discussion:
fn insert(&mut self, span: Span, hir_id: HirId, node: Node<'hir>) { debug_assert_eq!(self.owner, hir_id.owner); debug_assert_ne!(hir_id.local_id.as_u32(), 0); <ins> debug_assert_ne!(hir_id.local_id, self.parent_node); </ins> // Make sure that the DepNode of some node coincides with the HirId // owner of that node.

return self.lower_path_ty(t, qself, path, ParamMode::Explicit, itctx); } TyKind::ImplicitSelf => { <del> let hir_id = self.lower_node_id(t.id); </del> <ins> let hir_id = self.next_id(); </ins> let res = self.expect_full_res(t.id); let res = self.lower_res(res); hir::TyKind::Path(hir::QPath::Resolved(

impl fmt::Debug for OwnerNodes<'_> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { f.debug_struct("OwnerNodes") <ins> // Do not print all the pointers to all the nodes, as it would be unreadable. </ins> .field("node", &self.nodes[ItemLocalId::from_u32(0)]) <ins> .field( "parents", &self .nodes .iter_enumerated() .map(|(id, parented_node)| (id, parented_node.as_ref().map(|node| node.parent))) .collect::<Vec<_>>(), ) </ins> .field("bodies", &self.bodies) .field("local_id_to_def_id", &self.local_id_to_def_id) .field("hash_without_bodies", &self.hash_without_bodies)

let owner = self.tcx.hir_owner_nodes(id.owner).as_owner()?; let node = owner.nodes[id.local_id].as_ref()?; let hir_id = HirId { owner: id.owner, local_id: node.parent }; <ins> // HIR indexing should have checked that. debug_assert_ne!(id.local_id, node.parent); </ins> Some(hir_id) } }
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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should include a note informing the user that the declaration of another struct within a struct is not allowed and they should use separate declarations. (Wording might need a bit of tweaking). <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label D-terse
claim

Discussion:
fn parse_field_ident(&mut self, adt_ty: &str, lo: Span) -> PResult<'a, Ident> { let (ident, is_raw) = self.ident_or_err()?; if !is_raw && ident.is_reserved() { <ins> let snapshot = self.create_snapshot_for_diagnostic(); </ins> let err = if self.check_fn_front_matter(false) { let inherited_vis = Visibility { span: rustc_span::DUMMY_SP,

err.help("unlike in C++, Java, and C#, functions are declared in `impl` blocks"); err.help("see https://doc.rust-lang.org/book/ch05-03-method-syntax.html for more information"); err <ins> } else if self.eat_keyword(kw::Struct) { match self.parse_item_struct() { Ok((ident, _)) => { let mut err = self.struct_span_err( lo.with_hi(ident.span.hi()), &format!("structs are not allowed in {adt_ty} definitions"), ); err.help("consider creating a new `struct` definition instead of nesting"); err } Err(err) => { err.cancel(); self.restore_snapshot(snapshot); self.expected_ident_found() } } </ins> } else { self.expected_ident_found() };

<ins> struct S1 { struct S2 { //~^ ERROR structs are not allowed in struct definitions } } fn main() {} </ins>

<ins> error: structs are not allowed in struct definitions --> $DIR/issue-101540.rs:2:5 | LL |     struct S2 { |     ^^^^^^^^^ | = help: consider creating a new `struct` definition instead of nesting error: aborting due to previous error </ins>