jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0571]: `break` with value from a `while` loop --> $DIR/issue-114529-illegal-break-with-value.rs:9:13 | LL |         while true { |         ---------- you can't `break` with a value in a `while` loop LL |             break 9; |             ^^^^^^^ can only break with a value inside `loop` or breakable block | help: use `break` on its own without a value inside this `while` loop | LL |             break; |             ~~~~~ error[E0571]: `break` with value from a `while` loop --> $DIR/issue-114529-illegal-break-with-value.rs:16:13 | LL |         while let Some(v) = Some(9) { |         --------------------------- you can't `break` with a value in a `while` loop LL |             break v; |             ^^^^^^^ can only break with a value inside `loop` or breakable block | help: use `break` on its own without a value inside this `while` loop | LL |             break; |             ~~~~~ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0571`. </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. --<!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can't reproduce this on the latest nightly. Can you confirm that this doesn't reproduce anymore?
This may only be triggerable with a rustc that was built with debug assertions on
Yes, hence the label :sweat_smile:
No longer needs debug assertions to crash :tada:
`
Edit: Ignore it. Wrong bisection. For some reason it was bisecting to 2023-10-04 on my machine despite the fact that the issue was reported much earlier than this date.
The issue occurs because the interpreter tries to assign the value from to a temporary MIR local of type which produces a type mismatch and results in the ICE. Such faulty MIR should not have been generated. However, the while loop, although detected as malformed during AST lowering, successfully typecks. Had it not and had been set to , the MIR would not have been generated. Therefore as far as I understand the solution is to fail typeck and set to for code like this. claim
Change:
id = short, name = name)); } <del> struct Initializer<'a>(&'a str, Item<'a>); impl<'a> fmt::Show for Initializer<'a> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { let Initializer(s, item) = *self; if s.len() == 0 { return Ok(()); } try!(write!(f, "<code> = </code>")); if s.contains("n") { match item.href() { Some(url) => { write!(f, "<a href='{}'>[definition]</a>", url) } None => Ok(()), } } else { write!(f, "<code>{}</code>", s.as_slice()) } } } </del> match myitem.inner { <del> clean::StaticItem(ref s) | clean::ForeignStaticItem(ref s) => { try!(write!(w, " <tr> <td>{}<code>{}static {}{}: {}</code>{}</td> <td class='docblock'>{}&nbsp;</td> </tr> ", ConciseStability(&myitem.stability), VisSpace(myitem.visibility), MutableSpace(s.mutability), *myitem.name.as_ref().unwrap(), s.type_, Initializer(s.expr.as_slice(), Item { cx: cx, item: myitem }), Markdown(blank(myitem.doc_value())))); } clean::ConstantItem(ref s) => { try!(write!(w, " <tr> <td>{}<code>{}const {}: {}</code>{}</td> <td class='docblock'>{}&nbsp;</td> </tr> ", ConciseStability(&myitem.stability), VisSpace(myitem.visibility), *myitem.name.as_ref().unwrap(), s.type_, Initializer(s.expr.as_slice(), Item { cx: cx, item: myitem }), Markdown(blank(myitem.doc_value())))); } </del> clean::ViewItemItem(ref item) => { match item.inner { clean::ExternCrate(ref name, ref src, _) => {

Discussion:
Here's what I think is wrong: keywords , and appear next to the name of the constant, when clearly they are redundant. the constants page through search brings the user to an empty page. value assigned to the constant appears along side its name. When reading the documentation of constants, the most important information is the name of the constant and its description. Having the declaration appear inline makes scanning for the name of harder. Better output would replace the declaration with the name of the constant followed by its type. Also it would move the declaration of the constant to the empty page mentioned in point 2 and have the identifier of the constant link to this page. All these points are relevant for statics as well. Example of ugly output: ! This page should show the definition and a description of the constant: !
Change:
module.directory.pop(); self.cx.current_expansion.module = Rc::new(module); <ins> let orig_mod_span = krate.module.inner; </ins> let krate_item = Expansion::Items(SmallVector::one(P(ast::Item { attrs: krate.attrs, span: krate.span,

Discussion:
An ICE occurs when invoking a procedural macro attribute on the root of a crate with . Relevant backtrace frames: This happens on the latest nightly . cc
If you haven't started on this one I'll go ahead and take a crack at it since people are stumbling on it.
That second unwrap is which is infallible. That's kind of misleading, but okay.
Change:
def_id.to_def_id(), ); if let Some(assoc_item) = assoc_item { <del> tcx.type_of(assoc_item.def_id).subst_identity() </del> <ins> tcx.type_of(assoc_item.def_id) .no_bound_vars() .expect("const parameter types cannot be generic") </ins> } else { // FIXME(associated_const_equality): add a useful error message here. tcx.ty_error_with_message(

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
searched nightlies: from nightly-2022-12-30 to nightly-2023-03-18 regressed nightly: nightly-2023-01-01 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegression in
aaah shit, the commit only modified the backtrace :laughing: so "panicked at" no longer triggers before that..
`
maybe
Change:
//! Type-relative name resolution (methods, fields, associated items) happens in `rustc_hir_analysis`. #![doc(html_root_url = "https://doc.rust-lang.org/nightly/nightly-rustc/")] <ins> #![feature(assert_matches)] </ins> #![feature(box_patterns)] #![feature(drain_filter)] #![feature(if_let_guard)]

Discussion:
Instead, this happened: Successful compilation Tested on the playground, all versions and editions. Stable channel: 1.64.0 Beta channel: 1.65.0-beta.3 (2022-10-10 ) Nightly channel: 1.66.0-nightly (2022-10-19 ) I'm labeling this as a regression as I believe it is severe enough of an unplanned change (at best an accidental stabilization?) that I should draw attention to it, even though I haven't found a way to cause miscompilation for example. I also have not tried to do so at all yet. label +T-compiler +A-lifetimes +regression-from-stable-to-stable <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-01-01 to nightly-2022-10-01 regressed nightly: nightly-2022-07-26 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
claim
Actually, this behavior is correct as : There is exactly one lifetime used in the parameters (), so assigning it to the output lifetime is as expected. release-assignment
That verbiage but it compiles on no stable version of rustc prior to 1.64, so I don't think it's actually relevant. (The reference is also explicitly non-normative.) mirrors in specifying input positions, not counts. Regardless of documentation, as something that has not compiled on Rust 1.0--1.63 but compiles today, this is clearly a change in language behavior without FCP which I believe to be unintentional. label +T-lang
Ok, so we will consider this for now a regression that should be backported to stable (we're ~2 weeks away from the new release). WG-prioritization assigning priority (). label -I-prioritize +P-critical
Filed
Nominating for lang team to figure out what we should do with this. Will also ping on zulip.

Discussed in lang, dropping nomination. Agreement that we want to revert the change in behavior and backport that to 1.65 (and 1.64, but that's not happening given short time window). Considering whether we want to make the behavior change can happen in a follow-up proposal.
Change:
<ins> error[E0599]: no method named `foo` found for type `()` in the current scope --> $DIR/issue-33575.rs:2:18 | LL |     let baz = ().foo(); |                  ^^^ method not found in `()` error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>

Discussion:
Because of the method error, doesn't get a type (not even , AFAICT), and then it gets inferred to from another call in the function, which results in the unsized variable error.
cc
I'd expect a simple fix for this would be to actually set as 's type, so it can't be inferred to anything else, although that could make other errors less informative.
I just spent a lot of time looking at a error. The errors were hidden by a couple of screens of "doc comment not used by rustdoc" warnings. Because was unknown, the compiler assumed it implemented no traits at all, leading to misleading errors below and user confusion: "why isn't it when this other similar type similar is?", "how can I find out if a type is " and so on. I don't know if works like that, but in this case it might be better to assume that the type implements any trait it's required to.
That doesn't really work out, since the issue here is that inference gets a free pass instead of inferring which would at least signal anything. The fix seems simple, I really don't know why I haven't tried it yet
I'm not saying that the type should be inferred to something else from the code below (like you said it was happening in the issue description) -- that seems bad. But on the other hand the compiler should probably not report an error every place the type or variable is used.
I just reread, and: That's not relevant here - the problem is inference flows up into the variable, which is correct in other cases but in this case it infers the slice type which is unsized. The error is a mere side-effect.
The underlying cause is that we have two maps for →, a general one and one for locals. When type checking we write to the general one but the one for locals is only written to once, during initialization, and the we read from it. If we kept it up to date or read from the general map, the knock-down error wouldn't appear.
Change:
<ins> struct Checked<const F: fn(usize) -> bool>; //~^ ERROR function pointers as const generic parameters is forbidden fn not_one(val: usize) -> bool { val != 1 } const _: Checked<not_one> = Checked::<not_one>; fn main() {} </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. --<!-- 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 same problem is reproduced by rustc 1.76.0-nightly ( 2023-11-24). <!-- 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 --
Oo this looks like but it's much smaller and doesn't need any features.
searched nightlies: from nightly-2023-01-01 to nightly-2023-11-20 regressed nightly: nightly-2023-09-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
So that would be then. The panic originates .
After that error, something is still trying to create a valtree from a function pointer, it seems. I'd say that's a bug, my PR just turns it into an ICE -- but silencing the ICE does not fix the bug. Certain errors need to stop rustc from doing any further work with the faulty code. Cc
Can we turn it into a Constkind::Error instead of ICEing?
I mean we could I guess, though it seems suspicious to me that we even call this function after the type checker already determined that this is not valid as a const generic.
We check the type of const parameters separately from when we compute them. Not doing so results in query cycles iirc :thinking: so it's probably best to somewhere here instead of ICEing
Change:
let mut visitor = HirPlaceholderCollector::default(); visitor.visit_ty(ty); let mut diag = bad_placeholder(tcx, visitor.0, "return type"); let ret_ty = fn_sig.output(); <ins> // Don't leak types into signatures unless they're nameable! // For example, if a function returns itself, we don't want that // recursive function definition to leak out into the fn sig. let mut should_recover = false; </ins> if let Some(ret_ty) = ret_ty.make_suggestable(tcx, false) { diag.span_suggestion( ty.span,

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
That second function can be named anything, for the record. e.g.
Change:
<ins> error[E0277]: the trait bound `String: Copy` is not satisfied --> $DIR/synthetic-hir-has-parent.rs:7:9 | LL |         String: Copy; |         ^^^^^^^^^^^^ the trait `Copy` is not implemented for `String` | = help: see issue #48214 help: add `#![feature(trivial_bounds)]` to the crate attributes to enable | LL + #![feature(trivial_bounds)] | error[E0277]: the trait bound `String: Copy` is not satisfied --> $DIR/synthetic-hir-has-parent.rs:4:18 | LL |     fn demo() -> impl Foo |                  ^^^^^^^^ the trait `Copy` is not implemented for `String` | = help: see issue #48214 help: add `#![feature(trivial_bounds)]` to the crate attributes to enable | LL + #![feature(trivial_bounds)] | error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </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. --(reduced) (original) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongCode</strong</summary<p</p</details<!-- 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- The in closed issue is same as the .
Regression in The PR introducing the regression in this rollup is : Provide structured suggestion for searched nightlies: from nightly-2024-03-16 to nightly-2024-03-23 regressed nightly: nightly-2024-03-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
This was caused by the introduction of which has no parent. This seems like a gun aimed squarely at the foot of any user of or . I believe we need to audit all existing uses of these (if you haven't done that already).
Change:
let mut arg = OsString::from("--version-script="); arg.push(path); self.linker_arg(arg); <ins> self.linker_arg("--no-undefined-version"); </ins> } } }

Discussion:
Building Rust toolchain using latest leads to an error when compiling libtest at stage0: Error is coming from (Enable --no-undefined-version by default.), with the description indicating that our version scripts were not correct. Local workaround is to pass in Rustflags. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I ran into this too. I wonder why rustc is attempting to export those symbols from , but not ? I'm seeing that e.g. works but does not. I can't determine what's different between and that would cause only the latter to output an invalid version script.
This actually repros outside of . If you attempt to compile any crate as a dylib, and is available as a dylib and linked as such (e.g. with the ) flag, you can reproduce the error by simply passing . This was with stable rustc and my system . Hopefully reproducing it outside of Rust's bootstrap will make it easier to debug.
related discussion: https://rust-
I suspect I found the issue: First, early in compilation rustc determines if a crate needs an allocator (whether or not it comes from the crate itself, or a dep). This is filled in a crate metadata struct field: If , the field says whether the crate graph contains a or not, but that's not directly relevant to the bug. This field will usually be ; it's if and are not used. Later, rustc checks whether to codegen the et al functions: Notably, if any dependency is linked as a , it will not generate them and instead link to the implementations exported from another . Independently, rustc determines which symbols to export when generating a and provides this list to the linker. Part of this is deciding whether to export the allocator symbols: Notably it does not perform the check from the last step. Even if a dependency is linked whose allocator symbols this crate should use, the export list still contains these symbol names. So when building a that links another , rustc tells the linker to export symbols that weren't actually defined. The build failure is just one instance of this bug. who helped in the Zulip discussion. Can you confirm this explanation makes sense?
Most of it.

There is a further complication that you can specify multiple crate types for a single compilation. It is then possible for some crate types to generate the allocator shim while others don't generate it. The list of exported symbols however is for all crate types at the same time. One way to fix this would be to have a separate list of exported symbols for each crate type. Another option would be to move the addition of the symbols to the actual code that invokes the linker.
Listing exported symbols per crate type seems like the most correct fix in principle, but the lists will be almost the same except for the allocator symbols. I'll try to find a clean way to do the latter.
claim
Change:
<ins> error[E0373]: closure may outlive the current function, but it borrows `x`, which is owned by the current function --> $DIR/async-borrowck-escaping-block-error.rs:6:20 | LL |     Box::new(async { x } ) |                    ^^-^^ |                    | | |                    | `x` is borrowed here |                    may outlive borrowed value `x` | note: generator is returned here --> $DIR/async-borrowck-escaping-block-error.rs:4:13 | LL | fn foo() -> Box<impl std::future::Future<Output = u32>> { |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to force the closure to take ownership of `x` (and any other referenced variables), use the `move` keyword | LL |     Box::new(async move { x } ) |                    ^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0373`. </ins>

Discussion:
emits the following error The correct code needs the to be part of the block because it is a stack allocation that needs to be in the generator: Ideally, the error message would mention : thanks to for bringing this up! CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We could also consider suggesting an block, similar to the hints we provide for closures.
Marking this as a focus item. assign
Change:
<ins> //@ check-pass mod ffi { use super::*; extern "C" { pub fn DomPromise_AddRef(promise: *const Promise); pub fn DomPromise_Release(promise: *const Promise); } } #[repr(C)] #[allow(unused)] pub struct Promise { private: [u8; 0], __nosync: ::std::marker::PhantomData<::std::rc::Rc<u8>>, } pub unsafe trait RefCounted { unsafe fn addref(&self); unsafe fn release(&self); } unsafe impl RefCounted for Promise { unsafe fn addref(&self) { ffi::DomPromise_AddRef(self) } unsafe fn release(&self) { ffi::DomPromise_Release(self) } } fn main() {} </ins>

Discussion:
<!-- 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. --nothing The original code didn't have the , which was because of the "never constructed" deadcode lint, which I guess would be . Adding a constructor does make the function never used errors go away, so it seems doesn't have enough power. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
WG-prioritization assigning priority (). label -I-prioritize +P-medium
bisected to </detailscc
like
is about the struct itself, and there's a allow(unused). This is about the side effects.
Oh, I see. claim
Change:
#[stable(feature = "rust1", since = "1.0.0")] impl ExitStatusExt for process::ExitStatus { <ins> fn from_raw(raw: i32) -> Self { process::ExitStatus::from_inner(From::from(raw)) } </ins> fn signal(&self) -> Option<i32> { self.as_inner().signal() }

Discussion:
Because has a private field it is impossible to create one in user code, one must actually execute a process. This prevents testing/mocking. My use case is that I have some function which runs a process and generates data, however, for testing I want to mock the test run and just return a success exit status and some data. I can't do that because I can't create my own objects. At the least there should be a way to create a success . Preferably, there would be a way to create various fail statuses too.
Should the constructor just take an ?
I've also wanted a basically "raw constructor" in the past. I'd be fine adding some extensions which allow construction from a or ( and )
+1 I’d like to extend , but I cannot reuse for return value because I can’t construct . :(
I've opened a PR for this over at
Great, thanks! :+1:
This would help n00bs like me who start out by copying the example code and tweaking it: This example is a special case that only happens to work if the contains a or something else that immediately exits. Otherwise you need to create your own struct to return which is currently impossible.
This issue is now entering a cycle-long final comment period for stabilization
Discussed recently, the libs team decided to stabilize.