jiebi/CodeConvo huggingface dataset:
Change:
<ins> // only-x86_64 #![feature(asm_const)] use std::arch::asm; fn main() { let mut foo = 0; let mut bar = 0; unsafe { asm!("", a = in("eax") foo); //~^ ERROR explicit register arguments cannot have names asm!("{a}", in("eax") foo, a = const bar); //~^ ERROR attempt to use a non-constant value in a constant asm!("{a}", in("eax") foo, a = const bar); //~^ ERROR attempt to use a non-constant value in a constant asm!("{1}", in("eax") foo, const bar); //~^ ERROR positional arguments cannot follow named arguments or explicit register arguments //~^^ ERROR attempt to use a non-constant value in a constant } } </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.58:
This was , whoops. I can work on this. claim
Change:
use rustc_hir as hir; use rustc_hir::def_id::{DefId, LocalDefId}; use rustc_infer::traits::FulfillmentError; <ins> use rustc_middle::query::Key; </ins> use rustc_middle::ty::{self, suggest_constraining_type_param, Ty, TyCtxt, TypeVisitableExt}; use rustc_session::parse::feature_err; use rustc_span::edit_distance::find_best_match_for_name;

Discussion:
` " ); } This had me VERY confused as I was certain I would try to get a String here, where does Example come from?? And associated types wut?? The problem is I used which should have been :D Maybe rustc could improve its suggestion somehow in that case? No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
For reference, here is a MRE:
claim
Change:
let is_struct_pat_shorthand_field = self.is_hir_id_from_struct_pattern_shorthand_field(expr.hir_id, sp); <del> // If the span is from a macro, then it's hard to extract the text // and make a good suggestion, so don't bother. let is_macro = sp.from_expansion() && sp.desugaring_kind().is_none(); </del> // `ExprKind::DropTemps` is semantically irrelevant for these suggestions. let expr = expr.peel_drop_temps();

Discussion:
The tokens generated by procmacro (e.g. from ) use , which makes some suggestions produce invalid output: It's a bit tricky, because this callsite span does point into the current crate (to ), so this situaiton isn't detected in the same way as external .
Looks like should be used in more places. That one detects this span by checking if is a dummy or imported.
I'm working on a fix specifically for these typeck/borrowing suggestions. Not sure how many other suggestions have the same problem.
this is a prevalent problem. We need to add metadata to spans to distinguish call sites explicitly in an easy way and always ignore suggestions in them.
Change:
<ins> const pub () {} //~^ ERROR expected one of `async`, `extern`, `fn`, or `unsafe` pub fn main() {} </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2021-02-10 to nightly-2021-05-01 regressed nightly: nightly-2021-03-19 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsIt looks like is when this error started happening. cc
I'm going to take a look at this. claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
Change:
} } <ins> /// Wether `hir_id` corresponds to a `mod` or a crate. pub fn is_hir_id_module(&self, hir_id: HirId) -> bool { match self.lookup(hir_id) { Some(Entry { node: Node::Item(Item { node: ItemKind::Mod(_), .. }), .. }) | Some(Entry { node: Node::Crate, .. }) => true, _ => false, } } </ins> /// If there is some error when walking the parents (e.g., a node does not /// have a parent in the map or a node can't be found), then we return the /// last good `HirId` we found. Note that reaching the crate root (`id == 0`),

Discussion:
Seems to be something to do with Rocket. Having a on the internal function is causing the compiler to blow up. Version: Stack trace:
I think this issue might be better-suited for the Rocket repository.
Ah OK. The output told me to file an issue here so I thought it might be a compiler problem rather than something specific to Rocket. Can we leave it open for a bit just until it's confirmed as Rocket-specific?
Hm, this bug probably originates with interesting codegen in Rocket, but is likely a bug in rustc in the end. I would keep it here, though letting Rocket know about it might not be a bad idea.
I'm going to label this as P-high for now since it affects Rocket. cc re. macros & privacy.
Without looking too deeply I would wager that we're getting a here, although it could be any other which would be worrisome:
Would be great to have a reproducer that did not depend on Rocket and codegen, if it is possible.
Trying to get a simple reproducible example and am unable to :( It got a little time-consuming and I really need to get work done so have worked around it for now. I could possibly publish everything in a repo, but it would still be rocket + codegen and not a very simple example!
Latest nightly (2019-08-11) still panics, but with different error message:
Also as a sidenote: Rocket master does not ICE anymore. The ICE "was fixed" by so it may be a problem with decl_macro ?
I would still wan't not to ICE on the face of malformed input.
For future reference, when panicking or using for not finding what you expect it is a good idea to include in the message what the found value was. :)
I think you got me wrong. I haven't said, that this should be closed because upstream code has changed, but I said, that upstream does not ICE anymore, so I looked into it, what caused it to not ICE anymore.

I try to go that ;) Confirmed, that it is related to decl maros modify labels: +A-macros-2.0
I need your help with the tags here please ^^
<details<summaryBacktraces</summary<details<summary60960a260</summary</details<details<summarydddb7fca0</summary</details</details modify labels: -E-needs-mcve
What is the appropriate visibility scope for ? is failing because we get the following instead: In my mind the expected semantics of this could would be to scope to inside , but currently with a macro by example it would be scoped to the current module. I can implement either semantic. Edit: I'm talking out of my ass, matches my intuition. Don't know why I thought otherwise.
Change:
pub fn pat_id_map(dm: &resolve::DefMap, pat: &Pat) -> PatIdMap { let mut map = HashMap::new(); pat_bindings(dm, pat, |_bm, p_id, _s, path1| { <del> map.insert(path1.node, p_id); </del> <ins> map.insert(path1.node, p_id); </ins> }); map } <ins> pub fn pat_is_refutable(dm: &resolve::DefMap, pat: &Pat) -> bool { match pat.node { PatLit(_) | PatRange(_, _) => true, PatEnum(_, _) | PatIdent(_, _, None) | PatStruct(..) => { match dm.borrow().find(&pat.id) { Some(&DefVariant(..)) => true, _ => false } } PatVec(_, _, _) => true, _ => false } } </ins> pub fn pat_is_variant_or_struct(dm: &resolve::DefMap, pat: &Pat) -> bool { match pat.node { PatEnum(_, _) | PatIdent(_, _, None) | PatStruct(..) => {

Discussion:
Minimal test case: If 1024 doesn’t do it for you, try bumping it upwards. ought to do it. Just don’t try numbers like a million or you’ll be waiting a while before it crashes. And if you have anything like systemd-coredump start automatically, it’ll be busy for a while as well… I guess there are a few areas where [T, ..N] is not handled well for large N. (Additional keywords: sized array.)
Running it under GDB shows that it’s flipping back and forth between two functions recursively: Whatever this recursive algorithm is needs to be made non-recursive.
There is a slight difference between this minimal test case, and the original issue . If I reduce the size of the array to 10 bytes in , compilation never completes (no error is raised). If I reduce the size of the array in this test case to 10 bytes, it compiles.
could you try to narrow down the test from , in the manner that chris-morgan has done here, but preserving the behavioral difference you are observing?
I will try my best (this lunchtime), but I only have three hours experience with Rust so far. Every few lines of code written or modified requires 15 minutes of Googling the docs. (This learning curve is still much less steep than Haskell's was.)
feel free to drop by , you’ll get any help you need there quickly.
I was mistaken. I had a subsequent, chained, command on the command line which produced no output and hung. I mistook this for the compiler hanging.
okay, great, thanks for the update! (I now feel better about asking you to do the narrowing rather than attempting to do it myself.) ;)
Change:
hir::ExprIndex(P(self.lower_expr(el)), P(self.lower_expr(er))) } ExprKind::Range(ref e1, ref e2, lims) => { <del> fn make_struct(this: &mut LoweringContext, ast_expr: &Expr, path: &[&str], fields: &[(&str, &P<Expr>)]) -> hir::Expr { let struct_path = &iter::once(&"ops").chain(path).map(|s| *s) .collect::<Vec<_>>(); let unstable_span = this.allow_internal_unstable("...", ast_expr.span); if fields.len() == 0 { this.expr_std_path(unstable_span, struct_path, ast_expr.attrs.clone()) } else { let fields = fields.into_iter().map(|&(s, e)| { let expr = P(this.lower_expr(&e)); let unstable_span = this.allow_internal_unstable("...", e.span); this.field(Symbol::intern(s), expr, unstable_span) }).collect(); let attrs = ast_expr.attrs.clone(); this.expr_std_struct(unstable_span, struct_path, fields, None, attrs) } } </del> use syntax::ast::RangeLimits::*; <del> return match (e1, e2, lims) { (&None,         &None,         HalfOpen) => make_struct(self, e, &["RangeFull"], &[]), (&Some(ref e1), &None,         HalfOpen) => make_struct(self, e, &["RangeFrom"], &[("start", e1)]), (&None,         &Some(ref e2), HalfOpen) => make_struct(self, e, &["RangeTo"], &[("end", e2)]), (&Some(ref e1), &Some(ref e2), HalfOpen) => make_struct(self, e, &["Range"], &[("start", e1), ("end", e2)]), (&None,         &Some(ref e2), Closed)   => make_struct(self, e, &["RangeToInclusive"], &[("end", e2)]), (&Some(ref e1), &Some(ref e2), Closed)   => make_struct(self, e, &["RangeInclusive", "NonEmpty"], &[("start", e1), ("end", e2)]), </del> <ins> let (path, variant) = match (e1, e2, lims) { (&None, &None, HalfOpen) => ("RangeFull", None), (&Some(..), &None, HalfOpen) => ("RangeFrom", None), (&None, &Some(..), HalfOpen) => ("RangeTo", None), (&Some(..), &Some(..), HalfOpen) => ("Range", None), (&None, &Some(..), Closed) => ("RangeToInclusive", None), (&Some(..), &Some(..), Closed) => ("RangeInclusive", Some("NonEmpty")), (_, &None, Closed) => panic!(self.diagnostic().span_fatal( e.span, "inclusive range with no end")), }; </ins> <del> _ => panic!(self.diagnostic() .span_fatal(e.span, "inclusive range with no end")), </del> <ins> let fields = e1.iter().map(|e| ("start", e)).chain(e2.iter().map(|e| ("end", e))) .map(|(s, e)| { let expr = P(self.lower_expr(&e)); let unstable_span = self.allow_internal_unstable("...", e.span); self.field(Symbol::intern(s), expr, unstable_span) }).collect::<P<[hir::Field]>>(); let is_unit = fields.is_empty(); let unstable_span = self.allow_internal_unstable("...", e.span); let struct_path = iter::once("ops").chain(iter::once(path)).chain(variant) .collect::<Vec<_>>(); let struct_path = self.std_path(unstable_span, &struct_path, is_unit); let struct_path = hir::QPath::Resolved(None, P(struct_path)); return hir::Expr { id: self.lower_node_id(e.id), node: if is_unit { hir::ExprPath(struct_path) } else { hir::ExprStruct(struct_path, fields, None) }, span: unstable_span, attrs: e.attrs.clone(), </ins> }; } ExprKind::Path(ref qself, ref path) => {

Discussion:
The following code produces a compiler error (as expected) on stable, but the compiler crashes on nightly. On stable: On nightly:
Also in beta=1.17.
Backtrace:
Change:
#![feature(slice_internals)] #![feature(slice_partition_dedup)] #![feature(ip)] <del> #![feature(ip_in_core)] </del> #![feature(iter_advance_by)] #![feature(iter_array_chunks)] #![feature(iter_collect_into)]

Discussion:
Feature gate: This is a tracking issue for RFC , providing networking types in : , , , , , , and . [x] Implementation: [x] Final comment period (FCP)[^1] [x] Stabilization PR: [^1]: https://std-dev-
I guess there's nothing left to do. Can this feature now move to the the FCP?
Can this be stabilized before  ( implements )?
I believe so. Nothing in ipaddr points or uses core::error::Error: (master) The only impl Error is in Parser and I guess it needs to be featured gated:
You can't feature gate a trait implementation. The question would be if it's possible to refer to any of the methods on the error types without having to activate the feature. I believe not, since you would have to in order to bring the methods into scope.
Thanks for the explanation and yes, I agree that it can't be stabilised before Error then.
I disagree, this feature can be specialized before . Nothing will change for users, and users will merely not be able to use the impl. This is just like all existing errors in , eg (which is arguably stable):
Ping could this go into FCP?
Yes, please.
nominate libs
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
maybe? Would like to get some confirmation that this is on some list somewhere for discussion.
I've the nomination label so it'll be discussed in a libs-api meeting, though it's possible a libs-api member may decide to remove the label and just fcp it. It'd likely be helpful if someone could provide a summary of the current state of things and why this is ready for stabilization.
I'm not claiming this bears enough weight to stabilize but I just allowed in a small library that used address types and it went completely smooth.
Starting FCP for stabilization. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period.

If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
I pushed a stabilization PR:
Change:
match it.node { ItemStatic(_, _, ref ex) => { v.inside_const(|v| v.visit_expr(&**ex)); <del> check_item_recursion(&v.tcx.sess, &v.tcx.map, &v.tcx.def_map, it); </del> } ItemEnum(ref enum_definition, _) => { for var in (*enum_definition).variants.iter() {

Discussion:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.
Change:
) -> InterpResult<'tcx, OpTy<'tcx, M::PointerTag>> { let base = match op.try_as_mplace(self) { Ok(mplace) => { <del> // The easy case </del> <ins> // We can reuse the mplace field computation logic for indirect operands. </ins> let field = self.mplace_field(mplace, field)?; return Ok(field.into()); }

Discussion:
cc I suspect (but have not verified) that this would be fixed by a backport of
was merged in October, I don't think it's related
Does this need an mcve?
Yeah, but I think at this point a bisection might be more helpful since we're not yet sure what caused this.
Here's a somewhat small-ish MCVE: Haven't managed to remove mio yet, but that's just a matter of time ;) Note, that this doesn't depend on the feature. You can use as well.
Here's a "M"CVE without any dependencies: regression in nightly-2020-01-11 <details<summaryBacktrace</summary</details modify labels: -E-needs-bisection -E-needs-mcve
searched nightlies: from nightly-2019-11-01 to nightly-2020-02-16 regressed nightly: nightly-2020-01-11 searched commits: from to regressed commit: source code: Reproduce bisection with: <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details<details<summaryERROR BEFORE ICE REGRESSION</summary<p</p</details
It would be good to continue the bisection into the rollup PR, among the following PRs: (Point at opaque and closure type definitions in type errors) (Reduce special treatment for zsts) (Parse the syntax described in RFC 2632) (rustcastlowering: misc cleanup & rustc dep reductions) (Extend support of in type parameters) (expect after / )
triage: P-high, removing nomination, assigning to self.
Given the backtrace, I think it's probably (Reduce special treatment for zsts)
I can indeed reproduce the ICE at , seems to be the culprit. cc <details<summaryBacktrace</summary</details
Here is a more minimal MCVE: /me needs to invest some time in tools like rust-reduce or creduce...
Okay so now we have two different PR's to fix this. PR is almost certainly the right call for nightly itself. My only Question is whether we should also land PR and also then backport that to beta. My argument for why is that it is "obviously" less risky, which is important because the beta is going to be imminently promoted to stable.
Change:
let hidden_type = self.resolve(decl.hidden_type, &decl.hidden_type.span); let opaque_type_key = self.resolve(opaque_type_key, &decl.hidden_type.span); <del> struct RecursionChecker { def_id: LocalDefId, } impl<'tcx> ty::TypeVisitor<TyCtxt<'tcx>> for RecursionChecker { type BreakTy = (); fn visit_ty(&mut self, t: Ty<'tcx>) -> ControlFlow<Self::BreakTy> { if let ty::Alias(ty::Opaque, ty::AliasTy { def_id, .. }) = *t.kind() { if def_id == self.def_id.to_def_id() { return ControlFlow::Break(()); } } t.super_visit_with(self) } } if hidden_type .visit_with(&mut RecursionChecker { def_id: opaque_type_key.def_id }) .is_break() </del> <ins> if let ty::Alias(ty::Opaque, alias_ty) = hidden_type.ty.kind() && alias_ty.def_id == opaque_type_key.def_id.to_def_id() && alias_ty.args == opaque_type_key.args </ins> { continue; }

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: compile error that said the return type is wrong. Instead, this happened: compiled without error <!-- 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

edit: minimized see for more details <!-- 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: Compilation should fail, because different generator types should be generated by calling , meaning and should not share the same type . Instead, compilation passes, and occurs during runtime: More context: <!-- 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<summaryNo Backtrace from running it</summary<p</p</details
label +F-typealiasimpl_trait +I-unsound +T-compiler
Only possible with unstable feature label -I-prioritize
it would be good to have an example which does not depend on external crates or macros here.
slightly minimized completely minimized: + incorrectly ignoring recursive definitions, writing a clean MVCE rn
constrains to , which gets ignored because of I am not totally sure how this all interacts, would have to look at the code, but it feels like the same root cause as
Change:
<ins> // issue-119209 fn main<'a>(_: &'a i32) -> &'a () { &() } //~ERROR `main` function return type is not allowed to have generic parameters </ins>

Discussion:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'Normalizing Alias(Weak, AliasTy { args: [ReBound(DebruijnIndex(0), BoundRegion { var: 0, kind: BrNamed(DefId(0:13 ~ 24C571BC08516AAF219327E12F0FEDBF5591EB2DFE1FD843CF7E2D7C1441FB55[8fdb]::main::'a), 'a) }), ReError], defid: DefId(0:9 ~ 24C571BC08516AAF219327E12F0FEDBF5591EB2DFE1FD843CF7E2D7C1441FB55[8fdb]::Foo) }) without wrapping in a '', 'thread 'rustc' panicked at 'Normalizing Alias(Weak, AliasTy { args: [ReBound(DebruijnIndex(0), BoundRegion { var: 0, kind: BrNamed(DefId(0:13 ~ 24C571BC08516AAF219327E12F0FEDBF5591EB2DFE1FD843CF7E2D7C1441FB55[8fdb]::main::'a), 'a) }), ReError], defid: DefId(0:9 ~ 24C571BC08516AAF219327E12F0FEDBF5591EB2DFE1FD843CF7E2D7C1441FB55[8fdb]::Foo) }) without wrapping in a '' 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: [checkmoditem_types] checking item types in top-level module [analysis] running analysis passes on this crate --
Regression in ping