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
This regressed in , which is a rollup. Luckily is the only real candidate though. The panic that gets called is this one: From a quick scan of a result gets dropped here : cc searched nightlies: from nightly-2021-05-07 to nightly-2021-05-29 regressed nightly: nightly-2021-05-09 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
Mhh, I don't even remember why I this call to in the first place, maybe to consume the fn body and get fewer/cleaner errors? Should have a comment... Anyway fixing this should be easy, we can (or ) the error, or remove the call to .

Discussion:
self.sess.gated_spans.gate(sym::unnamed_fields, lo); } else { let err = if self.check_fn_front_matter(false) { <del> let _ = self.parse_fn(&mut Vec::new(), |_| true, lo); </del> <ins> // We use `parse_fn` to get a span for the function if let Err(mut db) = self.parse_fn(&mut Vec::new(), |_| true, lo) { db.delay_as_bug(); } </ins> let mut err = self.struct_span_err( lo.to(self.prev_token.span), &format!("functions are not allowed in {} definitions", adt_ty),

<ins> // Regression test for #85794 struct Baz { inner : dyn fn () //~^ ERROR expected `,`, or `}`, found keyword `fn` //~| ERROR functions are not allowed in struct definitions //~| ERROR cannot find type `dyn` in this scope } fn main() {} </ins>

<ins> error: expected `,`, or `}`, found keyword `fn` --> $DIR/fn-field-parse-error-ice.rs:4:16 | LL |     inner : dyn fn () |                ^ help: try adding a comma: `,` error: functions are not allowed in struct definitions --> $DIR/fn-field-parse-error-ice.rs:4:17 | LL |     inner : dyn fn () |                 ^^ | = help: unlike in C++, Java, and C#, functions are declared in `impl` blocks = help: see https://doc.rust-lang.org/book/ch05-03-method-syntax.html for more information error[E0412]: cannot find type `dyn` in this scope --> $DIR/fn-field-parse-error-ice.rs:4:13 | LL |     inner : dyn fn () |             ^^^ not found in this scope error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0412`. </ins>
Change:
(playground) label T-libs-impl, A-collections <hrCaused by violation of safety invariant as documented in yet implementation does I’m not sure where the field is really used at all, so maybe it can be replaced by a marker , similar to ’s implementation.
Assigning according to the and removing I-prioritize. modify labels -I-prioritize +P-critical
Good catch! Iterator debug implementations seem to be woefully under-audited in terms of soundness problems (this is such issue).
maybe you can help me out with how to run miri while hacking (a question that came up for the PR fixing this: ). I have no trouble compiling or testing a modified with , or linking a toolchain for usage (so that or are working) so that I can play around with it in a crate, but I don’t know how to run on such a local crate depending-on/using a modified .
Miri uses xargo for sysroot compilation, so setting will tell Miri which standard library to use. (It must be set to the folder in a rustc checkout.) You can then use a standard Miri, no rustup toolchain linking is required.
Oh, also, if you want to run the alloc/core test suites in Miri, see

Discussion:
#[stable(feature = "collection_debug", since = "1.17.0")] impl<T: fmt::Debug> fmt::Debug for Iter<'_, T> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { <del> f.debug_tuple("Iter").field(&self.len).finish() </del> <ins> f.debug_tuple("Iter") .field(&*mem::ManuallyDrop::new(LinkedList { head: self.head, tail: self.tail, len: self.len, marker: PhantomData, })) .field(&self.len) .finish() </ins> } }

/// documentation for more. #[stable(feature = "rust1", since = "1.0.0")] pub struct IterMut<'a, T: 'a> { <del> // We do *not* exclusively own the entire list here, references to node's `element` // have been handed out by the iterator! So be careful when using this; the methods // called must be aware that there can be aliasing pointers to `element`. list: &'a mut LinkedList<T>, </del> head: Option<NonNull<Node<T>>>, tail: Option<NonNull<Node<T>>>, len: usize, <ins> marker: PhantomData<&'a mut Node<T>>, </ins> } #[stable(feature = "collection_debug", since = "1.17.0")] impl<T: fmt::Debug> fmt::Debug for IterMut<'_, T> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { <del> f.debug_tuple("IterMut").field(&self.list).field(&self.len).finish() </del> <ins> f.debug_tuple("IterMut") .field(&*mem::ManuallyDrop::new(LinkedList { head: self.head, tail: self.tail, len: self.len, marker: PhantomData, })) .field(&self.len) .finish() </ins> } }

#[inline] #[stable(feature = "rust1", since = "1.0.0")] pub fn iter_mut(&mut self) -> IterMut<'_, T> { <del> IterMut { head: self.head, tail: self.tail, len: self.len, list: self } </del> <ins> IterMut { head: self.head, tail: self.tail, len: self.len, marker: PhantomData } </ins> } /// Provides a cursor at the front element.
Change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Input to is able to see underlying derive attributes. This is not supposed to happen as per the change in . A to remove this effect. But onwards, underlying attributes are visible again to derive and this is not mentioned in . Example code is available here: In the following code below, generates a function named which prints all derive attributes visible to it. is defined as: Ouputs a blank line: : :
cc - I believe the new behavior is the one we want, since it makes derived 'just another attribute'. If so, we should document it more clearly in the release notes.
This change was made by , but that PR was never tagged with for some reason.
Triage: dropping and as this isn't an actual regression.

Discussion:
- [Rustc now catches more cases of `pub_use_of_private_extern_crate`][80763] - [Changes in how proc macros handle whitespace may lead to panics when used with older `proc-macro-hack` versions. A `cargo update` should be sufficient to fix this in all cases.][84136] <ins> - [Turn `#[derive]` into a regular macro attribute][79078] </ins> [84136]: https://github.com/rust-lang/rust/issues/84136 [80763]: https://github.com/rust-lang/rust/pull/80763

[78429]: https://github.com/rust-lang/rust/pull/78429 [82733]: https://github.com/rust-lang/rust/pull/82733 [82594]: https://github.com/rust-lang/rust/pull/82594 <ins> [79078]: https://github.com/rust-lang/rust/pull/79078 </ins> [cargo/9181]: https://github.com/rust-lang/cargo/pull/9181 [`char::MAX`]: https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.MAX [`char::REPLACEMENT_CHARACTER`]: https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.REPLACEMENT_CHARACTER
Change:
Playground: <details<summaryOutput</summary</detailscc
Ah, yes, array lengths... this is like
Cc
This ICEs on stable: I thought we have an issue for this somewhere? Basically, array lengths (and patterns) side-step all prior checks, including stability checks, and try to evaluate this constant anyway.
Hmm
No longer ICEs since

Discussion:
<ins> const fn hey() -> usize { panic!(123); //~ ERROR argument to `panic!()` in a const context must have type `&str` } fn main() { let _: [u8; hey()] = todo!(); } </ins>

<ins> error: argument to `panic!()` in a const context must have type `&str` --> $DIR/issue-85907.rs:2:5 | LL |     panic!(123); |     ^^^^^^^^^^^ | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </ins>
Change:
This code ] produces these errors: in 1.54.0-nightly (2021-05-27 ) Note that you get one of these errors even if you , implying that the compiler first infers that is , then complains that and are different.
I suspect that this will be fixed by
label +A-associated-items +A-closures +T-compiler
Fixed in latest nightly
GATs issue triage: not blocking. Works now, just needs test.

Discussion:
<ins> // check-pass #![feature(generic_associated_types)] trait Trait { type Assoc<'a>; fn with_assoc(f: impl FnOnce(Self::Assoc<'_>)); } impl Trait for () { type Assoc<'a> = i32; fn with_assoc(f: impl FnOnce(Self::Assoc<'_>)) { f(5i32) } } fn main() {} </ins>
Change:
searched nightlies: from nightly-2021-04-19 to nightly-2021-06-01 regressed nightly: nightly-2021-05-23 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailssure , and optionally are installed. . Use commit specifically. . The bisector will use to look for whether compiling msp430 code succeeds or fails. On recent nightlies, msp430 linking using Rust will fail with something like this: When was merged, the default value for option from to . msp430 appears to have by , so is now set for msp430. If is set, Rust unconditionally to the linker options, which msp430 doesn't support. But technically, the msp430 backend does use the GNU linker. This is a bit of a bikeshed, but: I could set back to with a comment, or perhaps the logic to add the option? Does mean only "uses the GNU linker", or does it mean "uses the GNU linker plus specific options"? Thus, I'm opening an issue for possible feedback before fixing.
Thanks for the great writeup and context. cc: since author of the PR: any insights to share on this? Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Ooof, the linker errors strike again. In the short term, you could make the msp430 target explicitly set . In the longer term, we really need a better way of encoding all these linker capabilities :/ You're right, is pretty under-speced currently. Ideally I think I would instead replace it with a number of more specific flags for each specific feature we need.

Discussion:
// dependency on this specific gcc. asm_args: vec!["-mcpu=msp430".to_string()], linker: Some("msp430-elf-gcc".to_string()), <ins> linker_is_gnu: false, </ins> // There are no atomic CAS instructions available in the MSP430 // instruction set, and the LLVM backend doesn't currently support
Change:
() I would’ve expected it to say Relevant point in seems to be . label C-enhancement, T-libs <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-error-handling
claim
Wow, issues really do go fast. Best of luck, reaganmcf!

Discussion:
Some(s) => *s, None => match info.payload().downcast_ref::<String>() { Some(s) => &s[..], <del> None => "Box<Any>", </del> <ins> None => "Box<dyn Any>", </ins> }, }; let thread = thread_info::current_thread();

// run-fail <del> // error-pattern:panicked at 'Box<Any>' </del> <ins> // error-pattern:panicked at 'Box<dyn Any>' </ins> // ignore-emscripten no processes #![allow(non_fmt_panic)]

// run-fail <del> // error-pattern:panicked at 'Box<Any>' </del> <ins> // error-pattern:panicked at 'Box<dyn Any>' </ins> // ignore-emscripten no processes #![feature(box_syntax)]
Change:
: Local docs: ! But has the same issue: Probably caused by: ()
It seems like this css rule: applies to this element: !. Before () this rule wouldn't have applied because it would've been contrained by instead of .
This also had some other side-effects here: ! The search results have top/bottom margins compared to the previous styling.
The second issue was fixed in I'm checking for the first one, unless you want to send a PR?
Hmm, sorry I didn't/don't have much time to dig into this more. I couldn't think of an immediate fix for this because it kinda looked non-trivial (to me) :/
Don't worry, I'll send a fix in the next hours then.

Discussion:
border-bottom: 1px solid; } .impl, .method, <del> .type, .associatedconstant, </del> <ins> .type:not(.container-rustdoc), .associatedconstant, </ins> .associatedtype { flex-basis: 100%; font-weight: 600;

assert: (".sidebar-elems > .items > ul > li:nth-child(3)", "Enums") assert: (".sidebar-elems > .items > ul > li:nth-child(4)", "Traits") assert: (".sidebar-elems > .items > ul > li:nth-child(5)", "Functions") <del> assert: (".sidebar-elems > .items > ul > li:nth-child(6)", "Keywords") </del> <ins> assert: (".sidebar-elems > .items > ul > li:nth-child(6)", "Type Definitions") assert: (".sidebar-elems > .items > ul > li:nth-child(7)", "Keywords") </ins> assert: ("#structs + table td > a", "Foo") click: "#structs + table td > a"

#[doc(keyword = "CookieMonster")] pub mod keyword {} <ins> /// Just some type alias. pub type SomeType = u32; </ins>

<ins> goto: file://|DOC_PATH|/test_docs/type.SomeType.html assert-all: (".top-block .docblock p", {"font-weight": "400"}) </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. --Not minimal, but possibly helpful, from <!-- 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 --
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
This appears to have been caused by
claim
~A potential duplicate~
No that's a completely different error
Sorry I misread the error message, It is probably a duplicate of
Yep, that looks very similar

Discussion:
<ins> #[derive(Debug)] </ins> pub enum EntryPointType { None, MainNamed,

pub main_def: Option<MainDefinition>, } <del> #[derive(Clone, Copy)] </del> <ins> #[derive(Clone, Copy, Debug)] </ins> pub struct MainDefinition { pub res: Res<ast::NodeId>, pub is_import: bool,

use rustc_errors::struct_span_err; use rustc_hir::def_id::{DefId, CRATE_DEF_INDEX, LOCAL_CRATE}; use rustc_hir::itemlikevisit::ItemLikeVisitor; <del> use rustc_hir::{ForeignItem, HirId, ImplItem, Item, ItemKind, TraitItem, CRATE_HIR_ID}; </del> <ins> use rustc_hir::{ForeignItem, HirId, ImplItem, Item, ItemKind, Node, TraitItem, CRATE_HIR_ID}; </ins> use rustc_middle::hir::map::Map; use rustc_middle::ty::query::Providers; use rustc_middle::ty::TyCtxt;

} else if let Some((hir_id, _)) = visitor.attr_main_fn { Some((tcx.hir().local_def_id(hir_id).to_def_id(), EntryFnType::Main)) } else if let Some(def_id) = tcx.main_def.and_then(|main_def| main_def.opt_fn_def_id()) { <ins> // non-local main imports are handled below if def_id.is_local() { let hir_id = tcx.hir().local_def_id_to_hir_id(def_id.expect_local()); if matches!(tcx.hir().find(hir_id), Some(Node::ForeignItem(_))) { tcx.sess .struct_span_err( tcx.hir().span(hir_id), "the `main` function cannot be declared in an `extern` block", ) .emit(); return None; } } </ins> if tcx.main_def.unwrap().is_import && !tcx.features().imported_main { let span = tcx.main_def.unwrap().span; feature_err(

<ins> // missing and missing2 exist to make sure that the error only happens on a `main` declaration extern "C" { fn missing(); fn main(); //~^ the `main` function cannot be declared in an `extern` block fn missing2(); } </ins>

<ins> error: the `main` function cannot be declared in an `extern` block --> $DIR/extern-main-issue-86110.rs:4:5 | LL |     fn main(); |     ^^^^^^^^^^ error: aborting due to previous error </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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!

Discussion:
<del> Subproject commit 5dde0fe6de2941c9ef16bc1e9d91ecf20ac5ee8b </del> <ins> Subproject commit c8713c2f9fc1e28c90876b9ec9557d8c5729757b </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. --<!-- 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
ICE only appears since 1.52. label regression-from-stable-to-stable
Better-looking code example Bisection points to
Reading the descriptions, I’d guess most likely , cc
This is indeed caused by since we're now checking parameters unlike before. The issue is in when . The call to panics because there is no name for a param. The question I have is whether we should support params for doc aliases. I didn't find anything in the tracking issue to indicate that it was supposed to be supported, and I personally don't think it makes sense. If we decide to not support doc aliases for params, then it should be an easy change to to error when is a . cc
Doc aliases are only supported for items showing up in doc search, function parameters don't, so in this case, it should error on the doc alias attribute.
Do you want to send a fix or should I?
I'll submit a fix.
Thanks! Please ping me on it (and don't forget to add a test for it too ;) ).

Discussion:
_ => None, } } <ins> // we check the validity of params elsewhere Target::Param => return false, </ins> _ => None, } { return err_fn(meta.span(), &format!("isn't allowed on {}", err));

<del> #![crate_type="lib"] </del> <ins> #![crate_type = "lib"] </ins> pub struct Bar; pub trait Foo { type X; <del> fn foo() -> Self::X; </del> <ins> fn foo(x: u32) -> Self::X; </ins> } #[doc(alias = "foo")] //~ ERROR

impl Foo for Bar { #[doc(alias = "assoc")] //~ ERROR type X = i32; <del> fn foo() -> Self::X { </del> <ins> fn foo(#[doc(alias = "qux")] _x: u32) -> Self::X { //~^ ERROR </ins> 0 } }

<ins> error: allow, cfg, cfg_attr, deny, forbid, and warn are the only allowed built-in attributes in function parameters --> $DIR/check-doc-alias-attr-location.rs:22:12 | LL |     fn foo(#[doc(alias = "qux")] _x: u32) -> Self::X { |            ^^^^^^^^^^^^^^^^^^^^^ </ins> error: `#[doc(alias = "...")]` isn't allowed on extern block --> $DIR/check-doc-alias-attr-location.rs:9:7 |

LL |     #[doc(alias = "assoc")] |           ^^^^^^^^^^^^^^^ <del> error: aborting due to 4 previous errors </del> <ins> error: aborting due to 5 previous errors </ins>
Change:
It looks like a CSS rule is being applied incorrectly. It also looks weird if you click through to the type alias's page (). ! !
I'm not really sure, could that be slipped in ?
It turns out it was actually much more recent. The PR causing the regression was , cc searched nightlies: from nightly-2021-05-01 to nightly-2021-06-12 regressed nightly: nightly-2021-06-04 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The culprit CSS rule is here: It also caused which was fixed by .
Ah, I have missed this one. Sending a fix.
Assigning priority as in the prioritization working group. label: +P-medium -I-prioritize
The fix should be merged in less than 3 hours. ;)
I know, but we had already agreed on a priority :)
Oh I see. Thanks for taking care of that then! :)

Discussion:
# https://github.com/puppeteer/puppeteer/issues/375 # # We also specify the version in case we need to update it to go around cache limitations. <del> RUN npm install -g browser-ui-test@0.2.12 --unsafe-perm=true </del> <ins> RUN npm install -g browser-ui-test@0.2.14 --unsafe-perm=true </ins> ENV RUST_CONFIGURE_ARGS  --build=x86_64-unknown-linux-gnu 

h2, h3, h4 { border-bottom: 1px solid; } <del> .impl, .method, .type:not(.container-rustdoc), .associatedconstant, .associatedtype { </del> <ins> .impl, .impl-items .method, .impl-items .type, .impl-items .associatedconstant, .impl-items .associatedtype { </ins> flex-basis: 100%; font-weight: 600; margin-top: 16px;

<ins> goto: file://|DOC_PATH|/lib2/struct.Foo.html // This test checks that the font weight is correctly applied. assert: ("//*[@class='docblock type-decl']//a[text()='Alias']", {"font-weight": "400"}) assert: ("//*[@class='structfield small-section-header']//a[text()='Alias']", {"font-weight": "400"}) assert: ("#method.a_method > code", {"font-weight": "600"}) assert: ("#associatedtype.X > code", {"font-weight": "600"}) assert: ("#associatedconstant.Y > code", {"font-weight": "600"}) </ins>

assert: (".sidebar-elems > .crate > ul > li > a.current", "lib2") // We now go to the "foobar" function page. assert: (".sidebar-elems > .items > ul > li:nth-child(1)", "Modules") <del> assert: (".sidebar-elems > .items > ul > li:nth-child(2)", "Functions") </del> <ins> assert: (".sidebar-elems > .items > ul > li:nth-child(2)", "Structs") assert: (".sidebar-elems > .items > ul > li:nth-child(3)", "Traits") assert: (".sidebar-elems > .items > ul > li:nth-child(4)", "Functions") assert: (".sidebar-elems > .items > ul > li:nth-child(5)", "Type Definitions") </ins> assert:	("#functions + table td > a", "foobar") click: "#functions + table td > a"

} pub fn foobar() {} <ins> pub type Alias = u32; pub struct Foo { pub x: Alias, } impl Foo { pub fn a_method(&self) {} } pub trait Trait { type X; const Y: u32; } impl Trait for Foo { type X = u32; const Y: u32 = 0; } </ins>
Change:
While trying to unpin nightly (2021-03-25) to latest nightly, I have hit an internal compiler error. It emerged between 2021-03-25 and today's build. All the details are in the build log. In particular, The error seems to emerge when compiling a transitive dependency, so it is not very easy to reproduce with a minimal example. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Regressed between nightly-2021-06-08 and nightly-2021-06-09, which is , which corresponds to (which includes that touches :thinking:).
found out that the issue boils down to Does it make any sense to put on a item...??
It doesn't -- it even generates a warning:
claim

Discussion:
<del> Subproject commit e5c3af6f516311cc4b1fc017c58d83b7442cbc34 </del> <ins> Subproject commit 35af23b6a94459da538ee1479e863c7699620f84 </ins>
Change:
According to , the standalone tarball installer of stable Rust releases includes Miri. That's a bug, Miri is a nightly-only tool and should not be shipped on stable. Cc
Posted a fix at .

Discussion:
} fn run(self, builder: &Builder<'_>) -> Option<GeneratedTarball> { <ins> // This prevents rust-analyzer from being built for "dist" or "install" // on the stable/beta channels. It is a nightly-only tool and should // not be included. if !builder.build.unstable_features() { return None; } </ins> let compiler = self.compiler; let target = self.target; assert!(builder.config.extended);

} fn run(self, builder: &Builder<'_>) -> Option<GeneratedTarball> { <ins> // This prevents miri from being built for "dist" or "install" // on the stable/beta channels. It is a nightly-only tool and should // not be included. if !builder.build.unstable_features() { return None; } </ins> let compiler = self.compiler; let target = self.target; assert!(builder.config.extended);