jiebi/CodeConvo huggingface dataset:
Change:
$EndFeature, " ```"), <del> #[unstable(feature = "saturating_neg", issue = "59983")] </del> <ins> #[stable(feature = "saturating_neg", since = "1.45.0")] </ins> #[rustc_const_unstable(feature = "const_saturating_int_methods", issue = "53718")] #[inline] pub const fn saturating_abs(self) -> Self {

Discussion:
It would be great to have and functions for signed integer types. The current work-around is using a pattern like but having explicit functions would lift the corner-case knowledge "burden" from the user.
What do you expect them to return? Just for the two values that can't be expressed? IMHO you should prefer the instead and explicitly handle that.
The and functions both have a corner case when the negative minimum value is used (e.g. -128 for type i8). The result cannot be represented within the bounds of the output type. The / variants shall return a best-effort value (like 127 in case of -128 i8 input), similar to the existing functions. asserteq!(127i8.saturatingabs(), 127); asserteq!(-127i8.saturatingabs(), 127); asserteq!(-128i8.saturatingabs(), 127); asserteq!(127i8.saturatingneg(), -127); asserteq!(-127i8.saturatingneg(), 127); asserteq!(-128i8.saturating_neg(), 127);
These seems reasonable. I'd suggest just making a PR with them unstable and seeing what libs says. By using they'll automatically get the new saturating implementation, too, which should be better for optimization and codegen than the approach.
Haven't done a PR for Rust yet so will take a look at the contribution guidelines and try to get along.
What's holding up stabilization on this? It seems relatively simple.
In my opinion there is nothing specific holding this up from being stabilized. Initially I wanted to give it some time for others to comment, then forgot about. Added a PR for stabilization now.
Change:
<ins> // Regression test for issue #75062 // Tests that we don't ICE on a privacy error for a fieldless tuple struct. mod foo { struct Bar(); } fn main() { foo::Bar(); //~ ERROR tuple struct } </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. --It is very finicky to reproduce. is as minimal as I could get without significantly changing the structure of the macro or having other errors cover it up. Apologies for the mess! Updated 2020-08-04: I got it down to a total of only 130 lines of code. Please review the improved output below. Instructions: the project: The ICE was triggered by change in , where I simply changed the scoping on a nested inner generated by a macro from public to private. : On stable, errors regarding scoping are printed (this error is repeated many times): On nightly, a backtrace occurs. <details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongcargo expand with pub struct (updated 2020-08-04)</strong</summary<p</p</details
I have reduced this reproducer from about 500 lines of code total to 130 lines total. There are more syntax errors in it now, but the panic still triggers before them. Most of the other things I could change create an error that short circuits the compiler before the panic could trigger. EDIT: I also just updated the backtrace, because I didn't ask for a backtrace last time.
Let's get a MCVE and bisect the culprit PR. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Minimized:
is the likely cause.
Assigning as and removing .
Change:
#[rustc_specialization_trait] pub(super) unsafe trait IsZero { <del> /// Whether this value's representation is all zeros </del> <ins> /// Whether this value's representation is all zeros, /// or can be represented with all zeroes. </ins> fn is_zero(&self) -> bool; }

Discussion:
I want to initialize a large with . Compiling with Rust 1.66 generates instructions. However, after initializing with the code gets vectorized as expected: The generated assembly contains instructions. Now, the weird thing is that if I have both functions in the same file, both get vectorized. See this . As long as is commented out, is not vectorized. As soon as you remove the comment, both functions are vectorized.
Easiest fix for specifically would be to update , I think. We don't guarantee a layout for it, but internally for optimizations I think we'd be safe doing this. (We can put some tests like in non-public stuff to help double-check it.)
When is , couldn't the part of the memory layout be anything since it shouldn't be accessed? Couldn't we use that for optimization? So for example, if sets the discriminator bit to 0, couldn't we always zero out the entire memory no matter what is? Or if the discriminator is represented with a non-zero value, couldn't the whole data structure be filled up with that value (or just left unitialized depending on which is faster)?
Unfortunately not, because there can be other niches than 0. For instance, has the value 0xffff_ffff on Unix platforms.
Can we at least assume that two -s will always have the same bytes in memory for any fixed ? If so, couldn't we vectorize filling up the with those bytes?
I think similar to . iirc the main issue is that LLVM's InstCombine removes the instructions before reaching the passes that could use this information to optimize - at this point, it generally becomes a series of stores with gaps between which LLVM no longer knows can be written to freely.
No, because something like is half , where "the same" isn't a meaningful question. That's exactly what I mention for -- you can use that to check that it's a value where it would be legal to zero out the whole thing, and if that function returns then uses a zeroing allocator instead of the needing initialize the memory.
Change:
forward!(pub fn set_is_lint(&mut self,) -> &mut Self); forward!(pub fn disable_suggestions(&mut self,) -> &mut Self); <ins> forward!(pub fn clear_suggestions(&mut self,) -> &mut Self); </ins> forward!(pub fn multipart_suggestion( &mut self,

Discussion:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
/// Backs off using lightweight spinning. /// <del> /// This method should be used for: ///     - Retrying an operation because another thread made progress. i.e. on CAS failure. ///     - Waiting for an operation to complete by spinning optimistically for a few iterations ///     before falling back to parking the thread (see `Backoff::is_completed`). </del> <ins> /// This method should be used for retrying an operation because another thread made /// progress. i.e. on CAS failure. </ins> #[inline] pub fn spin_light(&self) { let step = self.step.get().min(SPIN_LIMIT);

Discussion:
Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Done in I believe
assign
Change:
<del> Subproject commit c4dd3f4ef98f8527aa652e8154ff044ca3e88455 </del> <ins> Subproject commit 655eed35b7ca7cae08f21ead6151b9dfb69794ff </ins>

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!
Change:
suggests_in_band = true; (generics.span, format!("<{}>", lifetime_ref)) }; <del> err.span_suggestion( span, &format!("consider introducing lifetime `{}` here", lifetime_ref), sugg, Applicability::MaybeIncorrect, ); </del> <ins> if !span.from_expansion() { err.span_suggestion( span, &format!("consider introducing lifetime `{}` here", lifetime_ref), sugg, Applicability::MaybeIncorrect, ); } else if suggest_note { suggest_note = false; // Avoid displaying the same help multiple times. err.span_label( span, &format!( "lifetime `{}` is missing in item created through this procedural  macro", lifetime_ref, ), ); } </ins> } MissingLifetimeSpot::HigherRanked { span, span_type } => { err.span_suggestion(

Discussion:
In case there is an undeclared lifetime in an ADT deriving a wrong help message is emited causes the following error thx, bye
There are two things here: 1) the suggestion should try and identify spans coming from macro expansion and not suggest changes 2) in this case expands to the following: Note the param, which could avoid having any lifetimes and thing would work correctly. We can probably change the desugaring to not specify the lifetime and then we would avoid the second unnecessary duplicated error. would you happen to know if there's any clear negative in doing 2 above and if not, point me in the right direction in to make that change?
I believe that we can't remove the explicit lifetime here. This would allow for even if is only implemented for .
Change:
let template_str = &template_str.as_str(); let template_snippet = ecx.source_map().span_to_snippet(template_sp).ok(); <ins> if let Some(snippet) = &template_snippet { let snippet = snippet.trim_matches('"'); match default_dialect { ast::LlvmAsmDialect::Intel => { if let Some(span) = check_syntax_directive(snippet, ".intel_syntax") { let span = template_span.from_inner(span); let mut err = ecx.struct_span_err(span, "intel syntax is the default syntax on this target, and trying to use this directive may cause issues"); err.span_suggestion( span, "remove this assembler directive", "".to_string(), Applicability::MachineApplicable, ); err.emit(); } if let Some(span) = check_syntax_directive(snippet, ".att_syntax") { let span = template_span.from_inner(span); let mut err = ecx.struct_span_err(span, "using the .att_syntax directive may cause issues, use the att_syntax option instead"); let asm_end = sp.hi() - BytePos(2); let suggestions = vec![ (span, "".to_string()), ( Span::new(asm_end, asm_end, sp.ctxt()), ", options(att_syntax)".to_string(), ), ]; err.multipart_suggestion( "remove the assembler directive and replace it with options(att_syntax)", suggestions, Applicability::MachineApplicable, ); err.emit(); } } ast::LlvmAsmDialect::Att => { if let Some(span) = check_syntax_directive(snippet, ".att_syntax") { let span = template_span.from_inner(span); let mut err = ecx.struct_span_err(span, "att syntax is the default syntax on this target, and trying to use this directive may cause issues"); err.span_suggestion( span, "remove this assembler directive", "".to_string(), Applicability::MachineApplicable, ); err.emit(); } // Use of .intel_syntax is ignored } } } </ins> let mut parser = parse::Parser::new( template_str, str_style,

Discussion:
People used to gcc/clang inline assembly may try using the or directives directly in the assembly string, which can cause issues. Ideally, we should detect attempts to use those directives. Attempting to use should generate an error stating that that's the default. Attempting to use should generate an error and point to the option, ideally with a rustfix-applicable suggestion. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Is anyone currently working on this? I would like to do it if not.
Not to my knowledge, no.
claim
Change:
<ins> #[deny(improper_ctypes_definitions)] // It's an improper ctype (a slice) arg in an extern "C" fnptr. pub type F = extern "C" fn(&[u8]); //~^ ERROR: `extern` fn uses type `[u8]`, which is not FFI-safe fn main() {} </ins>

Discussion:
I tried this code: I expected to see this happen: should trigger for this definition. Instead, this happened: It is not linted.
Change:
<ins> // Copyright 2016 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. // Regression test for #35546. Check that we are able to codegen // this. Before we had problems because of the drop glue signature // around dropping a trait object (specifically, when dropping the // `value` field of `Node<Send>`). struct Node<T: ?Sized + Send> { next: Option<Box<Node<Send>>>, value: T, } fn clear(head: &mut Option<Box<Node<Send>>>) { match head.take() { Some(node) => *head = node.next, None => (), } } fn main() {} </ins>

Discussion:
The following successfully typechecks on , but generates an LLVM assertion failure: Error: Note that replacing with (and making mutable) allows compilation to succeed.
First occurs in nightly-2016-08-03 which turns on mir by default, does not occur on nightly-2016-08-03 with -Z orbit=off.
Using this was introduced between and ().
Problem seems to be that we call the with a fat pointer as 2 arguments, but it expects a pointer to a tuple.
I have a fix for this, running the full locally now to see if I broke anything else on the way.
Change:
let enum_did = self.parent_def_id(did).unwrap(); self.lookup_adt_def(enum_did).variant_with_id(did) } <del> Def::Struct(did) | Def::StructCtor(did, ..) | Def::Union(did) => { </del> <ins> Def::Struct(did) | Def::Union(did) => { self.lookup_adt_def(did).struct_variant() } Def::StructCtor(ctor_did, ..) => { let did = self.parent_def_id(ctor_did).expect("struct ctor has no parent"); </ins> self.lookup_adt_def(did).struct_variant() } _ => bug!("expect_variant_def used with unexpected def {:?}", def)

Discussion:
I was trying an pattern match for a nullary constructor like this: but the compiler choked on the pattern match in an unexpected way. The fact that it's qualified does not seem to matter. See minimal repro below. I tried this code: I expected to see this happen: An plain, ordinary, not-scary type error. Instead, this happened: : Backtrace:
Works fine on 1.11.
Affects beta as well. Requires the type on the lhs to come from an extern crate. This is fixed on ( still fails, ) I suspect this was fixed by (although I may be wrong).
Originally introduced between and () The most likely cause is , I think.
cc
This happens when gets struct constructor as an argument (as opposed to of the struct itself) + it's the first time this struct is decoded. doesn't fix this issue, only masks it, it still can be reproduced with tuple struct patterns. How to fix this: add something like this at the beginning of : I have no idea how and can be implemented, need to investigate how new metadata works.
Fix for beta is in
Nice job
Change:
LL | use r#extern::foo; |     ^^^^^^^^ <del> error: aborting due to previous error </del> <ins> error[E0432]: unresolved import `r#extern` --> $DIR/keyword-extern-as-identifier-use.rs:1:5 | LL | use extern::foo; |     ^^^^^^ maybe a missing crate `r#extern`? error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0432`. </ins>

Discussion:
Example: Found by crater run (https://crater-) when visibility resolution switched to a different algorithm (early resolution), which doesn't have this problem.
This is a regression from Rust 1.33.
Diagnostic improvements strike again:
Fixed in
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. use std::collections::HashMap; use std::path::{Path, PathBuf}; fn main() { let m: HashMap<PathBuf, ()> = HashMap::new(); let k = Path::new("foo"); println!("{:?}", m.get(k)); } </ins>

Discussion:
Fedora 21 x86_64, rustc 1.0.0-nightly ( 2015-03-22) (built 2015-03-23). I hit an assertion when compiling cuviper/rust-git-fs I haven't tried to reduce it yet. Stack trace from coredumpctl:
I narrowed this down to my , where a is indexed by a . I can reproduce the crash with this smaller example: If I convert to a first, then all is fine.
Another example is:
Does not seem to affect beta or nightly. Marking as E-needstest
I'll add regression tests for these examples right now
Change:
db.span_note(glob_reexport_span, format!("the name `{}` in the {} namespace is supposed to be publicly re-exported here", name, namespace)); db.span_note(private_item_span, "but the private item here shadows it".to_owned()); } <ins> BuiltinLintDiagnostics::UnusedQualifications { path_span, unqualified_path } => { db.span_suggestion_verbose( path_span, "replace it with the unqualified path", unqualified_path, Applicability::MachineApplicable ); } </ins> } // Rewrap `db`, and pass control to the user. decorate(db)

Discussion:
In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .
Change:
Ok(self.mk_expr(blk.span, ExprKind::Block(blk, opt_label), attrs)) } <ins> /// Parse a block which takes no attributes and has no label fn parse_simple_block(&mut self) -> PResult<'a, P<Expr>> { let blk = self.parse_block()?; Ok(self.mk_expr(blk.span, ExprKind::Block(blk, None), AttrVec::new())) } </ins> /// Recover on an explicitly quantified closure expression, e.g., `for<'a> |x: &'a u8| *x + 1`. fn recover_quantified_closure_expr(&mut self, attrs: AttrVec) -> PResult<'a, P<Expr>> { let lo = self.token.span;

Discussion:
The error here is if is missing in else if but compiler reports: error:
already points out at the place where the should be, even if it doesn't suggest it:
: I still wish the parser to detect that the code immediately following is a binary operation followed by a block, so that we can instead emit
CC in case you might be interested in looking at the parser :)
this seems like a neat fix, i'll take a stab at it
Change:
<ins> error[E0277]: the size for values of type `[u8]` cannot be known at compilation time --> $DIR/suggest-maybe-sized-bound.rs:8:12 | LL |         a: StructA<isize, [u8]>, |            ^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `[u8]` note: required by an implicit `Sized` bound in `StructA` --> $DIR/suggest-maybe-sized-bound.rs:3:23 | LL |     struct StructA<A, B = A> { |                       ^^^^^ required by the implicit `Sized` requirement on this type parameter in `StructA` help: consider relaxing the implicit `Sized` restriction | LL |     struct StructA<A, B: ?Sized = A> { |                        ++++++++ error[E0277]: the size for values of type `[u8]` cannot be known at compilation time --> $DIR/suggest-maybe-sized-bound.rs:17:21 | LL |         type P<X> = [u8]; |                     ^^^^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `[u8]` note: required by a bound in `Trait::P` --> $DIR/suggest-maybe-sized-bound.rs:13:9 | LL |         type P<X>; |         ^^^^^^^^^^ required by this bound in `Trait::P` help: consider relaxing the implicit `Sized` restriction | LL |         type P<X>: ?Sized; |                  ++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
No response No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Another variant of this error I came up with using stable Edit Just tested on stable and . Both produced the same output.
claim
This is only tangentially related but just to give more context to anyone stumbling upon this issue: The diagnostic highlighting the entire path instead of only the type argument is tracked in .
Change:
should_panic: testing::ShouldPanic::No, }, testfn: testing::DynTestFn(box move |()| { <ins> let panic = io::set_panic(None); let print = io::set_print(None); </ins> match { rustc_driver::in_rustc_thread(move || { <ins> io::set_panic(panic); io::set_print(print); </ins> runtest(&test, &cratename, cfgs,

Discussion:
I've noticed this recently on the Travis/AppVeyor logs, but I haven't tracked it down yet to see what caused it.
Appears caused by perhaps caused by
ummmmmmmmm perhaps..... the tests are not failing though? Do you have a link to an example?
Oh right sorry I meant only that output is being generated, not that tests are failing. Most of the tests expect a failure which is the reason so many errors are printed. An example is here (https://travis-) from the logs of that PR (how nifty I can check that out!). You should be able to reproduce this locally as well via
Change:
tests whose names contain the filter are run. By default, all tests are run in parallel. This can be altered with the <del> RUST_TEST_THREADS environment variable when running tests (set it to 1). </del> <ins> --test-threads flag or the RUST_TEST_THREADS environment variable when running tests (set it to 1). </ins> All tests have their standard output and standard error captured by default. This can be overridden with the --nocapture flag or setting RUST_TEST_NOCAPTURE

Discussion:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.