jiebi/CodeConvo huggingface dataset:
Change:
<!-- 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 --
cc :smile:
This really should fail before rustdoc gets to it, unless rustdoc has a representation :thinking:
An (the?) interesting bit here is that it's a very recent regression, for instance does not produce an ICE:
claim
This regressed in cc
Hmm I don't know how that caused it.

Discussion:
} TyKind::BareFn(barefn) => BareFunction(Box::new(clean_bare_fn_ty(barefn, cx))), // Rustdoc handles `TyKind::Err`s by turning them into `Type::Infer`s. <del> TyKind::Infer | TyKind::Err => Infer, TyKind::Typeof(..) => panic!("unimplemented type {:?}", ty.kind), </del> <ins> TyKind::Infer | TyKind::Err | TyKind::Typeof(..) => Infer, </ins> } }

<ins> struct Struct { y: (typeof("hey"),), //~^ `typeof` is a reserved keyword but unimplemented } </ins>

<ins> error[E0516]: `typeof` is a reserved keyword but unimplemented --> $DIR/issue-102986.rs:2:9 | LL |     y: (typeof("hey"),), |         ^^^^^^^^^^^^^ reserved keyword | help: consider replacing `typeof(...)` with an actual type | LL |     y: (&'static str,), |         ~~~~~~~~~~~~ error: aborting due to previous error For more information about this error, try `rustc --explain E0516`. </ins>
Change:
Found with The attribute applies to The was initially lexed as part of a token This seems to be exactly the case described by the : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Do you have any suggestion for this case? The code path is going like this: Parser eat the first one of '' at here and set : fall pass at here: So this assertion is failed: The result is: and is true. Seems the assertion missed this scenario, do we need to add a TrailingToken::Gt ?
The assertion I wrote is overly conservative - it really just needs to check that we don't simultaneously break a token and 'really' capture a trailing token. Specifically, we only need to panic if we actually incremented in the match block. I think the simplest fix would be to add a variable, which gets set to in the parts of the block that increment . The assertion can then be changed to breaklasttoken

Discussion:
let cursor_snapshot_next_calls = cursor_snapshot.num_next_calls; let mut end_pos = self.token_cursor.num_next_calls; <ins> let mut captured_trailing = false; </ins> // Capture a trailing token if requested by the callback 'f' match trailing { TrailingToken::None => {} <ins> TrailingToken::Gt => { assert_eq!(self.token.kind, token::Gt); } </ins> TrailingToken::Semi => { assert_eq!(self.token.kind, token::Semi); end_pos += 1; <ins> captured_trailing = true; </ins> } TrailingToken::MaybeComma => { if self.token.kind == token::Comma { end_pos += 1; <ins> captured_trailing = true; </ins> } } }

// was not actually bumped past it. When the `LazyAttrTokenStream` gets converted // into an `AttrTokenStream`, we will create the proper token. if self.token_cursor.break_last_token { <del> assert_eq!( trailing, TrailingToken::None, "Cannot set `break_last_token` and have trailing token" ); </del> <ins> assert!(!captured_trailing, "Cannot set break_last_token and have trailing token"); </ins> end_pos += 1; }

&& this.token.kind == token::Semi { TrailingToken::Semi <ins> } else if this.token.kind == token::Gt { TrailingToken::Gt </ins> } else { // FIXME - pass this through from the place where we know // we need a comma, rather than assuming that `#[attr] expr,`

pub enum TrailingToken { None, Semi, <ins> Gt, </ins> /// If the trailing token is a comma, then capture it /// Otherwise, ignore the trailing token MaybeComma,

<ins> fn main() { x::<#[a]y::<z>> //~^ ERROR invalid const generic expression //~| ERROR cannot find value `x` in this scope } </ins>

<ins> error: invalid const generic expression --> $DIR/issue-103143.rs:2:13 | LL |     x::<#[a]y::<z>> |             ^^^^^^ | help: expressions must be enclosed in braces to be used as const generic arguments | LL |     x::<#[a]{ y::<z> }> |             +        + error[E0425]: cannot find value `x` in this scope --> $DIR/issue-103143.rs:2:5 | LL |     x::<#[a]y::<z>> |     ^ not found in this scope error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0425`. </ins>
Change:
with in no longer places & into but just into . Tested on Linux. . label T-infra A-bootstrap A-contributor-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm not convinced the binaries in are actually the newly compiled binaries; I think they may just never be copied from into a sysroot.
I am not familiar enough with the bootstrap process to be able to confirm or dispute this. As far as I'm concerned, I've relinked my toolchain to and everything appears to work flawlessly.
can you post the output of and ?
yeah that looks like it's not actually reflecting your changes, just using the latest nightly unmodified If it were working properly it would say -dev
Hmm, that can't be. I am currently working on fixing and modifications to the rustdoc source code are indeed properly reflected in the compiled binaries. Maybe the version string is just wrong but my local changes are picked up.
Actually, I have a counterquestion. Can you by chance reproduce this? Or is it just me and I'm just wondering why more people haven't stumbled upon this issue.
claim
cc

Discussion:
fn run(self, builder: &Builder<'_>) -> Interned<PathBuf> { let compiler = self.compiler; let host_dir = builder.out.join(&compiler.host.triple); <del> let sysroot = if compiler.stage == 0 { host_dir.join("stage0-sysroot") } else if builder.download_rustc() { host_dir.join("ci-rustc-sysroot") } else { host_dir.join(format!("stage{}", compiler.stage)) </del> <ins> let sysroot_dir = |stage| { if stage == 0 { host_dir.join("stage0-sysroot") } else if builder.download_rustc() && compiler.stage != builder.top_stage { host_dir.join("ci-rustc-sysroot") } else { host_dir.join(format!("stage{}", stage)) } </ins> }; <ins> let sysroot = sysroot_dir(compiler.stage); </ins> let _ = fs::remove_dir_all(&sysroot); t!(fs::create_dir_all(&sysroot));

"Cross-compiling is not yet supported with `download-rustc`", ); <del> // #102002, cleanup stage1 and stage0-sysroot folders when using download-rustc so people don't use old versions of the toolchain by accident. let _ = fs::remove_dir_all(host_dir.join("stage1")); let _ = fs::remove_dir_all(host_dir.join("stage0-sysroot")); </del> <ins> // #102002, cleanup old toolchain folders when using download-rustc so people don't use them by accident. for stage in 0..=2 { if stage != compiler.stage { let dir = sysroot_dir(stage); if !dir.ends_with("ci-rustc-sysroot") { let _ = fs::remove_dir_all(dir); } } } </ins> // Copy the compiler into the correct sysroot. let ci_rustc_dir =
Change:
Given the following code (): The current output is: This suggestion is on the right track, but unfortunately it introduces a parse error. It should be: This suggestion is in . It suggests adding around the type because the type is a slice, but I already have in my program (and the span doesn't include the existing ). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

Discussion:
| ty::Str | ty::Projection(_) | ty::Param(_) => format!("{deref_ty}"), <ins> // we need to test something like  <&[_]>::len // and Vec::function(); // <&[_]>::len doesn't need an extra "<>" between // but for Adt type like Vec::function() // we would suggest <[_]>::function(); _ if self.tcx.sess.source_map().span_wrapped_by_angle_bracket(ty.span)  => format!("{deref_ty}"), </ins> _ => format!("<{deref_ty}>"), }; err.span_suggestion_verbose(

} } <ins> /// Given a 'Span', tries to tell if the next character is '>' /// and the previous charactoer is '<' after skipping white space /// return true if wrapped by '<>' pub fn span_wrapped_by_angle_bracket(&self, span: Span) -> bool { self.span_to_source(span, |src, start_index, end_index| { if src.get(start_index..end_index).is_none() { return Ok(false); } // test the right side to match '>' after skipping white space let end_src = &src[end_index..]; let mut i = 0; while let Some(cc) = end_src.chars().nth(i) { if cc == ' ' { i = i + 1; } else if cc == '>' { // found > in the right; break; } else { // failed to find '>' return false immediately return Ok(false); } } // test the left side to match '<' after skipping white space i = start_index; let start_src = &src[0..start_index]; while let Some(cc) = start_src.chars().nth(i) { if cc == ' ' { if i == 0 { return Ok(false); } i = i - 1; } else if cc == '<' { // found < in the left break; } else { // failed to find '<' return false immediately return Ok(false); } } return Ok(true); }) .map_or(false, |is_accessible| is_accessible) } </ins> /// Given a `Span`, tries to get a shorter span ending just after the first occurrence of `char` /// `c`. pub fn span_through_char(&self, sp: Span, c: char) -> Span {

<ins> fn main() { let iter_fun = <&[u32]>::iter; //~^ ERROR no function or associated item named `iter` found for reference `&[u32]` in the current scope [E0599] //~| function or associated item not found in `&[u32]` //~| HELP the function `iter` is implemented on `[u32]` for item in iter_fun(&[1,1]) { let x: &u32 = item; assert_eq!(x, &1); } } </ins>

<ins> error[E0599]: no function or associated item named `iter` found for reference `&[u32]` in the current scope --> $DIR/issue-103271.rs:2:30 | LL |     let iter_fun = <&[u32]>::iter; |                              ^^^^ function or associated item not found in `&[u32]` | help: the function `iter` is implemented on `[u32]` | LL |     let iter_fun = <[u32]>::iter; |                     ~~~~~ error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>
Change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --I found this issue when I was compiling one of my large projects, and was able to track it down to the code below. Unfortunately, I haven't been able to reproduce the issue on any other machines other than this one (which is running Ubuntu 20.02.4 on Oracle Cloud, if that matters). The error only seems to happen in release mode in nightly. <!-- 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. --: </p</details
label +A-LLVM
I can reproduce this via .
Reduced:
Upstream issue:

Discussion:
[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/15.0-2022-08-09 </del> <ins> branch = rustc/15.0-2022-12-07 </ins> [submodule "src/doc/embedded-book"] path = src/doc/embedded-book url = https://github.com/rust-embedded/book.git

<del> Subproject commit a1232c451fc27173f8718e05d174b2503ca0b607 </del> <ins> Subproject commit 3dfd4d93fa013e1c0578d3ceac5c8f4ebba4b6ec </ins>
Change:
Run on this and get an ICE. Note that documenting itself does not panic, and that the is necessary. <!-- 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. --: Also reproduces on Linux (GitHub Actions) with the same nightly version. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +T-rustdoc -T-compiler
It looks like this started after commit . () I was able to create a MCVE: <details<summaryBacktrace:</summary</details
cc
Further minimized: The issue disappears if the private is removed. Looks like some logic in rustdoc is over-eager to pull in stuff through private imports, links in 's methods are not visible in the generated documentation and shouldn't be resolved at all.
--are responsible for including the trait into the rustdoc's crate representation, still unclear why.
Fixed in

Discussion:
PathSegment, Primitive, PrimitiveType, Type, TypeBinding, Visibility, }; use crate::core::DocContext; <del> use crate::formats::item_type::ItemType; </del> use rustc_ast as ast; use rustc_ast::tokenstream::TokenTree;

return did; } inline::record_extern_fqn(cx, did, kind); <del> if let ItemType::Trait = kind { inline::record_extern_trait(cx, did); } </del> did }

<ins> pub trait Trait { /// [`u8::clone`] fn method(); } </ins>

<ins> // The `Trait` is not pulled into the crate resulting in doc links in its methods being resolved. // aux-build:issue-103463-aux.rs extern crate issue_103463_aux; use issue_103463_aux::Trait; fn main() {} </ins>
Change:
When bootstrap updates a submodule, it performs a hard reset, discarding all local changes: This was a nasty surprise when I was editing my local , and then did a and . Fortunately, I only had some extra debugging prints , but there was no indication that my local changes would be overwritten. We should require explicit confirmation before potentially deleting local changes like this. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
There is an option in : Automatic submodule handling can still be disabled with . We'd better get confirmation if there is no explicit config parameter get from ?
This has been a frequent source of surprises for me as well going back all the way to the addition of . More generally I feel it is important that we figure out what the out-of-the-box experience is tailored for – the developers or people building rustc for distribution. Today this is a mixed bag.
I think a simple fix would be to use git stash + git apply to save changes before doing a hard reset; if that causes issues for some reason, we can remove all the flags so that we don't overwrite local changes and give a hard error instead.
Can I work on this issue? Though I need Some guidance I am new to the project
first, reproduce the original issue so you can be sure your changes are having an effect. Then modify the git commands linked in the original post () to add before and after. If that saves your changes then your work is done and you can open a PR; otherwise you'll have to do some experimenting with git to see what works.
claim
That's what I have done
Maybe a Zulip thread is a better place to show your result and receive more feedback on the solution
I think will restore the prvious local changes, so if we want to get previous changes, it should at the ending.
Yeah! It was a mistake thanks for pointing out
I have done the intended changes and opened a PR . Can someone please review it?

Discussion:
if !update(true).status().map_or(false, |status| status.success()) { self.run(&mut update(false)); } <ins> self.run(Command::new("git").args(&["stash", "push"]).current_dir(&absolute_path)); </ins> self.run(Command::new("git").args(&["reset", "-q", "--hard"]).current_dir(&absolute_path)); <del> self.run(Command::new("git").args(&["clean", "-qdfx"]).current_dir(absolute_path)); </del> <ins> self.run(Command::new("git").args(&["clean", "-qdfx"]).current_dir(&absolute_path)); self.run(Command::new("git").args(&["stash", "pop"]).current_dir(absolute_path)); </ins> } /// If any submodule has been initialized already, sync it unconditionally.
Change:
Not sure if we have a test for the following and rust #![feature(markertraitattr)] #[marker] trait Marker {} impl Marker for &' () {} impl Marker for &' () {} If not, we need to add them, since they would be important for special casing during canonicalization. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I can help add this test if needed. (Did not rustbot claim so as to not remove lcnr from assignee)
Sure :) would help out if nothing else
assign Rageking8
Error: Parsing assign command in failed: ...' Rageking8' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
assign
label +F-markertraitattr In case this needs to be indexed in the future.

Discussion:
<ins> // check-pass #![feature(marker_trait_attr)] #[marker] trait Marker {} impl Marker for &'static () {} impl Marker for &'static () {} fn main() {} </ins>

<ins> #![feature(marker_trait_attr)] #[marker] trait Marker {} impl Marker for &'_ () {} //~ ERROR type annotations needed impl Marker for &'_ () {} //~ ERROR type annotations needed fn main() {} </ins>

<ins> error[E0283]: type annotations needed: cannot satisfy `&(): Marker` --> $DIR/overlap-marker-trait-with-underscore-lifetime.rs:6:6 | LL | impl Marker for &'_ () {} |      ^^^^^^ | note: multiple `impl`s satisfying `&(): Marker` found --> $DIR/overlap-marker-trait-with-underscore-lifetime.rs:6:1 | LL | impl Marker for &'_ () {} | ^^^^^^^^^^^^^^^^^^^^^^ LL | impl Marker for &'_ () {} | ^^^^^^^^^^^^^^^^^^^^^^ error[E0283]: type annotations needed: cannot satisfy `&(): Marker` --> $DIR/overlap-marker-trait-with-underscore-lifetime.rs:7:6 | LL | impl Marker for &'_ () {} |      ^^^^^^ | note: multiple `impl`s satisfying `&(): Marker` found --> $DIR/overlap-marker-trait-with-underscore-lifetime.rs:6:1 | LL | impl Marker for &'_ () {} | ^^^^^^^^^^^^^^^^^^^^^^ LL | impl Marker for &'_ () {} | ^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0283`. </ins>

use std::fmt::{Debug, Display}; <del> #[marker] trait Marker {} </del> <ins> #[marker] trait Marker {} </ins> impl<T: Debug> Marker for T {} impl<T: Display> Marker for T {}

error[E0277]: the trait bound `NotDebugOrDisplay: Marker` is not satisfied <del> --> $DIR/overlap-marker-trait.rs:27:17 </del> <ins> --> $DIR/overlap-marker-trait.rs:28:17 </ins> | LL |     is_marker::<NotDebugOrDisplay>(); |                 ^^^^^^^^^^^^^^^^^ the trait `Marker` is not implemented for `NotDebugOrDisplay` | note: required by a bound in `is_marker` <del> --> $DIR/overlap-marker-trait.rs:15:17 </del> <ins> --> $DIR/overlap-marker-trait.rs:16:17 </ins> | LL | fn is_marker<T: Marker>() { } |                 ^^^^^^ required by this bound in `is_marker`

use std::fmt::{Debug, Display}; <del> #[marker] trait MyMarker {} </del> <ins> #[marker] trait MyMarker {} </ins> impl<T: Debug> MyMarker for T {} impl<T: Display> MyMarker for T {}
Change:
Valid according to stable (1.64.0), but ICEs beta (1.65.0-beta.4) and : Reduced from a mutation of Two ICEs: <details<summary<strongFull output with both backtraces</strong</summary<p</p</details: Bisected with <a href=''cargo-bisect-rustc</aon x8664-apple-darwin: searched nightlies: from nightly-2022-08-23 to nightly-2022-10-26 regressed nightly: nightly-2022-08-31 searched commit range: regressed commit: (rollup) Among the commits in the rollup, my guess is (CC It the function (frame 19 on the first stack). It with some similarities: an unconditionally recursive function with in return position. label +regression-from-stable-to-beta +A-impl-trait
yup, ez fix incoming

Discussion:
(&ty::Infer(ty::TyVar(vid)), _) => self.relate_ty_var((vid, b)), (&ty::Opaque(a_def_id, _), &ty::Opaque(b_def_id, _)) if a_def_id == b_def_id => { <del> infcx.commit_if_ok(|_| infcx.super_combine_tys(self, a, b)).or_else(|err| { </del> <ins> infcx.super_combine_tys(self, a, b).or_else(|err| { </ins> self.tcx().sess.delay_span_bug( self.delegate.span(), "failure to relate an opaque to itself should result in an error later on",

<ins> // check-pass trait T {} fn wrap(x: impl T) -> impl T { //~^ WARN function cannot return without recursing wrap(wrap(x)) } fn main() {} </ins>

<ins> warning: function cannot return without recursing --> $DIR/issue-103599.rs:5:1 | LL | fn wrap(x: impl T) -> impl T { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot return without recursing LL | LL |     wrap(wrap(x)) |          ------- recursive call site | = help: a `loop` may express intention better if this is on purpose = note: `#[warn(unconditional_recursion)]` on by default warning: 1 warning emitted </ins>
Change:
rustc crashes on the following input, found by :
searched nightlies: from nightly-2022-02-10 to nightly-2022-10-26 regressed nightly: nightly-2022-08-13 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This regressed in , specifically in . cc
Minimized:
This no longer ICEs, afaict.
According to , this got fixed in one of these commits: found 7 bors merge commits in the specified range commit[0] 2023-01-08: Auto merge of - GuillaumeGomez:rustdoc-gui-retry-mechanism, r=Mark-Simulacrum commit[1] 2023-01-08: Auto merge of - geeklint:loosenweakdebug_bound, r=dtolnay commit[2] 2023-01-09: Auto merge of - compiler-errors:rollup-emcj0o3, r=compiler-errors commit[3] 2023-01-09: Auto merge of - compiler-errors:better-spans-on-bad-tys, r=lcnr commit[4] 2023-01-09: Auto merge of - saethlin:propagate-operands, r=oli-obk commit[5] 2023-01-09: Auto merge of - aliemjay:astconv-normalize, r=lcnr commit[6] 2023-01-09: Auto merge of - fee1-dead-contrib:rollup-ticvmsd, r=fee1-dead ERROR: no CI builds available between and within last 167 days

Discussion:
<ins> trait FromResidual<R = <Self as Try>::Residual> { fn from_residual(residual: R) -> Self; } trait Try { type Residual; } fn w<'a, T: 'a, F: Fn(&'a T)>() { let b: &dyn FromResidual = &(); //~^ ERROR: the trait `FromResidual` cannot be made into an object //~| ERROR: the trait `FromResidual` cannot be made into an object } fn main() {} </ins>

<ins> error[E0038]: the trait `FromResidual` cannot be made into an object --> $DIR/canonicalize-fresh-infer-vars-issue-103626.rs:10:17 | LL |     let b: &dyn FromResidual = &(); |                 ^^^^^^^^^^^^ | = note: it cannot use `Self` as a type parameter in a supertrait or `where`-clause error[E0038]: the trait `FromResidual` cannot be made into an object --> $DIR/canonicalize-fresh-infer-vars-issue-103626.rs:10:12 | LL |     let b: &dyn FromResidual = &(); |            ^^^^^^^^^^^^^^^^^ `FromResidual` cannot be made into an object | note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety> --> $DIR/canonicalize-fresh-infer-vars-issue-103626.rs:2:8 | LL | trait FromResidual<R = <Self as Try>::Residual> { |       ------------ this trait cannot be made into an object... LL |     fn from_residual(residual: R) -> Self; |        ^^^^^^^^^^^^^ ...because associated function `from_residual` has no `self` parameter help: consider turning `from_residual` into a method by giving it a `&self` argument | LL |     fn from_residual(&self, residual: R) -> Self; |                      ++++++ help: alternatively, consider constraining `from_residual` so it does not apply to trait objects | LL |     fn from_residual(residual: R) -> Self where Self: Sized; |                                           +++++++++++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0038`. </ins>