jiebi/CodeConvo huggingface dataset:
Change:
| = note: required for `Option<Bar>` to implement `Copy` = note: the `Copy` trait is required because this value will be copied for each element of the array <ins> = help: consider using `core::array::from_fn` to initialize the array = help: see https://doc.rust-lang.org/stable/std/array/fn.from_fn.html# for more information </ins> help: consider annotating `Bar` with `#[derive(Copy)]` | LL + #[derive(Copy)]

Discussion:
For this snippet (): rustc gives: Since , for const-able values, rustc suggests the creation of a constant binding. Here this is not possible because is not const fn. However, we can suggest instead.
Personally, I prefer over a separate binding. Even in the case, the generated code will call the initialization function many times. Maybe in the case where bindings are possible, we can suggest both? Where they are not possible, we don't suggest anything right now, so at the least we should suggest there. what do you think?
Once is stable we can suggest that :3. But until then sounds reasonable.
Agreed, good point about . It seems to have a stabilization PR open with an FCP, which is blocked: . Maybe there might be progress on it this month: . Even if we stabilize inline const, it might make sense to wait with suggesting it for a while so that we don't make code depend on the latest MSRV immediately. So therefore, I think that it might still make sense to implement this in the meantime.
I think this should (in the future) suggest  instead, since the function would only be called once if were , whereas calls it for every element.
Change:
// since we initialize with an empty sysroot. // // Currently only the "libtest" tree of crates does this. <ins> let mut cargo = builder.cargo( compiler, Mode::Std, SourceType::InTree, target, cargo_subcommand(builder.kind), ); cargo.arg("--all-targets"); std_cargo(builder, target, compiler.stage, &mut cargo); </ins> <del> if let Subcommand::Check { all_targets: true, .. } = builder.config.cmd { let mut cargo = builder.cargo( compiler, Mode::Std, SourceType::InTree, target, cargo_subcommand(builder.kind), ); std_cargo(builder, target, compiler.stage, &mut cargo); cargo.arg("--all-targets"); // Explicitly pass -p for all dependencies krates -- this will force cargo // to also check the tests/benches/examples for these crates, rather // than just the leaf crate. for krate in builder.in_tree_crates("test", Some(target)) { cargo.arg("-p").arg(krate.name); } builder.info(&format!( "Checking stage{} std test/bench/example targets ({} -> {})", builder.top_stage, &compiler.host, target )); run_cargo( builder, cargo, args(builder), &libstd_test_stamp(builder, compiler, target), vec![], true, ); </del> <ins> // Explicitly pass -p for all dependencies krates -- this will force cargo // to also check the tests/benches/examples for these crates, rather // than just the leaf crate. for krate in builder.in_tree_crates("test", Some(target)) { cargo.arg("-p").arg(krate.name); </ins> } <ins> builder.info(&format!( "Checking stage{} std test/bench/example targets ({} -> {})", builder.top_stage, &compiler.host, target )); run_cargo( builder, cargo, args(builder), &libstd_test_stamp(builder, compiler, target), vec![], true, ); </ins> } }

Discussion:
It's possible to have errors in files such as: and , and have pass. I would expect to be equivalent of and check every file that CI checks. Otherwise, I run , push code to a PR, and only find later that I have a typo or such.
We don't check tests by default, but you can pass --all-targets () to check tests. I believe this is consistent with cargo check behavior? One reason we don't check tests by default is that causes duplicate error messages for the 'base' crate typically which are annoying (and most changes don't actually need them). If Cargo handled that and didn't show duplicate messages, I imagine we could change the default as well.
Oh, you're right. So my mistake was assuming that is more thorough than it is (my text editor invokes it for me, even for tests, so I didn't realize the command doesn't do everything itself).
Just FYI, 1.55 now deduplicates messages.
Oh, great news -- in that case I'm going to go ahead and reopen this as it seems likely to make sense to check tests (by default, and likely without an option to disable that). Should be a pretty simple adjustment to bootstrap.
Change:
| LL |         false => async_dummy().await, |                               ^^^^^^ <del> help: consider removing this semicolon and boxing the expressions | LL |             Box::new(async_dummy()) LL | LL |         } LL |         false => Box::new(async_dummy()), </del> <ins> help: consider removing this semicolon </ins> | <ins> LL |             async_dummy() |                         -- </ins> error[E0308]: `match` arms have incompatible types --> $DIR/match-prev-arm-needing-semi.rs:39:18

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. --The code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- 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 --
This looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim
Change:
<ins> #![allow(unused_variables)] use std::fs::File; fn main() { if Err(err) = File::open("hello.txt") { //~^ ERROR: cannot find value `err` in this scope //~| ERROR: mismatched types } } </ins>

Discussion:
Given the following code: The current output is: Ideally the output should look like: How do we remove other diagnostics in this scenario?
label +D-verbose
Change:
use syntax::edition::Edition; use syntax::feature_gate::UnstableFeatures; use syntax::with_globals; <del> use syntax_pos::{BytePos, DUMMY_SP, Pos, Span, FileName, hygiene}; </del> <ins> use syntax_pos::{BytePos, DUMMY_SP, Pos, Span, FileName}; </ins> use errors; use errors::emitter::ColorConfig;

Discussion:
Rustdoc seems to fail on async syntax in some situations. With in , the following is a sample of some apparent issues. This should build fine, but fails when running rustdoc: Tested with a few different nightlies (rustc 1.30.0-nightly ( 2018-08-05)) and latest master ().
This is a bug between rustdoc and , where the only place that is handed to libsyntax is this specific all-in-one entry point to the compiler: However, since rustdoc manages the phases of compilation itself, this line is never hit, and thus the global state telling libsyntax what edition to use is not set. We use this call manually for building doctests (see ), but not anywhere else. I propose moving the call from to , right before it sets up the parse session. That way, rustdoc can continue to set the edition in the session options, and other consumers of aren't caught by this gotcha.
Change:
use crate::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKind}; use crate::infer::{InferCtxt, InferOk, LateBoundRegionConversionTime}; use crate::traits::error_reporting::InferCtxtExt as _; <ins> use crate::traits::query::evaluate_obligation::InferCtxtExt as _; </ins> use crate::traits::select::ProjectionMatchesProjection; use rustc_data_structures::sso::SsoHashSet; use rustc_data_structures::stack::ensure_sufficient_stack;

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. --I recently updated my nightly toolchain and our project (still not open-sourced) ICE'd. I managed to reduce the problem to a minimal working example: <!-- 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</detailsI ran a quick : searched nightlies: from nightly-2022-03-01 to nightly-2022-03-24 regressed nightly: nightly-2022-03-16 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsThe offending line is the , so we should probably tag this with the appropriate feature tag. (Sorry if I messed anything up, I'm completely new to Rust ICE bug reports!) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
probably due to my PR claim
I get the same error on code that I got minimized to:
Same error with this example:
Same error I got with this example Defining it in a trait is fine though But adding a function body results in a crash
Change:
] [[package]] <ins> name = "dirs-sys" version = "0.3.3" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "cfg-if 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)", "libc 0.2.54 (registry+https://github.com/rust-lang/crates.io-index)", "redox_users 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)", "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] </ins> name = "dlmalloc" version = "0.1.3" source = "registry+https://github.com/rust-lang/crates.io-index"

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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 prioritization.
Miri is fixed upstream, but will be broken again by so I'd like to land that before updating.
Change:
self.set_tainted_by_errors(err.emit()); } <ins> /// On ambiguous associated type, look for an associated function whose name matches the /// extended path and, if found, emit an E0223 error with a structured suggestion. /// e.g. for `String::from::utf8`, suggest `String::from_utf8` (#109195) pub(crate) fn maybe_report_similar_assoc_fn( &self, span: Span, qself_ty: Ty<'tcx>, qself: &hir::Ty<'_>, ) -> Result<(), ErrorGuaranteed> { let tcx = self.tcx(); if let Some((_, node)) = tcx.hir().parent_iter(qself.hir_id).skip(1).next() && let hir::Node::Expr(hir::Expr { kind: hir::ExprKind::Path(hir::QPath::TypeRelative( hir::Ty { kind: hir::TyKind::Path(hir::QPath::TypeRelative( _, hir::PathSegment { ident: ident2, .. }, )), .. }, hir::PathSegment { ident: ident3, .. }, )), .. }) = node && let Some(ty_def_id) = qself_ty.ty_def_id() && let Ok([inherent_impl]) = tcx.inherent_impls(ty_def_id) && let name = format!("{ident2}_{ident3}") && let Some(ty::AssocItem { kind: ty::AssocKind::Fn, .. }) = tcx .associated_items(inherent_impl) .filter_by_name_unhygienic(Symbol::intern(&name)) .next() { let reported = struct_span_code_err!(tcx.dcx(), span, E0223, "ambiguous associated type") .with_span_suggestion_verbose( ident2.span.to(ident3.span), format!("there is an associated function with a similar name: `{name}`"), name, Applicability::MaybeIncorrect, ) .emit(); self.set_tainted_by_errors(reported); Err(reported) } else { Ok(()) } } </ins> } /// Emits an error regarding forbidden type binding associations

Discussion:
` " ); } This had me VERY confused as I was certain I would try to get a String here, where does Example come from?? And associated types wut?? The problem is I used which should have been :D Maybe rustc could improve its suggestion somehow in that case? No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
For reference, here is a MRE:
claim
Change:
error: an inner attribute is not permitted following an outer attribute <del> --> $DIR/inner-attr.rs:3:3 </del> <ins> --> $DIR/inner-attr.rs:3:1 </ins> | <ins> LL | #[feature(lang_items)] | ---------------------- previous outer attribute LL | </ins> LL | #![recursion_limit="100"] <del> |   ^ </del> <ins> | ^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute </ins> | = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.

Discussion:
Given the following we currently emit We should emit at least the following We might also want to provide suggestions when it makes sense (like turning the attr into an outer attr).
Hey , I tried to solve this with a little help of on a rust meetup. I wasn't able to run because of the following message. But I started to add some code you can read here: is this going into the right direction?
thank you for taking a look at this! You should be able to run the tests with . Use to update the relevant files. The code you've written would generate the following output: Instead, we'd want this to be a single error. What you'd want to do is 1) get the span for the prior attribute from 2) expand to also hold an extra field and 3) change the following to be This lets you point at the prior span in the same error. The second part of this ticket is changing the linked code to no longer use , but rather synthesize a new span from the first 's span to the closing . You can use to do so. Finally, we change the above to be something like
Are you still working on this? I'm thinking of giving it a try.
Go on! I don’t have so much time atm so just go there step by step while learning rust. If you want so solve it - awesome
Change:
#![feature(min_const_fn)] #![feature(const_int_ops)] #![feature(const_ip)] <ins> #![feature(const_raw_ptr_deref)] #![feature(const_cstr_unchecked)] </ins> #![feature(core_intrinsics)] #![feature(dropck_eyepatch)] #![feature(exact_size_is_empty)]

Discussion:
The current implementation of is not valid in a const context, but it can easily be tweaked so that it is:
At this point you can just enable the feature gate and use . There's no need for unions anymore
I thought was explicitly not going to become as per the discussion in .
Alternatively, why can't we make DST constructors work for simple wrappers like this? Why can't it be, e.g. &CStr{ bytes: *bytes } Where it looks kind of like the opposite of a deref coercion, and the compiler just reinterprets the fat pointer? This would eliminate the need for any besides what's necessary for the API contract.
Yes I would like such constructors, too. But that needs and RFC and probably has a lot of caveats that we want to think about. I did not know about that issue. I commented there.
Change:
| LL |     if let Some(n) = opt else { |                         ^ <ins> help: remove the `if` if you meant to write a `let...else` statement --> $DIR/ensure-that-let-else-does-not-interact-with-let-chains.rs:24:5 | LL |     if let Some(n) = opt else { |     ^^ </ins> error: this `if` expression is missing a block after the condition --> $DIR/ensure-that-let-else-does-not-interact-with-let-chains.rs:28:5

Discussion:
<!-- 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 removing the additional keyword in front of the . This mistake can occur due to muscle memory as , , and in the future are somewhat similar syntactically. Thanks. label +D-confusing +F-let-else <!-- 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 --
I think the current suggestion is valid. Because one writes instead of writing . So the suggestion if changed maybe fall-negative.
We should likely add an alternative suggestion to remove the , but keep both. I think that the current suggestion is likely going to be the more common situation, so it should still come first.
claim
What would be the best way to go about adding an alternate suggestion? I'd like to try my hand at this. What I think needs to be done is adding help text to , add a variant to , and then add something to to add the alternate after the primary suggestion. Is this a good starting point?
it sounds like you are in the right path.
I looked a bit into this issue and have already found where to add text to the and the as mentioned, but i am a bit overwhelmed how and where to start in the in the . Does anyone have a hint for me?
claim
claim
You can add instructions in the parser to track your progress.

I'm not sure about the specifics out of the top of my head here of what type each step in the parse is, but you will have successfully parsed the , the condition and then you'll encounter an token when a body/block was expected. That's where the new recovery should kick in, pointing at the span saying that you might want to remove it.
claim
Change:
} /// The yield kind that caused an `ExprKind::Yield`. <del> #[derive(Copy, Clone, Debug, RustcEncodable, RustcDecodable, HashStable)] </del> <ins> #[derive(Copy, Clone, PartialEq, Eq, Debug, RustcEncodable, RustcDecodable, HashStable)] </ins> pub enum YieldSource { /// An `<expr>.await`. Await,

Discussion:
Hi I'm pretty new to rust and programming in general. I was trying (failing) to write some toy async code and I got this internal compiler error, the theme seems to be always report ICEs so here we go This was from cargo: ~ The code I was trying was this code: ~ <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized:
ICEs with any statement between while inside a function that isn't async ICE Error without and without the ICE statement inside async function
claim
This is actually the same as . I think I've got a fix for both.
do you have a PR for this open?
Closing as a duplicate of , both of which are fixed by

<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Not had a lot of time to look at this unfortunately and it appears has come up with a fix in in the meantime. release-assignment
claim
assign (Sorry for the noise, testing a new GH feature)
Change:
<ins> error[E0432]: unresolved import `unresolved` --> $DIR/issue-113953.rs:3:5 | LL | use unresolved as u8; |     ^^^^^^^^^^^^^^^^ no external crate `unresolved` error: aborting due to previous error For more information about this error, try `rustc --explain E0432`. </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. --need <!-- 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
Crashes on but not on
Regression in nightly-2023-07-01 Regression in Regression in cc
reduced:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> error[E0308]: mismatched types --> $DIR/async-unwrap-suggestion.rs:5:16 | LL |         return Ok(6); |                ^^^^^ expected `i32`, found `Result<{integer}, _>` | = note: expected type `i32` found enum `Result<{integer}, _>` error[E0308]: mismatched types --> $DIR/async-unwrap-suggestion.rs:15:16 | LL |         return s; |                ^ expected `i32`, found `Result<{integer}, _>` | = note: expected type `i32` found enum `Result<{integer}, _>` help: consider using `Result::expect` to unwrap the `Result<{integer}, _>` value, panicking if the value is a `Result::Err` | LL |         return s.expect("REASON"); |                 +++++++++++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
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
Regression in probably ? cc
This is due to . The function name in the stack trace matches the title of that PR. cc
oops race condition, clicked the button before I saw you self-assigned -- I already found a fix
yeah, go ahead please.