jiebi/CodeConvo huggingface dataset:
Code change:
} } <del> debug!("enforce_member_constraint: final least choice = {:?}", least_choice); if least_choice != member_lower_bound { </del> <ins> // (#72087) Different `ty::Regions` can be known to be equal, for // example, we know that `'a` and `'static` are equal in a function // with a parameter of type `&'static &'a ()`. // // When we have two equal regions like this `expansion` will use // `lub_concrete_regions` to pick a canonical representative. The same // choice is needed here so that we don't end up in a cycle of // `expansion` changing the region one way and the code here changing // it back. let lub = self.lub_concrete_regions(least_choice, member_lower_bound); debug!( "enforce_member_constraint: final least choice = {:?}nlub = {:?}", least_choice, lub ); if lub != member_lower_bound { </ins> *var_values.value_mut(member_vid) = VarValue::Value(least_choice); true } else {

Related discussion:
text: () Errors: Backtrace: modify labels: +I-hang +T-compiler +C-bug +A-lifetimes
somewhat minimized: To replicate this I needed: async two other arguments by ref at least one arg must not be bound to , compiles quickly the problematic argument must be contain an indirection: compiles fine. and also freeze. and a trait object containing at least one non marker trait explicitly bound to . and are both ok
repro is a regression in 1.43. It compiles immediately with 1.39 through 1.42.
I am currently bisecting this using
regression in modify labels: -E-needs-bisection
FYI who had context on .
Code change:
const LEN: usize = 4; <del> struct SingleUnused(i32, [u8; LEN], String); //~^ ERROR: field `1` is never read </del> <ins> struct UnusedAtTheEnd(i32, f32, [u8; LEN], String, u8); //~^ ERROR:fields `1`, `2`, `3`, and `4` are never read //~| NOTE: fields in this struct //~| HELP: consider removing these fields struct UnusedJustOneField(i32); //~^ ERROR: field `0` is never read </ins> //~| NOTE: field in this struct <del> //~| HELP: consider changing the field to be of unit type </del> <ins> //~| HELP: consider removing this field </ins> <del> struct MultipleUnused(i32, f32, String, u8); //~^ ERROR: fields `0`, `1`, `2`, and `3` are never read </del> <ins> struct UnusedInTheMiddle(i32, f32, String, u8, u32); //~^ ERROR: fields `1`, `2`, and `4` are never read </ins> //~| NOTE: fields in this struct <del> //~| HELP: consider changing the fields to be of unit type </del> <ins> //~| HELP: consider changing the fields to be of unit type to suppress this warning while preserving the field numbering, or remove the fields </ins> struct GoodUnit(());

Related discussion:
text: The idea of changing a field to unit type to preserve field numbering makes sense for fields in the middle of a tuple. However, if the unused field is at the end, or it's the only field, then deleting it won't affect field numbering of any other field. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
<ins> error: prefix `world` is unknown --> $DIR/lex-bad-str-literal-as-char-4.rs:4:25 | LL |         println!('hello world'); |                         ^^^^^ unknown prefix | = note: prefixed identifiers and literals are reserved since Rust 2021 help: if you meant to write a string literal, use double quotes | LL |         println!("hello world"); |                  ~           ~ error[E0762]: unterminated character literal --> $DIR/lex-bad-str-literal-as-char-4.rs:4:30 | LL |         println!('hello world'); |                              ^^^ | help: if you meant to write a string literal, use double quotes | LL |         println!("hello world"); |                  ~           ~ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0762`. </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced
Code change:
<ins> // Copyright 2015 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. // Test to ensure we only report an error for the first issued loan that // conflicts with a new loan, as opposed to every issued loan.  This keeps us // down to O(n) errors (for n problem lines), instead of O(n^2) errors. fn main() { let mut x = 1; let mut addr; loop { match 1 { 1 => { addr = &mut x; } //~^ ERROR cannot borrow `x` as mutable more than once at a time 2 => { addr = &mut x; } //~^ ERROR cannot borrow `x` as mutable more than once at a time _ => { addr = &mut x; } //~^ ERROR cannot borrow `x` as mutable more than once at a time } } } </ins>

Related discussion:
text: Ran into this when running a fauly tt muncher with ~100 items. We can now compete with C++ in the compiler spew area as well! :-P
Ran into this while demonstrating why you need raw pointers to do a singly-linked-queue: 66 Borrow check errors in this test.
Code change:
} OptLevel::Default } else { <del> match ( cg.opt_level.as_ref().map(String::as_ref), nightly_options::is_nightly_build(), ) { (None, _) => OptLevel::No, (Some("0"), _) => OptLevel::No, (Some("1"), _) => OptLevel::Less, (Some("2"), _) => OptLevel::Default, (Some("3"), _) => OptLevel::Aggressive, (Some("s"), true) => OptLevel::Size, (Some("z"), true) => OptLevel::SizeMin, (Some("s"), false) | (Some("z"), false) => { early_error( error_format, &format!( "the optimizations s or z are only  accepted on the nightly compiler" ), ); } (Some(arg), _) => { </del> <ins> match cg.opt_level.as_ref().map(String::as_ref) { None => OptLevel::No, Some("0") => OptLevel::No, Some("1") => OptLevel::Less, Some("2") => OptLevel::Default, Some("3") => OptLevel::Aggressive, Some("s") => OptLevel::Size, Some("z") => OptLevel::SizeMin, Some(arg) => { </ins> early_error( error_format, &format!(

Related discussion:
text: The code around opt-levels indicates only nightly can use or . Non-nightly s should not even report those values as possible options.
Code change:
} OptLevel::Default } else { <del> match ( cg.opt_level.as_ref().map(String::as_ref), nightly_options::is_nightly_build(), ) { (None, _) => OptLevel::No, (Some("0"), _) => OptLevel::No, (Some("1"), _) => OptLevel::Less, (Some("2"), _) => OptLevel::Default, (Some("3"), _) => OptLevel::Aggressive, (Some("s"), true) => OptLevel::Size, (Some("z"), true) => OptLevel::SizeMin, (Some("s"), false) | (Some("z"), false) => { early_error( error_format, &format!( "the optimizations s or z are only  accepted on the nightly compiler" ), ); } (Some(arg), _) => { </del> <ins> match cg.opt_level.as_ref().map(String::as_ref) { None => OptLevel::No, Some("0") => OptLevel::No, Some("1") => OptLevel::Less, Some("2") => OptLevel::Default, Some("3") => OptLevel::Aggressive, Some("s") => OptLevel::Size, Some("z") => OptLevel::SizeMin, Some(arg) => { </ins> early_error( error_format, &format!(

Related discussion:
text: Added in these options are still unstable, this issue will track their progress to becoming stable!
Also note that is adding Cargo support, currently through and , but as we may want more human readable names.
I don't even think there is a single word that describes what does. As far as I know it was first introduced in clang and selected for its closeness to and connotations of compression, but this doesn't help at all when you need an immediately understandable token in
/ for and for ?
is right, "s" and "z" are not clear at all. I had no idea what "z" even did until I looked it up. it is the same as "s" but without loop vectorisation. According to it is intended to reduce size even further. I like the "size-1"/"size-2" idea.
We are potentially interested in this for Gecko's integration of Rust code, see [1]. We'd need to do more measurements to determine if the performance impact is acceptable though. [1]
thanks for the info! We haven't seen a lot of movement here in awhile and we've got support in Cargo/build scripts now, so I'd like to propose we stabilize this: fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [ ] [x] [x] [ ] [ ] [x] [x] [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
IS this properly documented? That can come after we've approved for stability, right?
good point! I think we should definitely make sure it's documented at least in or the various man pages.
yes, that should come before the final PR itself lands though.
It seems like there was an open concern that these tokens (especially for Cargo) aren't very clear. Do we want to take a short at single-word tokens before stabilizing?
I'm not personally motivated to do so as this is such a niche feature it seems like it's not worth the effort, but others may feel differently.
I feel differently!
Code change:
} OptLevel::Default } else { <del> match ( cg.opt_level.as_ref().map(String::as_ref), nightly_options::is_nightly_build(), ) { (None, _) => OptLevel::No, (Some("0"), _) => OptLevel::No, (Some("1"), _) => OptLevel::Less, (Some("2"), _) => OptLevel::Default, (Some("3"), _) => OptLevel::Aggressive, (Some("s"), true) => OptLevel::Size, (Some("z"), true) => OptLevel::SizeMin, (Some("s"), false) | (Some("z"), false) => { early_error( error_format, &format!( "the optimizations s or z are only  accepted on the nightly compiler" ), ); } (Some(arg), _) => { </del> <ins> match cg.opt_level.as_ref().map(String::as_ref) { None => OptLevel::No, Some("0") => OptLevel::No, Some("1") => OptLevel::Less, Some("2") => OptLevel::Default, Some("3") => OptLevel::Aggressive, Some("s") => OptLevel::Size, Some("z") => OptLevel::SizeMin, Some(arg) => { </ins> early_error( error_format, &format!(

Related discussion:
text: If I change the patch to , and would that be acceptable? Or is it too late since Cargo has already merged and ? If so then we should probably stick with that but they should be properly documented since clearly very few people know what they mean.
I think we're definitely still able to change, we just might have to have a small period of time where we support everything to deprecate s/z
is there any particular reason that, for Cargo, we need more than just ? In practice, the main historical distinction between and was that was OSX-specific, and gave you "definitely, for realz optimize for size." As far as I can tell, Cargo really only needs a way for people to say "I want you to optimize for size, please" and having multiple different versions of "optimize for size" at the Cargo level seems likely to introduce more confusion than help. I propose that we add to Cargo, and not leak and . I think I feel the same way about but don't have as strong of an opinion there.
Sounds plausible to me! In that case sounds like there's work to do, so I'll cancel the FCP fcp cancel
proposal cancelled.
That's not what does, as far as I can tell. According to Clang's manual: Also see . By the way, there is also ! , which is: Sounds like it could be useful. I suggest for that.
I came here because I wasn't sure what -Oz did - now I know. I would like to point out that "size1" and "size2" is not much better, imho. Ok, so there's a size difference. But which one is supposed to be smaller? The bigger number, because it tries more agressively to make it smaller, or the smaller number, for intuitive reasons? I can see the parallel with O1, O2, O3 -increasing optimization for speed, and S1, S2, S3 -increasing optimization for size, but perhaps this should be made more explicit then? We can always keep "s", "o", and so on as shorthand aliases
Hello This seems to have gone to sleep. I mean, the name for it is important, but no discussion seems to be happening for like 9 months ‒ is it likely to move forward?
Code change:
} OptLevel::Default } else { <del> match ( cg.opt_level.as_ref().map(String::as_ref), nightly_options::is_nightly_build(), ) { (None, _) => OptLevel::No, (Some("0"), _) => OptLevel::No, (Some("1"), _) => OptLevel::Less, (Some("2"), _) => OptLevel::Default, (Some("3"), _) => OptLevel::Aggressive, (Some("s"), true) => OptLevel::Size, (Some("z"), true) => OptLevel::SizeMin, (Some("s"), false) | (Some("z"), false) => { early_error( error_format, &format!( "the optimizations s or z are only  accepted on the nightly compiler" ), ); } (Some(arg), _) => { </del> <ins> match cg.opt_level.as_ref().map(String::as_ref) { None => OptLevel::No, Some("0") => OptLevel::No, Some("1") => OptLevel::Less, Some("2") => OptLevel::Default, Some("3") => OptLevel::Aggressive, Some("s") => OptLevel::Size, Some("z") => OptLevel::SizeMin, Some(arg) => { </ins> early_error( error_format, &format!(

Related discussion:
text: As for me, I'd rather have the feature stabilized (I'm often aiming at devices with chronic lack of storage space), no matter the actual values used. Or is it blocked on anything else beside choosing the right name?
Side note: the crash in only reproduces with -Os (probably an LLVM bug)
Since the lastest LLVM upgrade rustc / LLVM does more agressive ~inlining~ loop unrolling. This results in increased binary size of embedded / no_std programs: a hundreds of bytes increase, or about a 7x increase, in the case of the smallest Cortex-M binary cf. . As we are shooting for embedded Rust on stable it would be great to also provide a way to optimize for size (which is pretty important for embedded applications that target resource constrained devices) on stable. What can we do to move this forward. Can we at least stabilize "s" on rustc? Cargo already allows in the but requires a nightly toolchain. is this (opt-level) being discussed as part of the Cargo profile revamp?
I think those optimizations have baked long enough that it should be fine to stabilize now personally!
Code change:
use rustc_span::symbol::{kw, sym, Ident, Symbol}; use rustc_trait_selection::traits::{self, ObligationCauseCode}; <del> use std::fmt::Display; </del> impl<'a, 'tcx> FnCtxt<'a, 'tcx> { fn check_expr_eq_type(&self, expr: &'tcx hir::Expr<'tcx>, expected: Ty<'tcx>) { let ty = self.check_expr_with_hint(expr, expected);

Related discussion:
text: I just encountered this output: We currently mention available fields when the field used isn't found. It would be nice if we peeked at the types for the available fields to see if any of them has any fields (including through deref) of the name we originally wanted. In this case, I would love to see the following output: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'll work on this. claim
I was just about to open a PR when I saw that you claimed the issue. It's my fault for not claiming this issue myself obviously, so if you've already been investing time into this the issue its still yours, but if you haven't can I open a PR for this?
I've done nothing yet as I planned to work on this tomorrow morning, so this is yours :)
release-assignment
if you're still interested in contributing, it seems to me that might be similar in scope and section of the codebase you could work in.
Thank you.
Code change:
} } ast::TraitItemKind::Type(_, ref default) => { <del> // We use two if statements instead of something like match guards so that both // of these errors can be emitted if both cases apply. </del> <ins> // We use three if statements instead of something like match guards so that all // of these errors can be emitted if all cases apply. </ins> if default.is_some() { gate_feature_post!(&self, associated_type_defaults, ti.span, "associated type defaults are unstable");

Related discussion:
text: clauses on associated types don't work yet so should be feature gated, presumably with . cc . Happens on versions = 1.24
Code change:
<del> use crate::t; </del> <ins> use crate::{t, VERSION}; </ins> use std::path::{Path, PathBuf}; use std::str::FromStr; use std::{

Related discussion:
text: New contributors haven't use before, so there's no reason for them to read the changelog: nothing has changed.
I can tackle this.
that would be great! To get started, take a look at . In addition to adding , also add . You'll have to move from to so you can access it in . You should also double check that the changelog warning isn't printed during the command itself. I'm not sure exactly how to do that without reading the code, but I expect it to be a simple or something like that.
Code change:
"test/bench/shootout-meteor.rs", # BSD "test/bench/shootout-pidigits.rs", # BSD "test/bench/shootout-regex-dna.rs", # BSD <ins> "test/bench/shootout-reverse-complement.rs", # BSD </ins> "test/bench/shootout-threadring.rs", # BSD ]

Related discussion:
text: See I propose to change the license of Non trivial contributors: OK OK Contributors appearing in git blame that are trivial: OK OK OK OK OK Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license () Cheers
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
Code change:
// collect results based on the filter function if ident.name == lookup_ident.name && ns == namespace { <del> if filter_fn(name_binding.def()) { </del> <ins> let def = name_binding.def(); if filter_fn(def) { </ins> // create the path let mut segms = path_segments.clone(); if lookup_ident.span.rust_2018() {

Related discussion:
text: For this code: You get the following error message: The suggestion may be excused to be not 100% perfect, but here it suggests to add an use statement despite that same item being imported already. What I want is this exactly: that it removes stuff from the suggestion list that is already being imported. Note that changing the glob import to a non glob one doesn't change anything.
cc
Why is that even an error?
tuple structs have private fields by default, you can't construct instances of B outside of the foo module.
oh ^^ maybe we should simply modify this error message then to say that the "function" is private?
It already says "constructor is not visible here due to private fields". That's okay, but maybe you might have meant another B from another module or something. However, the candidate offered is not any better as its the same one you are attempting to use.
Reopening to track "removal of suggestion" work for pub tuple structs with private fields.
Code change:
<ins> // run-pass // ignore-emscripten no subprocess support #![feature(set_stdio)] use std::fmt; use std::fmt::{Display, Formatter}; use std::io::set_panic; pub struct A; impl Display for A { fn fmt(&self, _f: &mut Formatter<'_>) -> fmt::Result { panic!(); } } fn main() { set_panic(Some(Box::new(Vec::new()))); assert!(std::panic::catch_unwind(|| { eprintln!("{}", A); }) .is_err()); } </ins>

Related discussion:
text: I tried this code (using ): I expected to see this happen: The thread should've panicked with 'Index out of bounds: the len is 0 but the index is 0' Instead, this happened: Thread crashes with SIGILL (illegal instruction) This bug works in stable, beta and nightly. It also does the same in . Here is my (I figured that it might be useful given the nature of the bug). The bug doesn't appear if run from main, nor if run directly (without passing from the Display impl). : <details<summaryBacktrace</summary<prunning 1 test thread panicked while processing panic. aborting. error: test failed, to rerun pass '--lib' Caused by: process didn't exit successfully: (signal: 4, SIGILL: illegal instruction) </p</details
This seems to be due to the . Using instead works fine.
I can reproduce. This seems to happen if LOCALSTDERR is initialized (e.g., with setpanic) which leads us to this . Note that the RefCell there is borrowed so that we can write to it, but then when we go to panic we try to temporarily . This borrows the RefCell mutably, again, leading to a panic. Since this happens within an existing panic, we abort the process. Smaller example:
Code change:
fn main() -> () { let mut _0: ();                      // return place in scope 0 at $DIR/inline-generator.rs:8:11: 8:11 <del> let _1: std::ops::GeneratorState<<impl std::ops::Generator<bool> as std::ops::Generator<bool>>::Yield, <impl std::ops::Generator<bool> as std::ops::Generator<bool>>::Return>; // in scope 0 at $DIR/inline-generator.rs:9:9: 9:11 let mut _2: std::pin::Pin<&mut impl std::ops::Generator<bool>>; // in scope 0 at $DIR/inline-generator.rs:9:14: 9:32 let mut _3: &mut impl std::ops::Generator<bool>; // in scope 0 at $DIR/inline-generator.rs:9:23: 9:31 let mut _4: impl std::ops::Generator<bool>; // in scope 0 at $DIR/inline-generator.rs:9:28: 9:31 </del> <ins> let _1: std::ops::GeneratorState<i32, bool>; // in scope 0 at $DIR/inline-generator.rs:9:9: 9:11 let mut _2: std::pin::Pin<&mut [generator@$DIR/inline-generator.rs:15:5: 15:41]>; // in scope 0 at $DIR/inline-generator.rs:9:14: 9:32 let mut _3: &mut [generator@$DIR/inline-generator.rs:15:5: 15:41]; // in scope 0 at $DIR/inline-generator.rs:9:23: 9:31 let mut _4: [generator@$DIR/inline-generator.rs:15:5: 15:41]; // in scope 0 at $DIR/inline-generator.rs:9:28: 9:31 </ins> +     let mut _7: bool;                    // in scope 0 at $DIR/inline-generator.rs:9:14: 9:46 scope 1 { debug _r => _1;                  // in scope 1 at $DIR/inline-generator.rs:9:9: 9:11

Related discussion:
text: Previously: Now: <!-- 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
Inlining exposes a use of unnormalized local in a call terminator (not sure if this is more of an issue with inlining or a validator): Note: revision annotation doesn't work in an auxiliary file (so it isn't tested on CI with mir-opt-level=2). modify labels: +A-mir-opt-inlining
This ICEs again because the fix was reverted Can someone reopen please?
Due to this new requires to trigger. <details<summaryICE:</summary</details
(FWIW can also trigger this: )
fixes this for and , but it still ICEs with on its own or with mir-opt-level 1/2 cc