jiebi/CodeConvo huggingface dataset:
Change:
pub trait Pattern<'a> {} <ins> impl Pattern<'_> for () {} </ins> pub trait Trait<const N: usize> {} // @has async_fn/fn.const_generics.html // @has - '//pre[@class="rust item-decl"]' 'pub async fn const_generics<const N: usize>(_: impl Trait<N>)'

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. --I tried this code: I expected the documentation for the type alias to show the method and the implementation of . Instead, the type alias does not show the method . It does however show the implementation of . ! By publicly exposing through , the documentation of on the alias is documented as I expected, but then is publicly reachable, which in my case is unwanted due to being an internal implementation detail. This also works when making the statement , which gets the docs to look like I expected them to. ! <!-- 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. --: Thanks for helping me figure out why what I was expecting wasn't happening though it looked like it should.
I think it's ok to document an impl on a reexported if the reexported item is not doc hidden. I'll send a fix in the next weeks.
Change:
<ins> error: intel syntax is the default syntax on this target, and trying to use this directive may cause issues --> $DIR/inline-syntax.rs:18:15 | LL |         asm!(".intel_syntax noprefix", "nop"); |               ^^^^^^^^^^^^^^^^^^^^^^ help: remove this assembler directive error: intel syntax is the default syntax on this target, and trying to use this directive may cause issues --> $DIR/inline-syntax.rs:20:15 | LL |         asm!(".intel_syntax aaa noprefix", "nop"); |               ^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove this assembler directive error: using the .att_syntax directive may cause issues, use the att_syntax option instead --> $DIR/inline-syntax.rs:22:15 | LL |         asm!(".att_syntax noprefix", "nop"); |               ^^^^^^^^^^^^^^^^^^^^ | help: remove the assembler directive and replace it with options(att_syntax) | LL |         asm!("", "nop", options(att_syntax)); |              --       ^^^^^^^^^^^^^^^^^^^^^ error: using the .att_syntax directive may cause issues, use the att_syntax option instead --> $DIR/inline-syntax.rs:25:15 | LL |         asm!(".att_syntax bbb noprefix", "nop"); |               ^^^^^^^^^^^^^^^^^^^^^^^^ | help: remove the assembler directive and replace it with options(att_syntax) | LL |         asm!("", "nop", options(att_syntax)); |              --       ^^^^^^^^^^^^^^^^^^^^^ error: intel syntax is the default syntax on this target, and trying to use this directive may cause issues --> $DIR/inline-syntax.rs:28:15 | LL |         asm!(".intel_syntax noprefix; nop"); |               ^^^^^^^^^^^^^^^^^^^^^^ help: remove this assembler directive error: intel syntax is the default syntax on this target, and trying to use this directive may cause issues --> $DIR/inline-syntax.rs:33:14 | LL |               .intel_syntax noprefix |  ______________^ LL | |             nop" | |_ help: remove this assembler directive error: aborting due to 6 previous errors </ins>

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:
(& &s).draw_reference(); // ... and dereferenced and borrowed <del> (&@~s).draw_reference(); </del> <ins> (&~s).draw_reference(); </ins> ~~~ Implementations may also define standalone (sometimes called "static")

Discussion:
Their continued existence in the tutorial is causing confusion over what the status of this feature is. Let all the world know that managed pointers are relegated to the dustbin of history!
It's unclear to me if the tutorial is being rewritten from scratch by Mozilla. There's not much motivation for anyone to work on it if it's just going to be thrown out.
That may be true, but if a good samaritan wanted to do just enough work to delete mentions of them from the current tutorial, it would not be unappreciated.
Hi, I am the one who asked about this initially. I have started to work on it now.
At this point I do think it's worthwhile to keep maintaining the tutorial. Even if it doesn't survive as the tutorial, it does contain a lot of information that will end up disseminated elsewhere.
Not maintaining the tutorial leads to a growing collection of inaccurate or wrong information. Removing it could give newcomers a better first-time experience of Rust.
Change:
struct MyStruct; impl Drop for MyStruct { <del> //~^ NOTE conflicting implementation is here </del> <ins> //~^ NOTE first implementation here </ins> fn drop(&mut self) { } } impl Drop for MyStruct { //~^ ERROR conflicting implementations of trait <ins> //~| NOTE conflicting implementation for `MyStruct` </ins> fn drop(&mut self) { } }

Discussion:
From: src/test/compile- Error E0119 needs a spanlabel and a spannote converted to a span_label, updating it from: To:
Grabbed this one from the list.
Change:
ty::ReVar(rid) => match self.values[rid] { VarValue::Empty(_) => r, VarValue::Value(r) => r, <del> VarValue::ErrorValue => tcx.mk_re_error_misc(), </del> <ins> VarValue::ErrorValue => tcx.lifetimes.re_static, </ins> }, _ => r, };

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. --Possibly related to ? in The error message is in building but I can't reproduce with just building that crate, which is odd. <!-- 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 --
label +E-needs-mcve
I'm pretty sure I know how to make an MCVE for this. claim
Ah, lol, it's because hasn't landed, and a recent ReError PR made it delay a bug that should've been handled more gracefully. If you build assertor with (or add ) then it ICEs similarly.
Change:
trait_ref, obligation.cause.body_id, ); <del> } else { if !have_alt_message { // Can't show anything else useful, try to find similar impls. let impl_candidates = self.find_similar_impl_candidates(trait_ref); self.report_similar_impl_candidates(impl_candidates, &mut err); } // Changing mutability doesn't make a difference to whether we have // an `Unsize` impl (Fixes ICE in #71036) if !is_unsize { self.suggest_change_mut( &obligation, &mut err, trait_ref, points_at_arg, ); } </del> <ins> } else if !have_alt_message { // Can't show anything else useful, try to find similar impls. let impl_candidates = self.find_similar_impl_candidates(trait_ref); self.report_similar_impl_candidates(impl_candidates, &mut err); } // Changing mutability doesn't make a difference to whether we have // an `Unsize` impl (Fixes ICE in #71036) if !is_unsize { self.suggest_change_mut( &obligation, &mut err, trait_ref, points_at_arg, ); </ins> } // If this error is due to `!: Trait` not implemented but `(): Trait` is

Discussion:
: We currently emit: What is likely desired instead is to use . Seen in the wild at <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // Regression test for issue #72839 // Tests that we do not overflow during trait selection after // a type error occurs use std::ops::Rem; trait Foo {} struct MyStruct<T>(T); impl<T, U> Rem<MyStruct<T>> for MyStruct<U> where MyStruct<U>: Rem<MyStruct<T>> { type Output = u8; fn rem(self, _: MyStruct<T>) -> Self::Output { panic!() } } fn main() {} fn foo() { if missing_var % 8 == 0 {} //~ ERROR cannot find } </ins>

Discussion:
Does not appear on Stable or Beta in the playground. () Errors: modify labels: +C-bug, A-diagnostics, D-verbose, E-needs-bisection, T-compiler Edit: nevermind the attempt of adding “regression-from-stable-to-nightly”, I didn’t fully read the description of that label, it doesn’t apply.
Error: Label regression-from-stable-to-nightly can only be set by Rust team members Please let know if you're having trouble with this bot.
This can be reproduced outside the playground by adding to your . I suspect that this is caused by we now continue trait selection instead of bailing out when we see an error type. I think we'll want to re-add some kind of bail-out logic, but I'm not sure where the best place would be.
I can confirm regression at modify labels to -E-needs-bisection.
(This bug leaked into beta channel while waiting for PR to land, I think.)
Removing as this have been prioritized already.
This one is already on master and beta backported so closing it as fixed in both channels.
Change:
release_debuginfo: Option<bool>, version_check: Option<bool>, static_libstdcpp: Option<bool>, <ins> targets: Option<String>, </ins> } #[derive(RustcDecodable)]

Discussion:
Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.
Change:
Ty::new_unit(self.tcx), ); } <del> if !self.consider_removing_semicolon(blk, expected_ty, err) { </del> <ins> if !self.err_ctxt().consider_removing_semicolon( blk, expected_ty, err, ) { </ins> self.err_ctxt().consider_returning_binding( blk, expected_ty,

Discussion:
The code below has superfluous semicolons in the branches of the if expression: The error message that results is: This can be confusing to beginners, who may not understand unit type. However, since the expressions and can be shown to have no side effects, the code (as is) can't be what the user intended. Could the compiler produce a more targeted error message that mentions the superfluous semicolon? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label T-compiler A-diagnostics D-newcomer-roadblock D-terse
claim
Thinking more about this, I don't think we should extend the "remove semicolon to make tail expression" suggestion to cover this case, since we don't know the expected type of at the point at which the suggestion would be made. For example, we don't make the suggestion to change to here: But that's just a guess based on my limited knowledge of type mismatch suggestions. Maybe someone else could weigh in?
Change:
<ins> // Regression test for <https://github.com/rust-lang/rust/issues/101531>, // where links where to the item who's HTML page had the item linked to. //! [`Struct::struct_field`] //! [`Enum::Variant`] //! [`Trait::AssocType`] //! [`Trait::ASSOC_CONST`] //! [`Trait::method`] // @set struct_field = "$.index[*][?(@.name=='struct_field')].id" // @set Variant = "$.index[*][?(@.name=='Variant')].id" // @set AssocType = "$.index[*][?(@.name=='AssocType')].id" // @set ASSOC_CONST = "$.index[*][?(@.name=='ASSOC_CONST')].id" // @set method = "$.index[*][?(@.name=='method')].id" // @is "$.index[*][?(@.name=='non_page')].links['`Struct::struct_field`']" $struct_field // @is "$.index[*][?(@.name=='non_page')].links['`Enum::Variant`']" $Variant // @is "$.index[*][?(@.name=='non_page')].links['`Trait::AssocType`']" $AssocType // @is "$.index[*][?(@.name=='non_page')].links['`Trait::ASSOC_CONST`']" $ASSOC_CONST // @is "$.index[*][?(@.name=='non_page')].links['`Trait::method`']" $method pub struct Struct { pub struct_field: i32, } pub enum Enum { Variant(), } pub trait Trait { const ASSOC_CONST: i32; type AssocType; fn method(); } </ins>

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. --field contains wrong IDs for some kind of items. Items for which no independent HTML is generated (link target URL is ) appear to have incorrect IDs. I tried this code: I expected to see this happen: contains the IDs of link targets Instead, this happened: contains the ID of the items containing the link targets <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: +A-rustdoc-json +T-rustdoc +A-intra-doc-links
claim
Change:
<ins> error: att syntax is the default syntax on this target, and trying to use this directive may cause issues --> $DIR/inline-syntax.rs:22:15 | LL |         asm!(".att_syntax noprefix", "nop"); |               ^^^^^^^^^^^^^^^^^^^^ help: remove this assembler directive error: att syntax is the default syntax on this target, and trying to use this directive may cause issues --> $DIR/inline-syntax.rs:25:15 | LL |         asm!(".att_syntax bbb noprefix", "nop"); |               ^^^^^^^^^^^^^^^^^^^^^^^^ help: remove this assembler directive error: aborting due to 2 previous errors </ins>

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:
0x20_u8, 0x4e_u8, 0x61_u8, 0x6d_u8]; <del> let _x = from_bytes(bb); </del> <ins> let mut error_happened = false; let _x = do cond.trap(|err| { assert_eq!(err, ~"from_bytes: input is not UTF-8; first bad byte is 255"); error_happened = true; ~"" }).in { from_bytes(bb) }; assert!(error_happened); </ins> } #[test]

Discussion:
It seems to me that returning a Result would be more appropriate than failing.
See discussion on -- the right thing to do here would be to use conditions, I think.
This should be pretty simple -- working on it.
Fixed pending
fixes.
Change:
} /// Return `a` >= `b` lexicographically (Using partial order, `Ord`) <del> pub fn ge<A: Ord, T: Iterator<A>>(mut a: T, mut b: T) -> bool { </del> <ins> pub fn ge<A: Ord, T: Iterator<A>, S: Iterator<A>>(mut a: T, mut b: S) -> bool { </ins> loop { match (a.next(), b.next()) { (None, None) => return true,

Discussion:
They're currently very restricted as they only work with a single iterator type for both arguments, so, e.g. doesn't work. It should be easy to just add another parameter for the second argument.
Change:
<ins> // needs-asm-support // only-x86_64 struct W<T: ?Sized>(Oops); //~^ ERROR cannot find type `Oops` in this scope unsafe fn test() { let j = W(()); let pointer = &j as *const _; core::arch::asm!( "nop", in("eax") pointer, ); } fn main() {} </ins>

Discussion:
Found by mutating with a <details<summary<strongFull output including backtrace</strong</summary<p</p</detailsnightly-2022-05-28: changed from no ICE to ICE "index out of bounds" Most likely for the same reason as nightly-2022-07-13: changed from ICE "index out of bounds" to ICE "assertion failed: self.istaintedbyerrors()" From something in , most likely label +A-inline-assembly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
That assertion is probably unnecessarily strict, since doesn't check that errors are emitted from other items anyways. Instead, it can probably be turned into a delayed bug or just removed altogether, since already delays a bug.
claim
Change:
gid: Option<gid_t>, saw_nul: bool, closures: Vec<Box<dyn FnMut() -> io::Result<()> + Send + Sync>>, <ins> groups: Option<Box<[gid_t]>>, </ins> stdin: Option<Stdio>, stdout: Option<Stdio>, stderr: Option<Stdio>,

Discussion:
already offers and methods to control the user identity of the child process (calling respectively). For complete control of Unix credentials, there should also be a way to call and the concept of the supplementary group list are; I would expect this not to be a portability concern.) This feature would eliminate a use of and an unsafe block (to call ) from the program I'm currently writing, which is a port to Rust of a setuid C program. For illustration, this function exists in the C version: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would be prepared to consider a PR to add .
claim
Change:
<ins> // Copyright 2014 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. // This tests that we can't modify Box<&mut T> contents while they // are borrowed. struct A { a: int } struct B<'a> { a: Box<&'a mut int> } fn borrow_in_var_from_var() { let mut x: int = 1; let y = box &mut x; let p = &y; let q = &***p; **y = 2; //~ ERROR cannot assign to `**y` because it is borrowed drop(p); drop(q); } fn borrow_in_var_from_field() { let mut x = A { a: 1 }; let y = box &mut x.a; let p = &y; let q = &***p; **y = 2; //~ ERROR cannot assign to `**y` because it is borrowed drop(p); drop(q); } fn borrow_in_field_from_var() { let mut x: int = 1; let y = B { a: box &mut x }; let p = &y.a; let q = &***p; **y.a = 2; //~ ERROR cannot assign to `**y.a` because it is borrowed drop(p); drop(q); } fn borrow_in_field_from_field() { let mut x = A { a: 1 }; let y = B { a: box &mut x.a }; let p = &y.a; let q = &***p; **y.a = 2; //~ ERROR cannot assign to `**y.a` because it is borrowed drop(p); drop(q); } fn main() { borrow_in_var_from_var(); borrow_in_var_from_field(); borrow_in_field_from_var(); borrow_in_field_from_field(); } </ins>

Discussion:
Nominating for P-backcompat-lang as a borrow check bug
cc
cc me
0 P-backcompat-lang.
Also, it doesn't fail when using instead of :
I think is actually irrelevant to the real bug here. The assignment shouldn't be allowed while exists since the immutable borrow freezes everything. It seems to still work with , so maybe the owned pointer version just got lost in the to transition.
Side note: the current Redex model correctly rejects this code (yay!).
I have a simple fix for this: I'm testing on top of a lot of other borrowck changes, but this code in particular wasn't modified. I'll add a test, try again on master, and submit a PR.
theoretically the to transition was just renaming the syntax, I believe is still represented in the compiler in exactly the same way that was. (Maybe could try this code on the last pre--removal compiler (or anything before that) to see if it was rejected then.)
I just figured we would have run into not actually freezing pointers a long time ago, but it's possible I suppose.
Change:
(_, Err(Err::UnknownLayout)) => Answer::No(Reason::DstLayoutUnknown), (Err(Err::Unspecified), _) => Answer::No(Reason::SrcIsUnspecified), (_, Err(Err::Unspecified)) => Answer::No(Reason::DstIsUnspecified), <ins> (Err(Err::SizeOverflow), _) => Answer::No(Reason::SrcSizeOverflow), (_, Err(Err::SizeOverflow)) => Answer::No(Reason::DstSizeOverflow), </ins> (Ok(src), Ok(dst)) => { MaybeTransmutableQuery { src, dst, scope, assume, context }.answer() }

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
Crashes since 1.65.0.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
use rustc_middle::{bug, span_bug}; use rustc_session::Session; use rustc_span::symbol::{kw, Ident}; <del> use rustc_span::{sym, BytePos, Span, DUMMY_SP}; </del> <ins> use rustc_span::{sym, Span, DUMMY_SP}; </ins> use rustc_trait_selection::error_reporting::infer::{FailureCode, ObligationCauseExt}; use rustc_trait_selection::infer::InferCtxtExt; use rustc_trait_selection::traits::{self, ObligationCauseCode, SelectionContext};

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' 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: 536 | Err(#[stable(feature = "rust1", since = "1.0.0")] E), [typeck] type-checking [analysis] running analysis passes on this crate --
Probably one of those cases... We should almost have an internal deny lint that bans explicit manipulations for suggestions. Possibly
Strongly agree. It's so easy to find these kinds of ICEs: simply needs to look for inside , out which ASCII character is meant to one's favorite Unicode table website that can list Confusables a Confusable whose is 1 and :boom:
For example, here's another one which I organically found while reviewing an unrelated PR: This code uses a Medium Right Parenthesis Ornament (U+2769) which is confusable with Right Parenthesis
I'll open an issue for the internal lint.