jiebi/CodeConvo huggingface dataset:
Change:
projection }; <del> // The only thing that should be left is a deref, if the parent captured // an upvar by-ref. std::assert_matches::assert_matches!(final_deref, [] | [mir::ProjectionElem::Deref]); // For all of the additional projections that come out of precise capturing, // re-apply these projections. let additional_projections = additional_projections.iter().map(|elem| match elem.kind { ProjectionKind::Deref => mir::ProjectionElem::Deref, ProjectionKind::Field(idx, VariantIdx::ZERO) => { mir::ProjectionElem::Field(idx, elem.ty) } _ => unreachable!("precise captures only through fields and derefs"), }); </del> <ins> // These projections are applied in order to "bridge" the local that we are // currently transforming *from* the old upvar that the by-ref coroutine used // to capture *to* the upvar of the parent coroutine-closure. For example, if // the parent captures `&s` but the child captures `&(s.field)`, then we will // apply a field projection. let bridging_projections = bridging_projections.iter().map(|elem| match elem.kind { ProjectionKind::Deref => mir::ProjectionElem::Deref, ProjectionKind::Field(idx, VariantIdx::ZERO) => { mir::ProjectionElem::Field(idx, elem.ty) } _ => unreachable!("precise captures only through fields and derefs"), }); </ins> // We start out with an adjusted field index (and ty), representing the // upvar that we get from our parent closure. We apply any of the additional

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Sorry you hit this ICE. This should be fixed by , which landed 15 minutes ago, though will probably not make it into nightly until two days from now (10 April 2024).
Actually, it's not yet fixed. I have a follow-up PR that will fix this :facepalm:
Change:
use rustc::hir::{self, CodegenFnAttrFlags}; use rustc::hir::itemlikevisit::ItemLikeVisitor; <del> use rustc::hir::Node; </del> use rustc::hir::def_id::DefId; use rustc::mir::interpret::{AllocId, ConstValue}; use rustc::middle::lang_items::{ExchangeMallocFnLangItem, StartFnLangItem};

Discussion:
Adding to 's definition works around the ICE. Also, the bug doesn't trigger if is an non- , so it's not just that is inlined cross-crate, but -specific behavior is also involved. cc
Still happens on the latest nightly. cc It doesn't block , but the workaround in that PR is a bit ugly.
I have a fix in
Change:
<ins> warning: the feature `specialization` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/freeze-on-polymorphic-projection.rs:4:12 | LL | #![feature(specialization)] |            ^^^^^^^^^^^^^^ | = note: see issue #31844 <https://github.com/rust-lang/rust/issues/31844> for more information = help: consider using `min_specialization` instead, which is more stable and complete = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- (requires release mode) <!-- 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. --: 1.70.0-nightly (2023-04-02 ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details labels modify +F-specialization +requires-nightly +requires-incomplete-features
I understand how this ICE can come about, but I frankly cannot reproduce this. can you help out?
Ah, I apparently forgot to list that the ICE requires ; building without optimizations doesn't ICE.
label +F-specialization +requires-nightly +requires-incomplete-features
Change:
/// Returns a new span representing the next character after the end-point of this span. /// Special cases: /// - if span is a dummy one, returns the same span <del> /// - if next_point reached the end of source, return span with lo = hi </del> <ins> /// - if next_point reached the end of source, return a span exceeding the end of source, ///   which means sm.span_to_snippet(next_point) will get `Err` </ins> /// - respect multi-byte characters pub fn next_point(&self, sp: Span) -> Span { if sp.is_dummy() {

Discussion:
This malformed code () hangs the compiler: Found by fuzzing with a . must be defined as a named-field struct (not a tuple struct or unit struct), although it can have 0 fields. must be the last token to produce the hang: No opening brace (note that braces are required for literals of named-field structs) No closing delimiters Not even a comment If I understand correctly, the hang occurs in LateResolutionVisitor, with never finishing (while calling various functions such as and ) This also hangs. I'm guessing it's the same bug. : with: <details</summary<p</p</detailsregressed nightly: nightly-2022-10-21 regressed commit: (PR ) label +regression-from-stable-to-nightly +I-hang <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
I can not reproduce it with latest code, did I missed anything?
Great cactch Confirmed the error is only triggered by commit: The root cause is I changed the edge corner case in : We think won't return a span which outside of source file, so is a valid one, then will always return a valid span, and we get from when reaching the end of source. So, there is a loop in previous , which will run infinitely loop: Lucky, my another PR merged at last day, this PR refactored this function:
Verif, I no longer get a hang after rollup Do you want to add one or two of these as tests?
Yes, we'd better add a testcase for it. I'm thinking whether we sould in when reaching to the end of source, so that may get an error.
This testcase seems not easy to be : If so, the trigger point will do not exist,
label -I-prioritize
There's an alternative kind of annotation for patterns that should work for this case:
Change:
<ins> error[E0404]: expected trait, found type parameter `Read` --> $DIR/issue-120559.rs:3:9 | LL | use std::io::Read; |              ---- you might have meant to refer to this trait LL | LL | fn f<T: Read, U, Read>() {} |         ^^^^     ---- found this type parameter |         | |         not a trait error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0404`. </ins>

Discussion:
(A better title would be appreciated) I like this part: It could have a suggestion like , especially because are very close to each other on a US keyboard and could very well be a typo. Applying the suggestion will result in a compile error. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the label might be fitting as well.
Error: Parsing assign command in failed: ...' claim' ' +D-invali'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Change:
<a href="https://doc.rust-lang.org/reference/type-layout.html">“Type Layout”</a>  chapter for details on type layout guarantees.</p></div>" ); <del> if ty_layout.layout.abi.is_unsized() { writeln!(w, "<p><strong>Size:</strong> (unsized)</p>"); } else { let bytes = ty_layout.layout.size.bytes(); writeln!( w, "<p><strong>Size:</strong> {size} byte{pl}</p>", size = bytes, pl = if bytes == 1 { "" } else { "s" }, ); </del> <ins> w.write_str("<p><strong>Size:</strong> "); write_size_of_layout(w, ty_layout.layout, 0); writeln!(w, "</p>"); if let Variants::Multiple { variants, tag, tag_encoding, .. } = &ty_layout.layout.variants { if !variants.is_empty() { w.write_str( "<p><strong>Size for each variant:</strong></p> <ul>", ); let adt = if let Adt(adt, _) = ty_layout.ty.kind() { adt } else { span_bug!(tcx.def_span(ty_def_id), "not an adt") }; let tag_size = if let TagEncoding::Niche { .. } = tag_encoding { 0 } else if let Primitive::Int(i, _) = tag.value { i.size().bytes() } else { span_bug!(tcx.def_span(ty_def_id), "tag is neither niche nor int") }; for (index, layout) in variants.iter_enumerated() { let ident = adt.variants[index].ident; write!(w, "<li><code>{name}</code>: ", name = ident); write_size_of_layout(w, layout, tag_size); writeln!(w, "</li>"); } w.write_str("</ul>"); } </ins> } } // This kind of layout error can occur with valid code, e.g. if you try to

Discussion:
introduced a basic section on layout information, with only one piece of information: the total size of the type. I think one useful but easy extension to this is reporting the size of each variant for an enum. cc The "Layout" section is rendered in The variable is a .In that case we have access to an . The part will give us the size of the variant To get the name of the variant, we'll need the stored in , which we can hopefully get from . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think we could just look up the to find the name (there's probably a function for that). Also, it might be worth showing the sizes of each union field.
claim
Change:
<del> //@ known-bug: #120600 #![feature(never_type, never_type_fallback)] enum E { Bar(!) } fn f(a: &E, b: &E) { match (a, b) { (E::Bar(a), E::Bar(b)) => { *a == *b; } _ => {} } } pub fn main() {} </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: broken MIR in DefId(0:20 ~ o[fbbd]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move 23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !): NoSolution', 'error: internal compiler error: broken MIR in DefId(0:20 ~ o[fbbd]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move 23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !): NoSolution' File: --snippet: 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: error: internal compiler error: broken MIR in DefId(0:20 ~ mvce[954a]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move _23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !

): NoSolution --
Regression in nightly-2023-05-23 commit[0] 2023-05-21: Auto merge of - MU001999:fix/issue-, r=cjgillot commit[1] 2023-05-21: Auto merge of - Zoxc:query-structs-trim, r=cjgillot commit[2] 2023-05-22: Auto merge of - lukas-code:strike, r=notriddle commit[3] 2023-05-22: Auto merge of - the8472:filter-map-chunk, r=thomcc commit[4] 2023-05-22: Auto merge of - matthiaskrgr:rollup-qd4b2vu, r=matthiaskrgr commit[5] 2023-05-22: Auto merge of - Jules-Bertholet:document-pin-layout, r=thomcc commit[6] 2023-05-22: Auto merge of - compiler-errors:triple-check, r=Nilstrieb commit[7] 2023-05-22: Auto merge of - marc0246:arc-new-uninit-bloat, r=thomcc commit[8] 2023-05-22: Auto merge of - lcnr:recursion-depth, r=matthewjasper commit[9] 2023-05-22: Auto merge of - Dylan-DPC:rollup-7jqydzg, r=Dylan-DPC ERROR: no CI builds available between and within last 167 days cc
Minimized:
Minimized even more: (I independently found the same bug while running crater with the fallback being )
Change:
[[package]] name = "git2" <del> version = "0.10.1" </del> <ins> version = "0.11.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "39f27186fbb5ec67ece9a56990292bc5aed3c3fc51b9b07b0b52446b1dfb4a82" </del> <ins> checksum = "77519ef7c5beee314d0804d4534f01e0f9e8d9acdee2b7a48627e590b27e0ec4" </ins> dependencies = [ "bitflags", "libc",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
// Ambiguity if upvars haven't been constrained yet && !args.tupled_upvars_ty().is_ty_var() { <del> let no_borrows = match args.tupled_upvars_ty().kind() { ty::Tuple(tys) => tys.is_empty(), ty::Error(_) => false, _ => bug!("tuple_fields called on non-tuple"), }; </del> // A coroutine-closure implements `FnOnce` *always*, since it may // always be called once. It additionally implements `Fn`/`FnMut` <del> // only if it has no upvars (therefore no borrows from the closure // that would need to be represented with a lifetime) and if the // closure kind permits it. // FIXME(async_closures): Actually, it could also implement `Fn`/`FnMut` // if it takes all of its upvars by copy, and none by ref. This would // require us to record a bit more information during upvar analysis. if no_borrows && closure_kind.extends(kind) { </del> <ins> // only if it has no upvars referencing the closure-env lifetime, // and if the closure kind permits it. if closure_kind.extends(kind) && !args.has_self_borrows() { </ins> candidates.vec.push(ClosureCandidate { is_const }); } else if kind == ty::ClosureKind::FnOnce { candidates.vec.push(ClosureCandidate { is_const });

Discussion:
I've returned to one of my projects after a few months of pause. Before I was using rust nigthly ~1.7x (around November 2023). It also worked through whole 2022 and 2021 IIRC. I've moved to new computer and installed rust nightly 1.80 (latest). After upgrading I noticed that my whole codebase is full of errors around capturing something from environment. . However if I change to it builds and works like previosly. Minimal example below. The error for first method is: i booted my very old PC to check, this is definately not the last version this worked fine: I definately does not work with:
Minimal: This should be possible now to support due to changes in . I'll put up a fix soon.
Change:
_ => None, } { debug!("id = {:?} span = {:?} name = {:?}", id, span, name); if name.name == kw::UnderscoreLifetime { continue; }

Discussion:
Async functions that take references seem to always trigger the lint (which is allow-by-default). Example: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I found which describes basically the same problem.
Seeing as this lint is not enabled by default, marking as deferred, though this would be good to fix and probably not too hard.
claim
Looks the same issue as . A little inelegant but if we can suppress the lint I think...
Change:
_ => None, } { debug!("id = {:?} span = {:?} name = {:?}", id, span, name); if name.name == kw::UnderscoreLifetime { continue; }

Discussion:
<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Duplicate of
Change:
} trait foo6 { //~ ERROR trait `foo6` should have an upper camel case name <ins> type foo7; //~ ERROR associated type `foo7` should have an upper camel case name </ins> fn dummy(&self) { } }

Discussion:
Associated types are types and thus should be capitalized. I think most code also does this. Recently I accidentally didn't capitalize it and was surprised that it doesn't lint for it: I'd expect it to say something. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
checking happens inside , add for , then inspect the kind of inside this checking.
I'd like to put my hand up for this if that's alright? It looks like a good one to get started on. claim
Change:
Some(&adt_def.variants[variant_index]) } _ => if let ty::TyAdt(adt, _) = self.ty.sty { <del> Some(adt.struct_variant()) </del> <ins> if adt.is_univariant() { Some(&adt.variants[0]) } else { None } </ins> } else { None }

Discussion:
The minimum code example: compiling:
Thats a regression from stable → beta/nightly.
Introduced by .
Change:
fn run(self, builder: &Builder<'_>) -> Interned<PathBuf> { let compiler = self.compiler; let host_dir = builder.out.join(&compiler.host.triple); <del> let sysroot = if compiler.stage == 0 { host_dir.join("stage0-sysroot") } else if builder.download_rustc() { host_dir.join("ci-rustc-sysroot") } else { host_dir.join(format!("stage{}", compiler.stage)) </del> <ins> let sysroot_dir = |stage| { if stage == 0 { host_dir.join("stage0-sysroot") } else if builder.download_rustc() && compiler.stage != builder.top_stage { host_dir.join("ci-rustc-sysroot") } else { host_dir.join(format!("stage{}", stage)) } </ins> }; <ins> let sysroot = sysroot_dir(compiler.stage); </ins> let _ = fs::remove_dir_all(&sysroot); t!(fs::create_dir_all(&sysroot));

Discussion:
with in no longer places & into but just into . Tested on Linux. . label T-infra A-bootstrap A-contributor-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm not convinced the binaries in are actually the newly compiled binaries; I think they may just never be copied from into a sysroot.
I am not familiar enough with the bootstrap process to be able to confirm or dispute this. As far as I'm concerned, I've relinked my toolchain to and everything appears to work flawlessly.
can you post the output of and ?
yeah that looks like it's not actually reflecting your changes, just using the latest nightly unmodified If it were working properly it would say -dev
Hmm, that can't be. I am currently working on fixing and modifications to the rustdoc source code are indeed properly reflected in the compiled binaries. Maybe the version string is just wrong but my local changes are picked up.
Actually, I have a counterquestion. Can you by chance reproduce this? Or is it just me and I'm just wondering why more people haven't stumbled upon this issue.
claim
cc
Change:
/// This is only available on unix and WASI platforms and must be imported in /// order to call the method. Windows platforms have a corresponding /// `AsRawHandle` and `AsRawSocket` set of traits. <ins> #[cfg_attr(not(bootstrap), rustc_allowed_through_unstable_modules)] </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait AsRawFd { /// Extracts the raw file descriptor.

Discussion:
Steps to reproduce: It's possible that this was accidentally stabilized, then feature gated later.
This seems to be caused by . I was thinking might address this, but I tried that PR and it doesn't seem to work. Maybe can confirm. cc
Looks like another case of , is stable but the module it lives in is not: Just need to add and it should work.
I'll work on this.
Using your suggested fix, I have a simple PR to address this, if you'd like to review: . I've confirmed locally that a toolchain built with this patch fixes the regression.
Change:
// Empty } <ins> unsafe impl Sync for .. { } </ins> impl<T> !Sync for *const T { } impl<T> !Sync for *mut T { } impl !Sync for Managed { }

Discussion:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.
Change:
<ins> //@ run-pass //@ ignore-sgx not supported //@ ignore-emscripten // FIXME: test hangs on emscripten #![allow(deprecated)] #![allow(unused_imports)] use std::thread; fn main() { thread::sleep_ms(250); } </ins>

Discussion:
Perhaps I'm holding it wrong? About a fifth of the rustc UI test suite to fail on wasm32-unknown-emscripten when trying to run . In all cases we get an error like this:
Does this target use some different main symbol name?
... do we need to pass --no-entry to lib builds? can you check if (some of) the failing tests are lib crates? Actually what am I doing, I can check
I can't get past the building test helpers for this target cross-compiling from msvc host, not sure what's up with that.
Huh. cc Can you make it any further?
Because there's an open PR for this.
In the open platform support docs PR this says It's recommended to test the  target instead for WebAssembly compatibility. ... so I don't know, is this expected failure?
See I was able to get past the build helpers stage by properly acquring the toolchain and making relevant env vars available to bootstrap. Didn't bother trying to diagnose past stage 1 std and tests because there's like a chain of failures. Notably I see
The failing link command includes: if we replace that with , then it links as expected. But then it fails to run it at: We should invoke with node.
So I guess for starters we should do:
Combined with setting the runner to this fixes most of the failing tests:
The failures seem to be: and seems like it hangs? sounds like an xfail.
Change:
<ins> error: changes to closure capture in Rust 2021 will affect drop order --> $DIR/macro.rs:10:13 | LL |     let _ = || dbg!(a.0); |             ^^^^^^^^---^ |                     | |                     in Rust 2018, closure captures all of `a`, but in Rust 2021, it only captures `a.0` ... LL | } | - in Rust 2018, `a` would be dropped here, but in Rust 2021, only `a.0` would be dropped here alongside the closure | note: the lint level is defined here --> $DIR/macro.rs:5:9 | LL | #![deny(rust_2021_incompatible_closure_captures)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/disjoint-capture-in-closures.html> help: add a dummy let to cause `a` to be fully captured | LL |     let _ = || { let _ = &a; dbg!(a.0) }; |                ~~~~~~~~~~~~~~~~~~~~~~~~~ error: aborting due to previous error </ins>

Discussion:
produces: It expanded the macro. This only happens when the macro invocation is the entire body of the closure.
cc
Working on a fix.