jiebi/CodeConvo huggingface dataset:
Change:
--> $DIR/intermixed-lifetime.rs:6:28 | LL | struct Foo<const N: usize, 'a, T = u32>(&'a (), T); <del> |           -----------------^^---------- help: reorder the parameters: lifetimes, then types, then consts: `<'a, T, const N: usize>` </del> <ins> |           -----------------^^---------- help: reorder the parameters: lifetimes, then types, then consts: `<'a, T = u32, const N: usize>` </ins> error: type parameters must be declared prior to const parameters --> $DIR/intermixed-lifetime.rs:6:32 | LL | struct Foo<const N: usize, 'a, T = u32>(&'a (), T); <del> |           ---------------------^------- help: reorder the parameters: lifetimes, then types, then consts: `<'a, T, const N: usize>` </del> <ins> |           ---------------------^------- help: reorder the parameters: lifetimes, then types, then consts: `<'a, T = u32, const N: usize>` </ins> error: lifetime parameters must be declared prior to const parameters --> $DIR/intermixed-lifetime.rs:10:37 | LL | struct Bar<const N: usize, T = u32, 'a>(&'a (), T); <del> |           --------------------------^^- help: reorder the parameters: lifetimes, then types, then consts: `<'a, T, const N: usize>` </del> <ins> |           --------------------------^^- help: reorder the parameters: lifetimes, then types, then consts: `<'a, T = u32, const N: usize>` </ins> error: type parameters must be declared prior to const parameters --> $DIR/intermixed-lifetime.rs:10:28 | LL | struct Bar<const N: usize, T = u32, 'a>(&'a (), T); <del> |           -----------------^----------- help: reorder the parameters: lifetimes, then types, then consts: `<'a, T, const N: usize>` </del> <ins> |           -----------------^----------- help: reorder the parameters: lifetimes, then types, then consts: `<'a, T = u32, const N: usize>` </ins> error: aborting due to 4 previous errors

Discussion:
results in: when it should be: This should be easy to fix: just replace in the following line with an appropriate format string. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
For the record, it's not quite this simple, as doing so results in incorrect output when the parameter also has bounds. For example, it would render as because bounds are printed after the
Change:
[one] statement *[other] statements } with a body <del> .suggestion_use_comma_not_semicolon = use a comma to end a `match` arm expression </del> <ins> .suggestion_use_comma_not_semicolon = replace `;` with `,` to end a `match` arm expression </ins> parse_inclusive_range_extra_equals = unexpected `=` after inclusive range .suggestion_remove_eq = use `..=` instead

Discussion:
The reason why it should be changed is because the new error message makes it clearer you should replace with . I was following the book, and I encountered this error. I didn't understand how to solve it and asked on the community discord, then a user in the community server then helped me and I managed to fix the error. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
} if { <del> if self.option_loud_drop(7).is_some() && self.option_loud_drop(6).is_some() { </del> <ins> if self.option_loud_drop(6).is_some() && self.option_loud_drop(7).is_some() { </ins> self.loud_drop(8); true } else {

Discussion:
If you consider the following program: It will print "2,3,4,1," four times. The issue occurs on recent nightly as well as all the way back to 1.0.0. This is a bit weird IMO, and makes && and chains non-associative. IMO it's a bug that should be fixed to print "1,2,3,4,". IDK how much we can do about this at the current point, given backwards compatibility concerns. It might not stop programs from compiling, but programs might differ in their runtime output. There is with the name "Stabilize drop order" but if you read the text, it only concerns the drop order of structs, vecs, tuples, etc. Also, after the merge, the RFC author themself made a PR to add regression tests in , and mentioned that that PR was enough for getting the RFC tested. The RFC didn't include anything about && chains. I think the language should not be interpreted too generally. It took a long time until in which we we got some further drop order tests for "established" language constructs, while there have been many PRs with drop order tests for let-else. Originally I've discovered this in: , but given that it's so visible, I'm sure that someone else has already complained about this. Maybe one can just implement the change to "1,2,3,4," and make a crater run for it? cc label T-lang
Change:
} } SubSupConflict(var_origin, _, sub_r, _, sup_r) => { <ins> debug!("processing SubSupConflict") </ins> match free_regions_from_same_fn(self.tcx, sub_r, sup_r) { Some(ref same_frs) => { var_origins.push(var_origin);

Discussion:
For the input file below, the two distinct invocations of (but with identical arguments) are non-deterministically deciding whether or not to prompt with the "consider using an explicit lifetime parameter" hint. Input file (): Transcript: (See also for a problem with the suggestion actually provided by when it chooses to actually provide one.)
I tested it a bit, and the issue seems to be is fed slightly different information each time. In the first case we have a and in the second . In the constraint graph for some node we are trying to infer, there are multiple incoming edges and outgoing edges to and from . From my understanding the compiler only picks one node from these incoming edges and one node from these outgoing edges, and it doesn't pick the same pair each time (what I don't understand is why I didn't see the and variations).
I'm getting a non-deterministic error message using the latest nightlies: It's non-deterministic on my Fedora 20 machine but not my OSX machine.
Change:
match res { Res::Local(hir_id) => { let parent_def_id = self.cx.tcx.hir().get_parent_item(expr.hir_id); <del> let extent = self.cx.tcx.region_scope_tree(parent_def_id).var_scope(hir_id.local_id); </del> <ins> let extent = self.cx.tcx.region_scope_tree(parent_def_id).var_scope(hir_id.local_id).unwrap(); </ins> if index_used_directly { self.indexed_directly.insert( seqvar.segments[0].ident.name,

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I was just looking at the parsing code for const generic exprs.. claim
actually, so this isn't related to incorrectly parsing , since we're parsing in expr position to allow if-let chains.. -- this is due to const eval lowering to MIR and the fact that const generic parameters have no enclosing scope. Adding around the generic args works, but I don't know where exactly to hack in a scope for these params. release-assignment label A-const-eval A-mir
Maybe fixing this also fixes :slightlysmilingface:
This gives an error without ICE in 1.55
It was unclear to me - I think meant that changing to gives a compile error instead of an ICE. So the proper fix here is probably to add somewhere instead of panicking.
Then this should be easy. claim
Change:
} } <ins> #[derive(Clone, Debug, Deserialize, PartialEq, Eq)] #[serde(untagged)] pub enum RustOptimize { #[serde(deserialize_with = "deserialize_and_validate_opt_level")] String(String), Bool(bool), } impl Default for RustOptimize { fn default() -> RustOptimize { RustOptimize::Bool(false) } } fn deserialize_and_validate_opt_level<'de, D>(d: D) -> Result<String, D::Error> where D: serde::de::Deserializer<'de>, { let v = String::deserialize(d)?; if ["0", "1", "2", "3", "s", "z"].iter().find(|x| **x == v).is_some() { Ok(v) } else { Err(format!(r#"unrecognized option for rust optimize: "{}", expected one of "0", "1", "2", "3", "s", "z""#, v)).map_err(serde::de::Error::custom) } } impl RustOptimize { pub(crate) fn is_release(&self) -> bool { if let RustOptimize::Bool(true) | RustOptimize::String(_) = &self { true } else { false } } pub(crate) fn get_opt_level(&self) -> Option<String> { match &self { RustOptimize::String(s) => Some(s.clone()), RustOptimize::Bool(_) => None, } } } </ins> #[derive(Deserialize)] #[serde(untagged)] enum StringOrInt<'a> { String(&'a str), Int(i64), } define_config! { /// TOML representation of how the Rust build is configured. struct Rust { <del> optimize: Option<bool> = "optimize", </del> <ins> optimize: Option<RustOptimize> = "optimize", </ins> debug: Option<bool> = "debug", codegen_units: Option<u32> = "codegen-units", codegen_units_std: Option<u32> = "codegen-units-std",

Discussion:
It would be nice if we could speed up stage1 library builds by building it with less opts and no debuginfo. had the idea to control this with something like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
i'm going to use as a separate more broad issue for - i'll repurpose this to just be for (which is a lot simpler to add)
mentoring instructions: add this option to the struct, then around , set
Can we confirm before we land this support that this is actually a significant win in practice? I recall historically having issues with optimize = false equivalents where the net effect is broken and slower tests - I would prefer to avoid landing support we don't want to actually support :)
this is especially useful in combination with - optimizing only rustc and not std should be a speedup even if we include the time taken for tests.
claim
Maybe we should just generalize the config value to a number/boolean, instead of adding a new attribute?
Change:
<ins> // check-pass trait A { type Assoc; } impl A for () { // FIXME: it would be nice for this to at least cause a warning. type Assoc = Foo<()>; } struct Foo<T: A>(T::Assoc); 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium
Change:
<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>

Discussion:
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:
Change:
fn next(&mut self) -> Option<Self::Item> { let (mut sub, tail) = parse_next_substitution(self.s)?; self.s = tail; <del> match sub { Substitution::Format(_) => { if let Some(inner_span) = sub.position() { sub.set_position(inner_span.start + self.pos, inner_span.end + self.pos); self.pos += inner_span.end; } } Substitution::Escape => self.pos += 2, </del> <ins> if let Some(InnerSpan { start, end }) = sub.position() { sub.set_position(start + self.pos, end + self.pos); self.pos += end; </ins> } Some(sub) }

Discussion:
rustc crashes on the following input, found by :
searched nightlies: from nightly-2021-01-01 to nightly-2021-12-24 regressed nightly: nightly-2021-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
The regression happened in . cc
label regression-from-stable-to-stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
I've been taking a look at this. It's pretty interesting. I'm not entirely sure I'll be able to work it out, but I figure I may as well assign myself for the time being while I attempt to solve it.
Another test case:
The problem seems to reside within the crate , in the files and . The function in has a macro, , which is in charge of looking for foreign substitutions - that is, someone using printf or shell style formatting rather than Rust's style. It's a macro so it can be generic over the two types of substitution. The first time this macro is called, for printf substitutions, it finds two (I think "%%" and "%", though I'm not sure it's exactly that). The code that actually detects the substitutions is in . When parsing the substitution, in the function , it is somehow finding that the second substitution has a boundary in the middle of the character. I'm not sure exactly how yet. This gets turned into a span in . The span is malformed, as it splits a character in two, so the second the code tries to use it for anything it trips an assertion and causes this ICE. The remaining problem is figuring out what's going wrong in . This sort of string manipulation is not my forte. I'll probably take another few cracks at it though.
Something is broken about . This change makes the ICE go away (but probably breaks other things):
When returns here: it seems like we should increment by , but we actually only increment it by 2:
yes, I get the exact same error. . The error disappears if you add a new line after the , so maybe your text editor did that automatically.

That was it, thanks. I'm going to unassign myself from this. I do hope my exploration ends up being helpful to whoever fixes it though. if you want to fix this yourself, you certainly seem further along than I was, though you shouldn't feel any pressure to do so if you don't want to.
I put up a PR for a
I opened a new issue for your bug, because it's not exactly the same as this one.
Change:
pub llvm_use_libcxx: bool, // rust codegen options <del> pub rust_optimize: bool, </del> <ins> pub rust_optimize: RustOptimize, </ins> pub rust_codegen_units: Option<u32>, pub rust_codegen_units_std: Option<u32>, pub rust_debug_assertions: bool,

Discussion:
It would be nice if we could speed up stage1 library builds by building it with less opts and no debuginfo. had the idea to control this with something like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
i'm going to use as a separate more broad issue for - i'll repurpose this to just be for (which is a lot simpler to add)
mentoring instructions: add this option to the struct, then around , set
Can we confirm before we land this support that this is actually a significant win in practice? I recall historically having issues with optimize = false equivalents where the net effect is broken and slower tests - I would prefer to avoid landing support we don't want to actually support :)
this is especially useful in combination with - optimizing only rustc and not std should be a speedup even if we include the time taken for tests.
claim
Maybe we should just generalize the config value to a number/boolean, instead of adding a new attribute?
Change:
use rustc_span::{ExpnKind, Span, DUMMY_SP}; use std::fmt; use std::iter; <ins> use std::ops::ControlFlow; </ins> use crate::traits::query::evaluate_obligation::InferCtxtExt as _; use crate::traits::query::normalize::AtExt as _;

Discussion:
When I run this code (via ): I get the output I expected (i.e., a single line of output that says "My number is 42"). However, if I run this code (via the same with no other changes): I get two compiler errors. The first error indicates that is not in scope - this makes sense, I have not defined anywhere. However, the second error indicates (provided below) does not make sense: It appears that, when there are no other compiler issues, the compiler can infer a type for just fine. However, as soon as any other compiler issue appears, it loses the ability to infer type. That doesn't make sense to me - the ability to infer type should be unrelated to any other compiler errors present. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I partially fixed this for and in , but not in general. I am dissatisfied with this error message. I'll look into fixing it. claim
Change:
impl Stdio { fn to_handle(&self, stdio_id: c::DWORD) -> io::Result<Handle> { match *self { <ins> // If no stdio handle is available, then inherit means that it // should still be unavailable so propagate the // INVALID_HANDLE_VALUE. </ins> Stdio::Inherit => { <del> stdio::get(stdio_id).and_then(|io| { io.handle().duplicate(0, true, c::DUPLICATE_SAME_ACCESS) }) </del> <ins> match stdio::get(stdio_id) { Ok(io) => io.handle().duplicate(0, true, c::DUPLICATE_SAME_ACCESS), Err(..) => Ok(Handle::new(c::INVALID_HANDLE_VALUE)), } </ins> } Stdio::Raw(handle) => { RawHandle::new(handle).duplicate(0, true, c::DUPLICATE_SAME_ACCESS)

Discussion:
As , if one of the stdio handles for a Windows process is unset (e.g. isn't present) then you won't actually be able to spawn a process by default. All handles are set, by default, to "inherit", but duplicate the existing handle, which in turn means that if the stdio handle isn't present this operation will fail. Rust currently by always opening up handles even if is specified (just pointing them to a blank stream), but Rust should also defend against this situation when it was spawned from elsewhere.
cc
Change:
<ins> // Regression test for issue #84195 // Checks that we properly fire lints that occur inside // anon consts. #![deny(semicolon_in_expressions_from_macros)] macro_rules! len { () => { 0; }; //~  ERROR trailing semicolon //~| WARN this was previously accepted } fn main() { let val: [u8; len!()] = []; } </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. --After testing, it's this macro here: The semicolon in the third variant causes the error when used in a context such as: Note that prior to updating I was using , which did not error. This errors on Nightly and Stable, I tested both ( and both have the same result). Removing the semicolon causes the project to build fine and function as it did before updating. : This error is repeated over and over again before the notification saying to submit the bug report <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
Can you share the original repository, or provide a self-contained reproduction of the issue?
here is one I got to error in the same way: I also noticed this warning that I believe I failed to include in the original issue: If I remove the semicolon, this warning does not show up, and the program works as expected.
Change:
<del> // Copyright 2012-2013 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Check that non-constant exprs do fail as count in fixed length vec type fn main() { fn bar(n: isize) { let _x: [isize; n]; //~^ ERROR attempt to use a non-constant value in a constant [E0435] } } </del>

Discussion:
rustc 1.0.0 - 1.11.0: rustc 1.12.0 - 1.15.0: rustc 1.16.0 - present: Can we have the first one back please?
To clarify, the problem is in the note:
Note introduced in , using the exact wording from . Rust 1.12 fully transitioned to MIR, which made the repeat count no longer special, thus losing the special error message. I think the note should be reworded to "non-constant used as constant".
The error message today speaks the truth and does so quite well. Closing.
The span label is still pretty nonsensical.
Okay, I'll reopen. Can you provide the exact wording you'd expect? (I personally don't really see any point for a span label, but ... ).
Either remove the label or just "non-constant value" seems to make more sense to me. It's the "with constant" that is weird IMO.
I'll PR.
I just came here after googling and want to say that the first error message is a lot easier to understand!