jiebi/CodeConvo huggingface dataset:
Change:
fn main() { while true {} //~ ERROR: infinite loops } <ins> #[deny(while_true)] fn bar() { while cfg!(unix) {} // no error } </ins>

Discussion:
If any linting or suggestion is done in this case, it should suggest cc this has been in rustc forever, but clippy is only lately going crazy on it. Could this have come from your PR, too?
Hmm, shouldn't have been affected, but I'll investigate.
this is messing up clippy pretty bad. Any idea where to start looking?
So I tried to figure out what's going on, but I got lost in the code. As far as I can see it should be setting the expansion info. But it appears the passed to doesn't contain the expansion info. So maybe we need to generate a new span here with the from ?
The span passed to is the call site span, so it shouldn't contain the expansion info. The issue here is that is using the call site span directly in the expansion ( is call site span). To fix this, the macro should add expansion info to the call site span like does . Adding that line in should fix this issue. Are there other built-in macros that also have this problem in practice or is it just ?
I'd assume others have it too, but I'll check. So the passed call site span should only be used directly for error reporting, but never for creating ast items?
Right, unless you want an AST item with the raw (unexpanded) call site span -- I don't think we ever want that.
Change:
<ins> error: cannot specify lifetime arguments explicitly if late bound lifetime parameters are present --> $DIR/issue-60622.rs:12:11 | LL |     fn a(&self) {} |          - the late bound lifetime parameter is introduced here ... LL |     b.a::<'_, T>(); |           ^^ | note: lint level defined here --> $DIR/issue-60622.rs:3:9 | LL | #![deny(warnings)] |         ^^^^^^^^ = note: #[deny(late_bound_lifetime_arguments)] implied by #[deny(warnings)] = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #42868 <https://github.com/rust-lang/rust/issues/42868> error[E0107]: wrong number of type arguments: expected 0, found 1 --> $DIR/issue-60622.rs:12:15 | LL |     b.a::<'_, T>(); |               ^ unexpected type argument error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0107`. </ins>

Discussion:
Compiler crashes with Also, I wonder what is the right way (or is there any way) to write a with expected behavior. Thanks.
Reduced:
Regression first occurred in 1.30 according to godbolt.
One can leave out the trait in your MCVE, still crashes. Bug was introduced somewhere between ... Sadly that's a very big range, but there are no nightlys available in between and also no bors artifacts because they are older than 167
triage: P-high
Smaller example from :
I was trying to remove as many type parameters as possible, and ended up with this: Removing after still cuases an ICE. Adding a after stops causing the ICE. Removing the also stops causing the ICE. Not sure if it's any more or less helpful, but just putting this here.
claim Looks like that didn't work, either way, I'm taking a look into this issue.
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Change:
return first; } TokenTree::Sequence(sp, ref seq_rep) => { <del> match self.first.get(&sp.entire()) { Some(&Some(ref subfirst)) => { // If the sequence contents can be empty, then the first // token could be the separator token itself. if let (Some(sep), true) = (&seq_rep.separator, subfirst.maybe_empty) { first.add_one_maybe(TokenTree::Token(sep.clone())); } assert!(first.maybe_empty); first.add_all(subfirst); if subfirst.maybe_empty || seq_rep.kleene.op == quoted::KleeneOp::ZeroOrMore || seq_rep.kleene.op == quoted::KleeneOp::ZeroOrOne { // continue scanning for more first // tokens, but also make sure we // restore empty-tracking state first.maybe_empty = true; continue; } else { return first; } } </del> <ins> let subfirst_owned; let subfirst = match self.first.get(&sp.entire()) { Some(&Some(ref subfirst)) => subfirst, </ins> Some(&None) => { <del> panic!("assume all sequences have (unique) spans for now"); </del> <ins> subfirst_owned = self.first(&seq_rep.tts[..]); &subfirst_owned </ins> } None => { panic!("We missed a sequence during FirstSets construction"); } <ins> }; // If the sequence contents can be empty, then the first // token could be the separator token itself. if let (Some(sep), true) = (&seq_rep.separator, subfirst.maybe_empty) { first.add_one_maybe(TokenTree::Token(sep.clone())); } assert!(first.maybe_empty); first.add_all(subfirst); if subfirst.maybe_empty || seq_rep.kleene.op == quoted::KleeneOp::ZeroOrMore || seq_rep.kleene.op == quoted::KleeneOp::ZeroOrOne { // Continue scanning for more first // tokens, but also make sure we // restore empty-tracking state. first.maybe_empty = true; continue; } else { return first; </ins> } } }

Discussion:
Steps to reproduce: Extract the archive Run Run The following generated macro is a likely source of error: However, directly putting this macro does not seem to cause a compiler crash: It appears that the crash only occurs when the macro-by-example generated from a proc-macro. The full error message: Using gives a similar result: You can try removing the first one or two parts in the macro pattern and the error disappears.
cc
cc
The offending code is here: TBH, I'm not really sure what it is checking, and I don't have time to look into it right now (work is busy)... Sorry about that. It seems that the procmacro is somehow generating some tokens or TokenTrees (especially in a [i.e. a token repetition]) that don't have spans somehow. is that even possible? It looks like pnkfelix wrote this code originally 4 years ago. It hasn't been touched in years. do you know if there have been any changes in proc_macros that could have exposed this behavior?
Change:
codegen_llvm_lto_dylib = lto cannot be used for `dylib` crate type without `-Zdylib-lto` <ins> codegen_llvm_lto_proc_macro = lto cannot be used for `proc-macro` crate type without `-Zdylib-lto` </ins> codegen_llvm_missing_features = add the missing features in a `target_feature` attribute

Discussion:
I'm trying to cross-compile the rust compiler to x86_64 on an M1 macOS machine with LTO enabled and ran into a compile error while building the stage2 compiler artifact: I also tried cross-compiling aarch64 on an Intel Mac and ran into the same issue. Here is the I used: It seems that is enabling LTO for proc-macro crates, but only when cross-compiling?
sorry for pinging, are there any updates on this issue? This bug is easily reproducible, and is preventing cross compiling the toolchain with LTO enabled.
I haven't had time to look into this, no. You can always disable LTO as a workaround.
This problem also appears when just the vendor of the target tripple changes (i.e. ).
Thank you for the additional feedback, will look into this issue in couple weeks.
Change:
<ins> error[E0572]: return statement outside of function body --> $DIR/issue-64620.rs:2:10 | LL |     V1 = return [0][0] |          ^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0572`. </ins>

Discussion:
The following ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</detailsRunning a quick test in godbolt, the first occurrence of the ICE is in stable 1.25. Feel free to close if this is a dupe of
triage: P-medium. has fix in PR (thanks !). Assigning to latter and removing nomination label.
Change:
{favicon} {in_header} </head> <del> <body class="rustdoc"> </del> <ins> <body class="rustdoc {css_class}"> </ins> <!--[if lte IE 8]> <div class="warning"> This old browser is unsupported and will most likely display funky

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:
_0 = const 3_i32;                // scope 0 at $DIR/match-arm-scopes.rs:15:59: 15:60 StorageDead(_13);                // scope 0 at $DIR/match-arm-scopes.rs:15:72: 15:73 StorageDead(_12);                // scope 0 at $DIR/match-arm-scopes.rs:15:77: 15:78 <del> -         goto -> bb23;                    // scope 0 at $DIR/match-arm-scopes.rs:1:1: 1:1 +         goto -> bb20;                    // scope 0 at $DIR/match-arm-scopes.rs:1:1: 1:1 </del> <ins> -         goto -> bb23;                    // scope 0 at no-location +         goto -> bb20;                    // scope 0 at no-location </ins> } -     bb15: {

Discussion:
Sysroot has been compiled using to get set. Otherwise it is hard to guess a defid with encoded mir, now it is just taking the first exported symbol from:
I used to read the mir.
I think these are and printed as . If so it would be less confusing if the debug impl of would say or something like that instead.
I'm unsure how to reproduce the environment to reproduce this bug. It's easy to adjust the debug printing for , but without a test for that I'm not sure how to test it
Change:
let mut err = self.struct_span_err(self.token.span, &msg_exp); if let TokenKind::Ident(symbol, _) = &self.prev_token.kind { <del> if symbol.as_str() == "public" { err.span_suggestion_short( self.prev_token.span, "write `pub` instead of `public` to make the item public", "pub", appl, ); } </del> if ["def", "fun", "func", "function"].contains(&symbol.as_str()) { err.span_suggestion_short( self.prev_token.span,

Discussion:
When writing it will suggest and I think nothing should be suggested before it is validated. The statement to be suggested must be checked if it is true or not, if true it is suggested and if not it is not. The issue from: : The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oh dear, I didn't think of that while making the PR. A possible solution could be checking if the current token is for initializing an item? Like, struct/enum/macro, etc.
I wrote this solution, but I don't know if I can use it in rustc, it's currently building
I can't work on the problem unfortunately, whoever will assign it to him you can solve it this way The block
release-assignment
claim
Trying to add a method in token: And add a check: Any other better idea?
could be the keyword, as well. looks alright, ideally the repeated block could be prevented using a macro? I'm afraid that might slightly overengineer it, though.
Change:
} #[stable(feature = "collection_debug", since = "1.17.0")] <del> impl<'a, K: 'a + fmt::Debug, V: 'a + fmt::Debug> fmt::Debug for Values<'a, K, V> { </del> <ins> impl<'a, K: 'a, V: 'a + fmt::Debug> fmt::Debug for Values<'a, K, V> { </ins> fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { <del> f.debug_list().entries(self.inner.clone()).finish() </del> <ins> f.debug_list().entries(self.clone()).finish() </ins> } }

Discussion:
landed implementations for a number of derived types in collections, but imposes overly strict requirements. For example, for : Given that only the keys are printed, we should only require , not also (unless I'm mistaken?).
Yep, seems overly restrictive.
While we're on it, should only require , and the same change should be applied to and friends.
Change:
input_tarballs.push_str(&sanitize_sh(&mingw_installer)); } <del> let mut cmd = Command::new("sh"); </del> <ins> let mut cmd = Command::new(SH_CMD); </ins> cmd.arg(sanitize_sh(&build.src.join("src/rust-installer/combine-installers.sh"))) .arg("--product-name=Rust") .arg("--rel-manifest-dir=rustlib")

Discussion:
The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .
Change:
<ins> // edition:2018 </ins> #[bench] //~ ERROR use of unstable library feature 'test' //~| WARN this was previously accepted fn bench() {} <ins> use bench as _; //~ ERROR use of unstable library feature 'test' //~| WARN this was previously accepted </ins> fn main() {}

Discussion:
Hi there, I'm updating rust-sgx-sdk (solving rust-sgx-sdk ) to use latest rust nightly compiler to help the error info more ergonomic by the help of . However, the compiler always panics. Your help would be very much helpful. The current code is at . To reproduce this bug, please checkout branch and build sgxtstd as follows: And the reproducible failure info is: : rustc 1.40.0-nightly ( 2019-10-03) binary: rustc commit-hash: commit-date: 2019-10-03 host: x8664-unknown-linux-gnu release: 1.40.0-nightly LLVM version: 9.0 Backtrace:
It'd be helpful to have a more minimal example here I suspect -- for example, at least reducing to a single crate. cc since this deals with diagnostic machinery
It seems like this was introduced a month ago in , CC
I think I find the solution on my side: the removal of .
A working branch is baidu/rust-sgx-sdk : test-2019-10. Failing branch is librustc-bug-report. After I enable , the compiler starts to fail.
The minimum sample is as follows: and compile by
Fixed in
Cool!
Change:
<ins> // Issue #94176: wrong span for the error message of a mismatched type error, // if the function uses a `let else` construct. #![feature(let_else)] pub fn test(a: Option<u32>) -> Option<u32> { //~ ERROR mismatched types let Some(_) = a else { return None; }; println!("Foo"); } fn main() {} </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: A helpful error message pointing to the end of the block. Instead, this happened: An error message with a wrong span: <!-- 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. --: cc labels: +T-compiler +F-let-else +requires-nightly +A-diagnostics
Let's try that again... label +T-compiler +F-let-else +requires-nightly +A-diagnostics
FTR this is the error for the equivalent:
I wonder how is affecting this, as this seems to be a bug in the desugaring and that PR changes it. what is the error output with your PR applied? Does it fix the issue? If so, maybe adding a test to your PR would be helpful.
I meant caused by the desugaring, not in the desugaring.
It won't fix it. This needs a bit of work I think, to push the error further inside the if-let-else branch, so the span marked is the implicit return expression or lack thereof, which is (in the source code) further down in the block.
Hmm if you move the println into the , it gives a similar error to the one emitted by : gives
That's because you have only now reproduced the actual desugaring.
Change:
) } <ins> fn construct_mut_suggestion_for_local_binding_patterns( &self, err: &mut DiagnosticBuilder<'_, ErrorGuaranteed>, local: Local, ) { let local_decl = &self.body.local_decls[local]; debug!("local_decl: {:?}", local_decl); let pat_span = match *local_decl.local_info() { LocalInfo::User(BindingForm::Var(mir::VarBindingForm { binding_mode: ty::BindingMode::BindByValue(Mutability::Not), opt_ty_info: _, opt_match_place: _, pat_span, })) => pat_span, _ => local_decl.source_info.span, }; struct BindingFinder { span: Span, hir_id: Option<hir::HirId>, } impl<'tcx> Visitor<'tcx> for BindingFinder { fn visit_stmt(&mut self, s: &'tcx hir::Stmt<'tcx>) { if let hir::StmtKind::Local(local) = s.kind { if local.pat.span == self.span { self.hir_id = Some(local.hir_id); } } hir::intravisit::walk_stmt(self, s); } } let hir_map = self.infcx.tcx.hir(); let def_id = self.body.source.def_id(); let hir_id = if let Some(local_def_id) = def_id.as_local() && let Some(body_id) = hir_map.maybe_body_owned_by(local_def_id) { let body = hir_map.body(body_id); let mut v = BindingFinder { span: pat_span, hir_id: None, }; v.visit_body(body); v.hir_id } else { None }; // With ref-binding patterns, the mutability suggestion has to apply to // the binding, not the reference (which would be a type error): // // `let &b = a;` -> `let &(mut b) = a;` if let Some(hir_id) = hir_id && let Some(hir::Node::Local(hir::Local { pat: hir::Pat { kind: hir::PatKind::Ref(_, _), .. }, .. })) = hir_map.find(hir_id) && let Ok(name) = self.infcx.tcx.sess.source_map().span_to_snippet(local_decl.source_info.span) { err.span_suggestion( pat_span, "consider changing this to be mutable", format!("&(mut {name})"), Applicability::MachineApplicable, ); return; } err.span_suggestion_verbose( local_decl.source_info.span.shrink_to_lo(), "consider changing this to be mutable", "mut ", Applicability::MachineApplicable, ); } </ins> // point to span of upvar making closure call require mutable borrow fn show_mutating_upvar( &self,

Discussion:
No response Applying the suggestion gives No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It should suggest instead. Looks odd but it's correct. label -needs-triage A-suggestion-diagnostics D-invalid-suggestion
Hi, I'm interested in this issue and want to try to fix it. claim
Change:
} fn fold_item(&mut self, item: P<ast::Item>) -> SmallVector<P<ast::Item>> { <del> self.configure(item).map(|item| SmallVector::one(item.map(|i| self.fold_item_simple(i)))) </del> <ins> self.configure(item).map(|item| fold::noop_fold_item(item, self)) .unwrap_or(SmallVector::zero()) } fn fold_impl_item(&mut self, item: ast::ImplItem) -> SmallVector<ast::ImplItem> { self.configure(item).map(|item| fold::noop_fold_impl_item(item, self)) .unwrap_or(SmallVector::zero()) } fn fold_trait_item(&mut self, item: ast::TraitItem) -> SmallVector<ast::TraitItem> { self.configure(item).map(|item| fold::noop_fold_trait_item(item, self)) </ins> .unwrap_or(SmallVector::zero()) } }

Discussion:
no longer compiles on nightly due to what I think is a regression in macro hygiene: Here we have methods on a trait that are defined by hand, but implemented by macro. The function names are not generated by the macro - they're passed in, so I would not expect any hygiene shenanigans to apply. Possibly ? cc
Thanks for the report! I fixed this in -- it was caused by .
Change:
ast::ItemConst(_, ref ex) => { gather_loans::gather_loans_in_static_initializer(this, &**ex); } <del> _ => { visit::walk_item(this, item); } </del> <ins> _ => { } </ins> } <ins> visit::walk_item(this, item); </ins> } /// Collection of conclusions determined via borrow checker analyses.

Discussion:
Functions defined inside of declarations seem to ignore all lifetimes and mutability. This allows for massively violating the safety guarantees of Rust:
Nominating, this seems incredibly serious.
According to it seems that the borrowck isn't bothering to walk statics/consts (see ). Presumably this code was never updated when it became possible to use blocks as the initializer expression.
Um, yeah, not good. I'll investigate soonish, presuming doesn't get there first.
P-back-compatlang, 1.0 beta
Change:
}) .map(|pred| { tcx.fold_regions(pred, |r, _| match *r { <del> ty::ReVar(vid) => vid_to_region[&vid], </del> <ins> // FIXME: Don't `unwrap_or`, I think we should panic if we encounter an infer var that // we can't map to a concrete region. However, `AutoTraitFinder` *does* leak those kinds // of `ReVar`s for some reason at the time of writing. See `rustdoc-ui/` tests. // This is in dire need of an investigation into `AutoTraitFinder`. ty::ReVar(vid) => vid_to_region.get(&vid).copied().unwrap_or(r), </ins> ty::ReEarlyParam(_) | ty::ReStatic | ty::ReBound(..) | ty::ReError(_) => r, <ins> // FIXME(#120606): `AutoTraitFinder` can actually leak placeholder regions which feels // incorrect. Needs investigation. </ins> ty::ReLateParam(_) | ty::RePlaceholder(_) | ty::ReErased => { bug!("unexpected region kind: {r:?}") }

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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 --
probably cc
yep yep yep, I got it :) claim

<!-- 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
reduced a bit `
Ah another bug ^^. label T-compiler A-synthetic-impls A-auto-traits
reduce:
All three reproducers will be fixed by .
I can no longer reproduce any of these issues.