jiebi/CodeConvo huggingface dataset:
Change:
self.flat_map_node(node) } <del> fn flat_map_stmt(&mut self, mut node: ast::Stmt) -> SmallVec<[ast::Stmt; 1]> { </del> <ins> fn flat_map_stmt(&mut self, node: ast::Stmt) -> SmallVec<[ast::Stmt; 1]> { </ins> // FIXME: invocations in semicolon-less expressions positions are expanded as expressions, // changing that requires some compatibility measures. if node.is_expr() {

Discussion:
ICE encountered in a , will post more details when i trace it further:
I am able to reproduce the issue with this code and : And it's combination of ("introduce" the ICE, preexisting issue) and (trigger the lint which trigger the ICE).
Further reduced to:
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Issue #18317 mod bleh { macro_rules! defn { ($n:ident) => ( fn $n (&self) -> i32 { println!("{}", stringify!($n)); 1 } ) } #[derive(Copy)] pub struct S; impl S { pub defn!(f); //~ ERROR can't qualify macro invocation with `pub` //~^ HELP try adjusting the macro to put `pub` inside the invocation } } fn main() { bleh::S.f(); } </ins>

Discussion:
Hey, I have an issue on my macros use. The source code of my macro is . I can't put the pub keyword and if I call my macro like this : The methods aren't public. Am I doing something wrong or is it a compiler's bug ? Thanks in advance.
Any news on it ?
Related?
I think.
I just encountered this. I can reproduce it with:
Now let's just hope it'll be fixed sooner or later !
Hm, what should actually mean? A macro in item position can expand to zero or more items. Should the qualifier apply to all of them, or should it be an error to use it with a multi-item macro? We might want to forbid in this position for 1.0, and come back to the issue later. I had a design for that I think would be rather nice. The current workaround is to write The precise syntax is up to the macro author and can accommodate multiple items. This workaround would be less annoying if we had a "0 or 1" repeat operator in macros.
Could you be a little more explicit about the workaround - I can't seem to get it to work.
from the compiler itself. looks better, with less duplicated code.
Thanks for the examples. If I understand them correctly (neither of which generate forms, iiuc), I should be matching on and inserting a literal in the expansion, but does not seem to work :
It works for me on rustc 1.0.0-dev ( 2015-02-16). The playpen is just to have my fix for .
Thanks for the confirmation. I'll be looking forward to a new nightly for once :)
Change:
use std::cmp; use std::mem::replace; <ins> use rustc_data_structures::fx::FxHashSet; </ins> use rustc_data_structures::sync::Lrc; mod diagnostics;

Discussion:
I guess this should be erroring with or E0666 (nested impl trait is not allowed).
Continues crashing in 1.26 stable.
This does not crash:
Particularly unfortunate because of and . <strikeWhat is going on here: There is a syntactical check to forbid nested impl Trait, but the default sneaks past that check, so we probably have to check for that substitution after lowering from HIR in type collection. Though it can also be done in the syntax check with some contortion.</strikeI was thinking that this shouldn't be allowed because it's like nested impl Trait, but is not at all like because the latter allows the inner type to be different from the outer one, while the former doesn't. So it might just be a case of fixing the overflow itself . I can take this myself but someone looking for mentorship or who is just faster is welcome.
Change:
use rustc::ty::{self, TyCtxt, Ty, TypeFoldable}; use rustc::ty::fold::TypeVisitor; use rustc::ty::maps::Providers; <ins> use rustc::ty::subst::UnpackedKind; </ins> use rustc::util::nodemap::NodeSet; use syntax::ast::{self, CRATE_NODE_ID, Ident}; use syntax::symbol::keywords;

Discussion:
I guess this should be erroring with or E0666 (nested impl trait is not allowed).
Continues crashing in 1.26 stable.
This does not crash:
Particularly unfortunate because of and . <strikeWhat is going on here: There is a syntactical check to forbid nested impl Trait, but the default sneaks past that check, so we probably have to check for that substitution after lowering from HIR in type collection. Though it can also be done in the syntax check with some contortion.</strikeI was thinking that this shouldn't be allowed because it's like nested impl Trait, but is not at all like because the latter allows the inner type to be different from the outer one, while the former doesn't. So it might just be a case of fixing the overflow itself . I can take this myself but someone looking for mentorship or who is just faster is welcome.
Change:
error[E0412]: cannot find type `Iter` in this scope <del> --> $DIR/missing-type.rs:4:11 | 4 |     let x: Iter; |            ^^^^ not found in this scope | </del> <ins> --> $DIR/missing-type.rs:4:11 | LL |     let x: Iter; |            ^^^^ not found in this scope | </ins>

Discussion:
Part of To support lines in the first column of UI test output, we have to make use of the flag and update the library. Relevant : The relevant PR in the annotate-snippet library and a new version needs to be released. Once that's done, we have to pass as a second argument to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
modify labels: A-diagnostics E-help-wanted
claim
Change:
// Now that we validated, turn this into a proper constant. let def_id = cid.instance.def.def_id(); if tcx.is_static(def_id).is_some() || cid.promoted.is_some() { <del> mplace_to_const(&ecx, mplace) </del> <ins> Ok(mplace_to_const(&ecx, mplace)) </ins> } else { <del> op_to_const(&ecx, mplace.into()) </del> <ins> Ok(op_to_const(&ecx, mplace.into())) </ins> } })();

Discussion:
It looks like this was broken in the release of 1.32.0 (and is still broken, even on nightly) (checked on ). The following example program: Fails to compile: Interestingly, making the fixes it. My Rust version: I know , but I don't think this qualifies as a field access. And yes, I'm aware of . cc
Interesting. Looks like a validation issue? Cc
Change:
diag.note("no two closures, even if identical, have the same type"); diag.help("consider boxing your closure and/or using it as a trait object"); } <ins> (ty::Coroutine(def_id1, ..), ty::Coroutine(def_id2, ..)) if self.tcx.coroutine_is_async(def_id1) && self.tcx.coroutine_is_async(def_id2) => { diag.note("no two async blocks, even if identical, have the same type"); diag.help( "consider pinning your async block and casting it to a trait object", ); } </ins> (ty::Alias(ty::Opaque, ..), ty::Alias(ty::Opaque, ..)) => { // Issue #63167 diag.note("distinct uses of `impl Trait` result in different opaque types");

Discussion:
Especially for people new to async, this message is extremely opaque. There is not actually enough information to understand it unless you already know (a) that async blocks produce an anonymous future type and (b) that regardless of the type, those futures are always unique and incompatible types. The message sort of implies this (“found a different block”), but it is not actionable in any way. It is pretty easy to get here by reaching for (to pick just one easy example) . I ended up stumbling across it in the process of building up some sample code for the new async chapter in , and I had a moment at first! I have the time to help fix this, so if someone can point me in the right direction and help get it landed, I would be delighted to do the work. No response No response_
This seems like a good suggestion. I'd suggest tweaking the wording a bit, since I don't know that the implications of async blocks having unique types are immediately obvious. Maybe something like this?
labels +AsyncAwait-Triaged We discussed this in our async call and agreed that some improvement along these lines would be good. We could wordsmith it in the PR of course. (It'd be interesting too to add such diagnostics for closures and other similar cases.)
For reference, here's the error message for mismatched s (). Perhaps borrowing from this phrasing could be helpful here?
Change:
padding: 14px; } <del> .source pre { </del> <ins> .source .content pre { </ins> padding: 20px; }

Discussion:
What it looks like on : ! ! The strange color change on the side with the new sidebar style looks kind of tacky (especially at the bottom) and was probably not intended. Currently on : ! !
This is also broken on beta, tagging as such.
I'm looking into this. I see three potential options: the sidebar white on the src pages. This would look the same as the old styling. the width of the src view so it doesn't overlap with the sidebar. The sidebar is empty on src pages though so this looks kind of weird. If the sidebar retained its items from the other doc pages, this might look nice. the sidebar color and the background of the code block match so there isn't slightly different shades of grey on top of each other. I'm leaning toward option 1 for now but I think option 2 might be worth considering in the future. Thoughts?
While I am certainly not the most qualified to weigh in on this, my thoughts would be that 3 is less than desirable (having a random grey stripe on the left side looks out-of-place regardless of whether the color matches or not), 2 would unnecessarily decrease the usability of pages by decreasing the amount of horizontal space available to the code, and 1 is likely the best option. 3 would also mean that the code block would have padding on the right side but no padding on the left.
1 seems good
Ok. Option 1 it is!
Change:
let tcx = self.tcx(); if self.can_use_global_caches(param_env) { <del> if let Some(res) = tcx.evaluation_cache.get(&param_env.and(trait_pred), tcx) { </del> <ins> if let Some(res) = tcx.evaluation_cache.get(&(param_env, trait_pred), tcx) { </ins> return Some(res); } } <del> self.infcx.evaluation_cache.get(&param_env.and(trait_pred), tcx) </del> <ins> self.infcx.evaluation_cache.get(&(param_env, trait_pred), tcx) </ins> } fn insert_evaluation_cache(

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. --code 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. --: This crashes nightly, beta and stable <!-- 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 --
Looks like this is happens during codegen which is why this didn't show up in the test (note the ´check-pass`) ...?
Hmm... this should be normalized somewhere above codegen I think? Curious to investigate though. claim
I suspect that this is caused by a bug in how we handle higher-ranked region variables (possibly during trait selection caching).
Change:
<ins> // only-x86_64 #[cfg(target_arch = "x86")] use std::arch::x86::*; #[cfg(target_arch = "x86_64")] use std::arch::x86_64::*; unsafe fn pclmul(a: __m128i, b: __m128i) -> __m128i { _mm_clmulepi64_si128(a, b, *&mut 42) //~ ERROR argument 3 is required to be a constant } fn main() {} </ins>

Discussion:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to
Change:
self.check_variances_for_type_defn(item, ast_generics); } hir::ItemEnum(ref enum_def, ref ast_generics) => { <del> self.check_type_defn(item, false, |fcx| { </del> <ins> self.check_type_defn(item, true, |fcx| { </ins> fcx.enum_variants(enum_def) });

Discussion:
Backtrace: This seems to occur when using a non-struct type that contains an unsized type. This is probably because  only handles and the base unsized types. This should be extended to handle enums and tuples as well.
This is still happening. Does this mean we should avoid using DSTs for complex custom types for now?
Visiting for triage This is still an issue:
ICE also happens with a tupled trait object:
I've seen this too with: Reproducer: Version: Backtrace:
No longer reproduces but the other tests do.
cc
Is this the same as or related to ?
leads to . As mentioned inline, using the correct type works (). I'm using the Ubuntu PPA "rust-nightly", version ~~vivid.
Does not compile for other reasons that the ICE anymore. I've adjusted to the following and could not reproduce it anymore.
Another example hitting this same ICE:
Bugs similar to this one have been reported numerous times (most of the references to this issue are duplicates). Although it would be nice for reporters to search for similar issues before filing a new one, it's hard to blame them, since the ICE message from rustc tells people to file an issue. This issue itself was opened over two years ago. Separate from fixing the underlying problem, we should at least investigate displaying a real error instead of an ICE.
Change:
return None; } res <del> }) .is_some(); </del> <ins> }); </ins> self.r.doc_link_resolutions = doc_link_resolutions; res }

Discussion:
Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details
Change:
<ins> // Test that we don't duplicate storage for futures moved around in .await, and // for futures moved into other futures. // // The exact sizes can change by a few bytes (we'd like to know when they do). // What we don't want to see is the wrong multiple of 1024 (the size of BigFut) // being reflected in the size. // // See issue #59123 for a full explanation. // ignore-wasm32-bare (sizes don't match) // run-pass // edition:2018 #![feature(async_await)] use std::future::Future; use std::pin::Pin; use std::task::{Context, Poll}; const BIG_FUT_SIZE: usize = 1024; struct BigFut([u8; BIG_FUT_SIZE]); impl BigFut { fn new() -> Self { BigFut([0; BIG_FUT_SIZE]) } } impl Drop for BigFut { fn drop(&mut self) {} } impl Future for BigFut { type Output = (); fn poll(self: Pin<&mut Self>, _ctx: &mut Context<'_>) -> Poll<Self::Output> { Poll::Ready(()) } } #[allow(dead_code)] struct Joiner { a: Option<BigFut>, b: Option<BigFut>, c: Option<BigFut>, } impl Future for Joiner { type Output = (); fn poll(self: Pin<&mut Self>, _ctx: &mut Context<'_>) -> Poll<Self::Output> { Poll::Ready(()) } } fn noop() {} async fn single() { let x = BigFut::new(); x.await; } async fn single_with_noop() { let x = BigFut::new(); noop(); x.await; } async fn joined() { let a = BigFut::new(); let b = BigFut::new(); let c = BigFut::new(); let joiner = Joiner { a: Some(a), b: Some(b), c: Some(c), }; joiner.await } async fn joined_with_noop() { let a = BigFut::new(); let b = BigFut::new(); let c = BigFut::new(); let joiner = Joiner { a: Some(a), b: Some(b), c: Some(c), }; noop(); joiner.await } fn main() { assert_eq!(1028, std::mem::size_of_val(&single())); assert_eq!(1032, std::mem::size_of_val(&single_with_noop())); assert_eq!(3084, std::mem::size_of_val(&joined())); assert_eq!(3084, std::mem::size_of_val(&joined_with_noop())); } </ins>

Discussion:
E.g. in and cc
I'd like to work on this :smile:
You've got it :)
Change:
Some([item]) if item.has_name(sym::on) => return true, Some(_) | None => { // Other possibilities should have been rejected by `rustc_parse::validate_attr`. <del> tcx.dcx().span_bug(attr.span, "unexpected value of coverage attribute"); </del> <ins> // Use `span_delayed_bug` to avoid an ICE in failing builds (#127880). tcx.dcx().span_delayed_bug(attr.span, "unexpected value of coverage attribute"); </ins> } } }

Discussion:
<!-- [31mICE[0m: Rustc '-Cinstrument-coverage -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected value of coverage attribute', 'error: internal compiler error: unexpected value of coverage attribute' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [coverageattron] checking for on [mirbuilt] building MIR for -- label +F-coverageattribute
Regression in
Change:
fn main() { let u: usize = std::mem:size_of::<u32>(); <del> //~^ ERROR expected one of </del> <ins> //~^ ERROR casts cannot be followed by a function call //~| ERROR expected value, found module `std::mem` [E0423] //~| ERROR cannot find type `size_of` in this scope [E0412] </ins> }

Discussion:
Summary: Parsing leads to the error: It is currently impossible for a cast expression to have a trailing index expression without surrounding the cast expression by parenthesis. This however seems to be a parser limitation, not a grammar limitation. As currently the macro language guarantees that ty/path expressions can be followed by a "[", this seems like a bug in the parser to me, as it seems to be parsing it as which makes no grammatical sense, compared to parsing it as (value as Type)[index] which should be valid if I read the lexical structure specification correctly.
I think it's parsed correctly, but should get a tailored error message to suggest surrounding the cast with parens.
Considering that a trailing "[" is never valid in the type syntax (otherwise macros break) and the fact that and variants are perfectly legal (even which is another symbol that occurs in type syntax). But if a tailored error message will be made instead, then this should also include other postfix operators like which are currently rejected even though technically being legal by the lexical grammar specification. (another one is the proposed "?" operator)
This is still lacking a tailored error message, and as far as I know no movement has been made here.
Submitted a pull request to fix this!
Thanks!
Change:
/// The actual stack size may be greater than this value if /// the platform specifies minimal stack size. /// <ins> /// For more information about the stack size for threads, see /// [this module-level documentation][stack-size]. /// </ins> /// # Examples /// /// ```

Discussion:
One can specify the stack size of a thread via . It looks like looks at the env var and attempts to parse it into an integer. If it's not specified or can't parse, it falls back to 2MB. Should we update the thread documentation to mention what the default stack size is and mention that environment variable?
Relevant discussion on IRC
Don't forget that the stack size of the main thread is not determined by Rust.
Opened a PR:
Change:
match def { Def::Variant(variant_did) | Def::VariantCtor(variant_did, ..) => { <del> let enum_did = tcx.parent_def_id(variant_did).unwrap(); let downcast_cmt = if tcx.adt_def(enum_did).is_univariant() { cmt_pat } else { let cmt_pat_ty = cmt_pat.ty; mc.cat_downcast(pat, cmt_pat, cmt_pat_ty, variant_did) }; </del> <ins> let downcast_cmt = mc.cat_downcast_if_needed(pat, cmt_pat, variant_did); </ins> debug!("variant downcast_cmt={:?} pat={:?}", downcast_cmt, pat); delegate.matched_pat(pat, downcast_cmt, match_mode);

Discussion:
I got panic with this code (): Backtrace: My rust version:
This code seems to be minimal example type Value = String; fn main() { let f = ""; Some("".into()).map(f); }
Change:
<ins> // edition: 2018 use clippy::time::Instant; //~^ `clippy` is a tool module fn main() { Instant::now(); } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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
works with any tool attr also compiles but it probably... shouldn't.
label +S-bug-has-mcve
Triaged with . Steps performed: Reproduced: Formatted: No change, already formatted Reduced: Bisected: Regression in nightly-2022-04-17 couldn't nail down the particular commit: <details<summaryDetails</summary<prustc version: Icemelter version: v0.2.0 Icemelter command line: Do you have feedback about this report? Please ! </p</details
another one `
Change:
<ins> error[E0412]: cannot find type `r#break` in module `crate` --> $DIR/raw-ident-in-path.rs:3:17 | LL | type A = crate::r#break; |                 ^^^^^^^ not found in `crate` error: aborting due to previous error For more information about this error, try `rustc --explain E0412`. </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