jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> let is_macro = base_span.from_expansion() && base_span.desugaring_kind().is_none(); </ins> if !self.type_ascription_suggestion(&mut err, base_span) { let mut fallback = false; if let ( PathSource::Trait(AliasPossibility::Maybe), Some(Res::Def(DefKind::Struct | DefKind::Enum | DefKind::Union, _)), <del> ) = (source, res) </del> <ins> false, ) = (source, res, is_macro) </ins> { if let Some(bounds @ [_, .., _]) = self.diagnostic_metadata.current_trait_object { fallback = true;

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. --With a procmacro, an ICE occurs when generating an block (whether for a trait or not) that has an associated type that looks like this: The type needs to be a valid (in scope) type that takes a generic parameter, with a trait/lifetime bound. Both the generic parameter and the trait/lifetime bound don't actually need to be in scope - just syntactically valid. I only found this after a typo ( instead of ); this code shouldn't compile without the ICE anyway - the trait/lifetime bound is on a concrete type. As a result, I cannot foresee a situation where valid code that should compile would fail to compile as a result of this ICE. <!-- 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. --Occurs on latest stable, beta and nightly versions. : I have also tested this on a host running , and the ICE also occurs on that machine as well. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning and removing .
Change:
<ins> // Regression test for issue #63882. type A = crate::r#break; //~ ERROR cannot find type `r#break` in module `crate` fn main() {} </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:
<code>enum</code>, <code>trait</code>, <code>type</code>, <code>macro</code>,  and <code>const</code>.", "Search functions by type signature (e.g., <code>vec -&gt; usize</code> or  <del> <code>* -&gt; vec</code>)", </del> <ins> <code>-&gt; vec</code>)", </ins> "Search multiple things at once by splitting your query with comma (e.g.,  <code>str,u8</code> or <code>String,struct:Vec,test</code>)", "You can look for items with an exact name by putting double quotes around 

Discussion:
In its help, rustdoc says I can use " -vec" to search by type signature. But when I actually run exactly that search query, rustdoc Cc
Hmm, I think it uses the syntax instead (though we've discussed switching to , which I prefer). I'll open a PR. cc
Yeah works. This looks like a fairly recent regression, .
It could be that the old query parser just ignored the . A new one was implemented recently that's strict about syntax.
Change:
<ins> // run-rustfix #![allow(dead_code)] struct U <T> { wtf: Option<Box<U<T>>>, x: T, } fn main() { U { wtf: Some(Box::new(U { //~ ERROR cannot initialize a tuple struct which contains private fields wtf: None, x: (), })), x: () }; } </ins>

Discussion:
Could someone change the bad title? I am not good for english.
Seems like more of a diagnostics issue. is a private constructor, but we're erroring out on type-checking before we realize this. The fix for this specific code is to replace with
Triage: this now has a different, yet still confusing, error:
That error is correct; but either way, the other error you get today is this, which while not ideal, is possibly the best we can do. I guess we could look for a method with a single parameter? But that seems hacky.
It is, but it is a common enough pattern and such a big enhancement in end user experience that I feel it'd be worth it to add it, specially when the ctor is not public. Then, the output should be: Similar output, but not quite the same cause in .
In order to implement this there's a bit of roadblock at the moment. The verification if a struct has a given method is done in , while this error is being emitted in . I believe the error is being bubbled up, but it would have to be delayed on its entirety to the type check step in order to verify wether exists. :-/ You can look for traits that have a given method (), but when I tried it with it returned an empty . We could provide with a generic suggestion about trying out , but I would much rather prefer if we could have some certainty that the method exists instead of potentially misleading the user.
Current output:
The error message seems pretty good... let's close this?
I still think that . Definitely low priority now given the other improvements on the error.
: We still need to look for and suggest it.
Change:
Usage: x.py <subcommand> [options] [<paths>...] Subcommands: <del> build       Compile either the compiler or libraries check       Compile either the compiler or libraries, using cargo check </del> <ins> build, b    Compile either the compiler or libraries check, c    Compile either the compiler or libraries, using cargo check </ins> clippy      Run clippy (uses rustup/cargo-installed clippy binary) fix         Run cargo fix fmt         Run rustfmt <del> test        Build and run some test suites </del> <ins> test, t     Build and run some test suites </ins> bench       Build and run some benchmarks doc         Build documentation clean       Clean out build directories dist        Build distribution artifacts install     Install distribution artifacts <del> run         Run tools contained in this repository </del> <ins> run, r      Run tools contained in this repository </ins> To learn more about a subcommand, run `./x.py <subcommand> -h`", );

Discussion:
currently supports , and a few others even though not so discoverable (). It would be good to let supports the aliases supported by , such as , and such. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // Copyright 2017 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. #![feature(rustc_attrs)] #![allow(unused)] fn f() { let x: Box<()> = Box::new(()); || { &x }; } #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>

Discussion:
This works: This does not and gives a confusing error: The error:
This also gives a confusing error: The following works:
None of these examples don't compile today, so I'm presuming this is fixed and marking E-needstest.
Can I take this issue and put this into a run-pass test?
Sounds good to me, though compile-pass would probably be sufficient - grep for .
Ok. Will do. Btw, it looks like this commit was fixed by .
Change:
<ins> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </ins>

Discussion:
When learning async/await feature I was struggling with running multiple tasks simultaneously. Loop causes compiler to crash Github Action crash output: I expected to see this happen: Error message if something goes wrong. Instead, this happened: Compiler crashed Crash happens on macOS rustc 1.40 / Linux rustc 1.40 / Linux rustc 1.39 ( github actions ) :
If you could provide an example that ICEs in e.g. the playground that would be helpful towards fixing the issue. :)
Provided example is pretty small, but it is dependent on tokio and actix-web. I do not know how to create such an example in playground, I do know know how I can replace async tokio::sync::mpsc with standard library which does not have async alternative as far as i know. I have tried to simplify code but then crash disappear. Just putting everything into one file and crash is gone, code wont compile and reasonable errors show up.
Visiting from triage.. we decided that as the first step we should reduce this reproducer to a more self-contained one.
Can repro. Will try and min.
Reduced version so far is here:
This no longer ICEs on the latest nightly.
Let's see if we can shrink further so that we can add a test. 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
I’ve reduced it quite a bit. Down to dependencies on only. Appears to need 2 crates.

I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.
Change:
<ins> use std::mem::MaybeUninit; use std::ops::Deref; pub unsafe trait Array { /// The array’s element type type Item; #[doc(hidden)] /// The smallest index type that indexes the array. type Index: Index; #[doc(hidden)] fn as_ptr(&self) -> *const Self::Item; #[doc(hidden)] fn as_mut_ptr(&mut self) -> *mut Self::Item; #[doc(hidden)] fn capacity() -> usize; } pub trait Index : PartialEq + Copy { fn to_usize(self) -> usize; fn from(usize) -> Self; } impl Index for usize { fn to_usize(self) -> usize { self } fn from(val: usize) -> Self { val } } unsafe impl<T> Array for [T; 1] { type Item = T; type Index = usize; fn as_ptr(&self) -> *const T { self as *const _ as *const _ } fn as_mut_ptr(&mut self) -> *mut T { self as *mut _ as *mut _} fn capacity() -> usize { 1 } } impl<A: Array> Deref for ArrayVec<A> { type Target = [A::Item]; #[inline] fn deref(&self) -> &[A::Item] { panic!() } } pub struct ArrayVec<A: Array> { xs: MaybeUninit<A>, len: usize, } impl<A: Array> ArrayVec<A> { pub fn new() -> ArrayVec<A> { panic!() } } fn main() { let mut buffer = ArrayVec::new(); let x = buffer.last().unwrap().0.clone(); //~^ ERROR type annotations needed //~| ERROR no field `0` on type `&_` buffer.reverse(); } </ins>

Discussion:
The compiler correctly errors about the ambiguous types, but also panics on this code:
Also reproduces on nightly. Panic happens here:
triage: P-medium. removing nomination label. reasoning: has a PR. tagging as P-medium (since it does produce useful error message before ICE'ing), and removing nomination label.
Change:
None } <ins> // Two layouts are considered for `CanBeNicheFilledButShouldnt`: //   Niche-filling: //     { u32 (4 bytes), NonZeroU8 + tag in niche (1 byte), padding (3 bytes) } //   Tagged: //     { tag (1 byte), NonZeroU8 (1 byte), padding (2 bytes), u32 (4 bytes) } // Both are the same size (due to padding), // but the tagged layout is better as the tag creates a niche with 254 invalid values, // allowing types like `Option<Option<CanBeNicheFilledButShouldnt>>` to fit into 8 bytes. pub enum CanBeNicheFilledButShouldnt { A(NonZeroU8, u32), B } pub enum AlwaysTaggedBecauseItHasNoNiche { A(u8, u32), B } </ins> pub fn main() { assert_eq!(size_of::<u8>(), 1 as usize); assert_eq!(size_of::<u32>(), 4 as usize);

Discussion:
This prints the values in comments: Note that contains strictly more opportunities for optimization, but it's optimized worse. That's because it uses a "niche-filling" layout (using in the field of for ), but the "tag" layout wouldn't be any larger, because it has enough space in bytes to fit the (byte-sized) tag, and . uses the tagged layout since it has no other choice, and ends up with free values in the byte-sized tag, but "jumps the gun" on using a pre-existing niche.
Change:
<ins> error: expected `,` --> $DIR/incorrect-placement-of-pattern-modifiers.rs:8:26 | LL |         S {ref field_name: _foo} => {} |         -                ^ |         | |         while parsing the fields for this pattern | help: the pattern modifiers belong after the `:` | LL -         S {ref field_name: _foo} => {} LL +         S {field_name: ref _foo} => {} | error: expected `,` --> $DIR/incorrect-placement-of-pattern-modifiers.rs:11:26 | LL |         S {mut field_name: _foo} => {} |         -                ^ |         | |         while parsing the fields for this pattern | help: the pattern modifiers belong after the `:` | LL -         S {mut field_name: _foo} => {} LL +         S {field_name: mut _foo} => {} | error: expected `,` --> $DIR/incorrect-placement-of-pattern-modifiers.rs:14:30 | LL |         S {ref mut field_name: _foo} => {} |         -                    ^ |         | |         while parsing the fields for this pattern | help: the pattern modifiers belong after the `:` | LL -         S {ref mut field_name: _foo} => {} LL +         S {field_name: ref mut _foo} => {} | error[E0308]: mismatched types --> $DIR/incorrect-placement-of-pattern-modifiers.rs:17:20 | LL |     let _: usize = 3u8; |            -----   ^^^ expected `usize`, found `u8` |            | |            expected due to this | help: change the type of the numeric literal from `u8` to `usize` | LL |     let _: usize = 3usize; |                     ~~~~~ error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
When changing a pattern binding from something like to something like it's easy to end up with which yields an unhelpful syntax error message (). I don't believe it's obvious why and are valid, but is not. The same holds for bindings, of course. It would be nice if rustc's parser accepted the invalid syntax and provided one of its helpful "did you mean to write ?" error messages.
Current output:
Change:
let dst = trait_ref.args.type_at(0); let src = trait_ref.args.type_at(1); let err_msg = format!("`{src}` cannot be safely transmuted into `{dst}`"); match rustc_transmute::TransmuteTypeEnv::new(self.infcx).is_transmutable(

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'', 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'' File: --auto-reduced (treereduce-rust): original: 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: [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2024-08-22 seems to bisect to
Slightly more reduction:
(Note that this reduction should drop the feature gate, as this ICEs without the feature gate)
claim
Change:
<pre class="language-{}"><code>{}</code></pre> </div>", lang, <del> Escape(&text), </del> <ins> Escape(&origtext), </ins> ) .into(), ));

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: text //! #..#.####.#....#.....##.. //! #..#.#....#....#....#..#. //! ####.###..#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.####.####.####..##.. //! I expected to see this happen: When I run , I expect to see ASCII art in the output that matches the above example. Instead, this happened: In the output, this actually appears: It appears that if a line starts with at least three s, one gets "swallowed" somehow. <!-- 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<summaryBacktrace</summary<p</p</details
It's because of how are handled for rust code blocks. I'll send a PR but we need to ensure that people are not relying on to hide a line for non-rust code blocks.
This is actually a regression. I haven't bisected, but it occurred sometime between 1.50.0 and 1.63.0 based on a quick test. In 1.50.0, the following code block markdown /// # Header /// rendered as , but in 1.63.0 it renders as a blank code block.
Thanks for the information !

The regression is in nightly-2021-07-15 Commits in range: commit[0] 2021-07-13UTC: Auto merge of - camsteffen:hash-lint-resolved, r=oli-obk commit[1] 2021-07-13UTC: Auto merge of - cjgillot:expnhash, r=petrochenkov commit[2] 2021-07-14UTC: Auto merge of - Mark-Simulacrum:edition-no-clone, r=petrochenkov commit[3] 2021-07-14UTC: Auto merge of - tlyu:option-result-overviews, r=joshtriplett commit[4] 2021-07-14UTC: Auto merge of - JohnTitor:rollup-8ltidsq, r=JohnTitor commit[5] 2021-07-14UTC: Auto merge of - michaelwoerister:const-in-debuginfo-type-names-fix, r=oli-obk,wesleywiser commit[6] 2021-07-14UTC: Auto merge of - GuillaumeGomez:rollup-pfz9jbk, r=GuillaumeGomez commit[7] 2021-07-14UTC: Auto merge of - cuviper:fuse-less-specialized, r=joshtriplett Maybe this happened in (merged by ) (cc
Change:
if let clean::ImplItem(ref imp) = *i.kind { // Impl blocks can be skipped if they are: empty; not a trait impl; and have no // documentation. <del> if imp.trait_.is_none() && imp.items.is_empty() && i.doc_value().is_none() { return None; </del> <ins> // // There is one special case: if the impl block contains only private items. if imp.trait_.is_none() { // If the only items present are private ones and we're not rendering private items, // we don't document it. if !imp.items.is_empty() && !self.document_private && imp.items.iter().all(|i| { let item_id = i.item_id; item_id.is_local() && !is_item_reachable( self.is_json_output, &self.cache.access_levels, item_id, ) }) { return None; } else if imp.items.is_empty() && i.doc_value().is_none() { return None; } </ins> } if let Some(did) = imp.for_.def_id(self.cache) { if did.is_local() && !imp.for_.is_assoc_ty() && !self.retained.contains(&did.into())

Discussion:
cc label +A-docs +A-rustdoc-ui +C-enhancement +T-rustdoc This is technically a regression, but it doesn't feel appropriate to label it as such.
Here is an example of a block that should be hidden when is not passed:
Change:
<ins> #![feature(or_patterns)] fn main() { let 0 | (1 | 2) = 0; //~ ERROR refutable pattern in local binding match 0 { //~^ ERROR non-exhaustive patterns 0 | (1 | 2) => {} } } </ins>

Discussion:
This code is reduced from issue--unused-parens- :
Another variation on this to include in a regression test:
cc
Ah yeah, I see the issue. There's an implicit invariant that there should be no or-patterns directly in the first column of the matrix, but this invariant is broken exactly when an or-pattern has a child that is itself an or-pattern. I should have documented that. Specifically this fails to preserve the invariant: I don't expect to have the bandwidth to work on rustc in the foreseeable future sadly. I anyone wants to try, I believe the fix could be as simple as replacing in the above function with a loop that calls (and not ). That will ensure that we recursively expand or-patterns as needed instead of just expanding the first one.
Yep, that did it. Thanks for the pointer. This issue is fixed by
Change:
} } <del> let _ = euv::ExprUseVisitor::new( &FnCtxt::new(self, self.tcx.param_env(closure_def_id), closure_def_id), &mut delegate, ) .consume_body(body); // If a coroutine is comes from a coroutine-closure that is `move`, but // the coroutine-closure was inferred to be `FnOnce` during signature // inference, then it's still possible that we try to borrow upvars from // the coroutine-closure because they are not used by the coroutine body // in a way that forces a move. // // This would lead to an impossible to satisfy situation, since `AsyncFnOnce` // coroutine bodies can't borrow from their parent closure. To fix this, // we force the inner coroutine to also be `move`. This only matters for // coroutine-closures that are `move` since otherwise they themselves will // be borrowing from the outer environment, so there's no self-borrows occuring. if let UpvarArgs::Coroutine(..) = args && let hir::CoroutineKind::Desugared(_, hir::CoroutineSource::Closure) = self.tcx.coroutine_kind(closure_def_id).expect("coroutine should have kind") && let parent_hir_id = self.tcx.local_def_id_to_hir_id(self.tcx.local_parent(closure_def_id)) && let parent_ty = self.node_ty(parent_hir_id) && let Some(ty::ClosureKind::FnOnce) = self.closure_kind(parent_ty) { capture_clause = self.tcx.hir_node(parent_hir_id).expect_closure().capture_clause; } </del> debug!( "For closure={:?}, capture_information={:#?}", closure_def_id, delegate.capture_information

Discussion:
Rustc panicked when I attempted to use async in poll. I wanted to compose an async task inside my custom future :
I believe this is a duplicate of , which I have a local branch to fix but which needs a bit of cleanup first.

<!-- 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. --I tried this code (minimized): I expected to see this happen: Compiles Instead, this happened (): Instead, this happened (latest nightly): ICE Related: Mentioning :wink: Best guess: <details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. -- modify labels: +regression-from-nightly-to-nightly -regression-untriaged Thanks for investigating! -
Nightly-only features aren't typically regression triaged. I'll look into it soon.