jiebi/CodeConvo huggingface dataset:
Code change:
self.is_const_fn_raw(def_id) && match self.is_unstable_const_fn(def_id) { Some(feature_name) => { // has a `rustc_const_unstable` attribute, check whether the user enabled the <del> // corresponding feature gate, const_constructor is not a lib feature, so has // to be checked separately. </del> <ins> // corresponding feature gate. </ins> self.features() .declared_lib_features .iter() .any(|&(sym, _)| sym == feature_name) <del> || (feature_name == sym::const_constructor && self.features().const_constructor) </del> }, // functions without const stability are either stable user written // const fn or the user is using feature gates and we thus don't

Related discussion:
text: When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per
Code change:
<ins> fn f1() -> impl Sized { & 2E } //~ ERROR expected at least one digit in exponent fn f2() -> impl Sized { && 2E } //~ ERROR expected at least one digit in exponent fn f3() -> impl Sized { &'a 2E } //~ ERROR expected at least one digit in exponent //~^ ERROR borrow expressions cannot be annotated with lifetimes fn f4() -> impl Sized { &'static 2E } //~ ERROR expected at least one digit in exponent //~^ ERROR borrow expressions cannot be annotated with lifetimes fn f5() -> impl Sized { *& 2E } //~ ERROR expected at least one digit in exponent fn f6() -> impl Sized { &'_ 2E } //~ ERROR expected at least one digit in exponent //~^ ERROR borrow expressions cannot be annotated with lifetimes fn main() {} </ins>

Related discussion:
text: <!-- 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<strongSample Backtrace</strong</summary<p</p</detailsThe original code () is already fixed by , however some other mutations of the original code still ICEs with the same backtrace and error. Thanks. <brCC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If the parsing error is not needed to manifest the issue, can that be fixed () in the MCVE you provided? since more error messages just obscures the underlying ICE that needs to be fixed here.
(also this could probably use a more descriptive title that reflects the ICE, and doesn't just point to another issue, but that's just my opinion)
Is that better?
claim
Code change:
<ins> // edition: 2021 trait Foo { type T; async fn foo(&self) -> Self::T; } struct Bar; impl Foo for Bar { type T = (); async fn foo(&self) {} //~^ ERROR type annotations needed: cannot satisfy `<Bar as Foo>::T == ()` } impl Foo for Bar { //~^ ERROR conflicting implementations of trait `Foo` for type `Bar` type T = (); async fn foo(&self) {} //~^ ERROR type annotations needed: cannot satisfy `<Bar as Foo>::T == ()` } fn main() {} </ins>

Related discussion:
text: No response No response No response
(for compiler people:) We could fix this by merging the impl WF and coherence checks into one compiler stage. I'll put up a PR and see what T-types thinks.
labels +AsyncAwait-Triaged We discussed this in a WG-async meeting and are deferring to the resolution suggested above. He noted that this is a fix to the diagnostics only. That fact that this is an error is correct.
Code change:
let mut indirect_outputs = vec![]; for (i, (out, &place)) in ia.outputs.iter().zip(&outputs).enumerate() { if out.is_rw { <del> inputs.push(self.load_operand(place).immediate()); </del> <ins> let operand = self.load_operand(place); if let OperandValue::Immediate(_) = operand.val { inputs.push(operand.immediate()); } </ins> ext_constraints.push(i.to_string()); } if out.is_indirect { <del> indirect_outputs.push(self.load_operand(place).immediate()); </del> <ins> let operand = self.load_operand(place); if let OperandValue::Immediate(_) = operand.val { indirect_outputs.push(operand.immediate()); } </ins> } else { output_types.push(place.layout.llvm_type(self.cx())); }

Related discussion:
text: Was working on bug and tried to compile the program below. The inline assembly may be bogus: I make no guarantees of its correctness. crashed with this output: : (but also happened on a nightly from late May)
The inline assembly is in fact bogus. Here's a minimal example that crashes the compiler. The problem is likely using the string operand (by mistake, because I'm dumb).
<details<summarybacktrace</summary</details
modify labels: I-ICE T-compiler A-inline-assembly C-bug
Thank you!
Code change:
} } <ins> fn evaluation_is_concurrent(&self) -> bool { self.sess.threads() > 1 } </ins> fn expand_abstract_consts<T: TypeFoldable<TyCtxt<'tcx>>>(self, t: T) -> T { self.expand_abstract_consts(t) }

Related discussion:
text: <!-- 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. --After adding to , I get the ICE. The resulting : The full project: <!-- 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. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?
Code change:
} } <ins> fn evaluation_is_concurrent(&self) -> bool { self.sess.threads() > 1 } </ins> fn expand_abstract_consts<T: TypeFoldable<TyCtxt<'tcx>>>(self, t: T) -> T { self.expand_abstract_consts(t) }

Related discussion:
text: Pretty much what the title says, I've narrowed it down to and today's nightly with the following: I've attached some backtraces.
probably duplicate of but made more prevalent by next solver
Is it possible to provide a link to or a snippet of a reproducer? I know it probably happens to various crates, but it still would be nice to have something that reproduces.
See for an attached repro.
The repro case is basically the same as , but with other crates mentioned in the ICE logs from the issue comment.
Code change:
} } <ins> fn evaluation_is_concurrent(&self) -> bool { self.sess.threads() > 1 } </ins> fn expand_abstract_consts<T: TypeFoldable<TyCtxt<'tcx>>>(self, t: T) -> T { self.expand_abstract_consts(t) }

Related discussion:
text: Compile with latest Nightly got ICE like below: when compiling in code OS: x86_64-apple-darwin
cc
Wyvern, could you provide some sort of reproducer? A link to some commit in some repository or better yet a smaller stripped down version of it?
Can you provide an example which triggers this behavior?
I'm not sure which commit/PR of lead to this crash, sometimes it compiled successfully, sometimes it not. Add this info to original post, hope to help investigation.
are you running with greater than 1? The cache is broken when used with more than 1 thread (which we should fix)
Sorry, I wasn't clear. I meant a link to your project (the project you are trying to compile) if publicly accessible / not proprietary.
I can hit plenty of these while fuzzing with -Zthreads so yeah its probably that.
Yeah, I think was the culprit. Comment out this option crashes disappears.
the easiest fix to rustc is to just disable this assert when we're using more than 1 thread. I've only it for debugging purposes to detect cases where we unnecessarily recompute cache entries
just hit this while trying to bootstrap with Zthreads :sweat_smile:
cc as this also showed up in your ci test run ^^
When I just disable this assert, all relevant UI tests passed with no other bugs or ICE
samle code that triggers this in around 5 of 6 cases with -Zthreads=16
Code change:
<ins> use std::hash::Hash; use std::marker::PhantomData; use std::ops::Index; struct HashMap<K, V>(PhantomData<(K, V)>); impl<K, V> Index<&K> for HashMap<K, V> where K: Hash, V: Copy, { type Output = V; fn index(&self, k: &K) -> &V { todo!() } } fn index<'a, K, V>(map: &'a HashMap<K, V>, k: K) -> &'a V { map[k] //~^ ERROR the trait bound `K: Hash` is not satisfied //~| ERROR the trait bound `V: Copy` is not satisfied //~| ERROR mismatched types //~| ERROR mismatched types } fn main() {} </ins>

Related discussion:
text: I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim
Code change:
import textwrap try: import urllib2 <ins> from urllib2 import HTTPError </ins> except ImportError: import urllib.request as urllib2 <ins> from urllib.error import HTTPError try: import typing except ImportError: pass </ins> # List of people to ping when the status of a tool or a book changed. # These should be collaborators of the rust-lang/rust repository (with at least

Related discussion:
text: Updated the toolstate repository at https://rust-lang- currently does not seem to work, see e.g. To "tool failed to build"-issues are being created, either. remarked that the error . Cc
Code change:
self.error_on_extra_if(&cond)?; // Parse block, which will always fail, but we can add a nice note to the error self.parse_block().map_err(|mut err| { <del> err.span_note( cond_span, "the `if` expression is missing a block after this condition", ); </del> <ins> if self.prev_token == token::Semi && self.token == token::AndAnd && let maybe_let = self.look_ahead(1, |t| t.clone()) && maybe_let.is_keyword(kw::Let) { err.span_suggestion( self.prev_token.span, "consider removing this semicolon to parse the `let` as part of the same chain", "", Applicability::MachineApplicable, ).span_note( self.token.span.to(maybe_let.span), "you likely meant to continue parsing the let-chain starting here", ); } else { err.span_note( cond_span, "the `if` expression is missing a block after this condition", ); } </ins> err })? }

Related discussion:
text: This is a common typo I make when hoisting an inconditional let binding into the let chain to merge two let-chains that could be one. The parser only needs to do look-ahead 1 and 2 to detect the case and recover. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
check_safety_of_rvalue_destructor_if_necessary(rcx, head_cmt, expr.span); } Err(..) => { <del> rcx.fcx.tcx().sess.span_note(expr.span, "cat_expr Errd during dtor check"); </del> <ins> let tcx = rcx.fcx.tcx(); if tcx.sess.has_errors() { // cannot run dropck; okay b/c in error state anyway. } else { tcx.sess.span_bug(expr.span, "cat_expr Errd"); } </ins> } }

Related discussion:
text: I tried to get a minimal example, now i just ended up with completely senseless code, that still gives the error. playpen says: if you remove the for loop, only the last two cat_expr notes are left. adding more code just ends up with more of the notes.
this is pretty much my fault. :) In all the cases that I have seen where it arises, it is due to a type error (or a type inference failure at at least) somewhere in the code. Of course the notes are incredibly annoying. I will try to fix.
And of course the concrete example given here is one where there is no type error. At least, not one exposed by compiling this code. (I have not yet managed to show being instantiated concretely without causing some other type error to arise.)
(but there may be a mix of bugs causing the original input here to pass. In particular, the code in the description is doing , but that associated type does not exist. One needs . See also: )
cc
Code change:
self.maybe_annotate_with_ascription(&mut err, false); err.emit(); self.recover_stmt_(SemiColonMode::Ignore, BlockMode::Ignore); <del> Some(Stmt { id: DUMMY_NODE_ID, kind: StmtKind::Expr(self.mk_expr_err(self.token.span)), span: self.token.span, }) </del> <ins> Some(self.mk_stmt( self.token.span, StmtKind::Expr(self.mk_expr_err(self.token.span)), )) </ins> } Ok(stmt) => stmt, };

Related discussion:
text: The idea of shortening to has been discussed many times before, and the general consensus always ends up being that it is not a good idea. I would like to propose something a bit different, so please hear me out. I propose that instead of aliasing to , we instead just make expand into when in the context of a variable declaration. For example: This solves the problems (readability, more concise) that people have with , whilst not causing the issues that people have (pattern matching and consistancy). The most common issue people have with aliasing to is that it doesn't fit well with patterns, like . However, gets rid of this problem, because you wouldn't write if you were trying to pattern match, so why would someone want to write ? You wouldn't do that, and it wouldn't compile. This would be optional, of course. would still work fine, and people would just have to option of removing the to let it be implied. There are a lot of other abbreviations used in rust (, , ) that all serve the purpose of writing less. It just doesn't feel right that one of the most commonly used keywords is so long. :heart::crab: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Rust wants to make to make you think when you try and use mutation, even if only a little bit, because mutation can be difficult to reason about. Shortening to doesn't fit this philosophy. Also, this makes mutation just as easy as no mutation. This will lead people to choose mutation because it will give them less compiler errors in the short term, and in doing so open themselves up to some weird bugs that could have been prevented with the syntactic salt that is . tldr: wasn't rejected because of the name , but because it allowed easy mutation, which runs counter to Rust's philosophy.
I politely disagree. In fact, it is actually the other way around. Using unnecessarily will cause compiler warnings, discouraging the use of unneeded mutability. The compiler doesn't warn when the use of is actually needed.
The fact that people will choose in the face of compiler warnings has been shown in practice, across many projects.
Code change:
self.maybe_annotate_with_ascription(&mut err, false); err.emit(); self.recover_stmt_(SemiColonMode::Ignore, BlockMode::Ignore); <del> Some(Stmt { id: DUMMY_NODE_ID, kind: StmtKind::Expr(self.mk_expr_err(self.token.span)), span: self.token.span, }) </del> <ins> Some(self.mk_stmt( self.token.span, StmtKind::Expr(self.mk_expr_err(self.token.span)), )) </ins> } Ok(stmt) => stmt, };

Related discussion:
text: Also, the problem isn't that people may choose to put just for the heck of it, but that they will unintentionally mutate something that was supposed to be immutable. And because it is being mutated, there is no warning, and they used because it is their default, it is their default because it gets rid of compiler errors that say they were trying to mutate things that are immutable even though they weren't supposed to mutate them in the first place. They will use because it is just as easy as making it immutable. So the problem is a bit more subtle than you seem to think.
Incorrect. Extreme brevity harms readability. See Perl. lol Readers would ignore the vs distinction far more often that vs , partially due to length difference, but works even better than say . It's true boilerplate often harms readability, but boilerplate requires some complexity be repeated, not merely the in . It harms readability even further if also works for , especially when you consider code readers need not actually know Rust. Rust syntax was designed largely to reduce cognitive load, not to reduce typing. We use , , and , not any shorter alternatives. And delegation RFCs have kinda given up the short syntaxes. I think Rust's omission of is now considered a mistake, but presumably helps C programmers. Rust has short keywords only really for fundamental "items" used repeatedly by basically every module. It's similar cognitive load if you write , , or , but actually just writing the shorter bare increases cognitive load. I think invokes the minor linguistic subtlety that variable means mutable binding, while acts like a common term for binding, which makes very slightly clearer.
The statement would be orthogonal to the current language in some sense though. is not a special syntax, but is composed of statement + pattern. It is in line with other places expects a pattern, where you can write , , or .
It seems unlikely to me that we would support as a short-hand. I'm personally opposed to it both because it adds unnecessary compiler complexity, stylistic schisms, and for the reasons outlined by However, I've taken the liberty of reusing this issue towards improved diagnostics: The idea here is to check . The idea here is to check: The relevant code is here: cc
claim
Error: Parsing assign command in failed: claim :)... Please let know if you're having trouble with this bot.
Code change:
self.maybe_annotate_with_ascription(&mut err, false); err.emit(); self.recover_stmt_(SemiColonMode::Ignore, BlockMode::Ignore); <del> Some(Stmt { id: DUMMY_NODE_ID, kind: StmtKind::Expr(self.mk_expr_err(self.token.span)), span: self.token.span, }) </del> <ins> Some(self.mk_stmt( self.token.span, StmtKind::Expr(self.mk_expr_err(self.token.span)), )) </ins> } Ok(stmt) => stmt, };

Related discussion:
text: Although I would also guess that the initial idea is very unlikely to end up accepted, it feels premature to unilaterally hijack the thread in your very first comment and make it have a different (and in a way opposite) purpose. Teams of the Rust project are designed to make decisions collectively. Improving diagnostics sounds good, but issue numbers are cheap.
Implementing something as a diagnostic actually brings you closer to a working implementation -- I think more proposals should start out as diagnostics. I will not bother the other language team members with not-fully-formed proposals that we will not accept in either case. I converted the issue into the most actionable and productive thing it could be. The place for ephemeral discussions is either on Discord or on internals. If you want to discuss this further, I'm available at Discord (but will not respond to it further here). wasting everyone's time with things that will go nowhere (because it won't be accepted and because it is not important enough to be raised at the team) is not.
IMHO, the original thing this issue was opened for should be an RFC, not an issue. I'd have closed this, pointed the OP to the RFCs repo, and opened a new issue for the diagnostic issue.
This issue was literally in the RFCs repo initially, transferred it from there.
Language bashing is not welcome here
Wait, so should I unassign here, and assign to the new issue?
Nah, just use this one.
Yeah, thats fine. You can just change this issue to be for diagnostics instead.
I'm sorry, I've been pretty busy with coursework, and I'm still fighting my Python installation to even build the compiler, let alone make progress on this. Sorry :(
I'll assign this to myself to work on when I have time. If you want to work on it however, feel free to work-steal it from me!
I would like to help with this
Sorry; should have updated this issue...! There's a PR at the moment. Feel free to leave suggestions on it if you like. :)
Code change:
self.maybe_annotate_with_ascription(&mut err, false); err.emit(); self.recover_stmt_(SemiColonMode::Ignore, BlockMode::Ignore); <del> Some(Stmt { id: DUMMY_NODE_ID, kind: StmtKind::Expr(self.mk_expr_err(self.token.span)), span: self.token.span, }) </del> <ins> Some(self.mk_stmt( self.token.span, StmtKind::Expr(self.mk_expr_err(self.token.span)), )) </ins> } Ok(stmt) => stmt, };

Related discussion:
text: From The following code should be using the common list parsing utilities: CC
What/where are the common list parsing utilties? Edit: never mind, I've got it. , , etc. for anyone who's wondering.