jiebi/CodeConvo huggingface dataset:
Change:
self.check_or_expected(self.token.can_begin_const_arg(), TokenType::Const) } <del> fn check_inline_const(&mut self) -> bool { self.check_keyword(kw::Const) && self.look_ahead(1, |t| match t.kind { </del> <ins> fn check_inline_const(&self, dist: usize) -> bool { self.is_keyword_ahead(dist, &[kw::Const]) && self.look_ahead(dist + 1, |t| match t.kind { </ins> token::Interpolated(ref nt) => matches!(**nt, token::NtBlock(..)), token::OpenDelim(DelimToken::Brace) => true, _ => false,

Discussion:
As soon as I've seen the new inline_const feature, I've tried to find some use cases for it in my code, and I did find only very few of them, unfortunately, and one of the two uses cases could be reduced to this: That gives errors: So I am not sure if this is a bug report or an enhancement request.
Note that this does work in expressions ():
Support for ranges in patterns ( or ) needs to be separately, to and respectively.
Ohh I've just realized that we had this issue opened, I've fixed this in Going to adjust description of the PR accordingly so it closes this issue when merged.
Change:
<ins> mod foo { pub fn r#let() {} pub fn break() {} //~ ERROR expected identifier, found keyword `break` } fn main() { foo::let(); //~ ERROR expected identifier, found keyword `let` r#break(); //~ ERROR cannot find function `break` in this scope } </ins>

Discussion:
Right now the raw ident suggestion when using a reserved keyword somewhere where it is not allowed is context free, leading to misleading output: The parser should perform some lookahead to see if it could actually continue parsing if a raw identifier had been supplied in its place and if so, only then suggest raw idents.
Or we shouldn't suggest using raw identifiers if we cannot do that easily and reliably.
Change:
match *self { LintSource::Default => symbol::kw::Default, LintSource::Node(name, _, _) => name, <del> LintSource::CommandLine(name) => name, </del> <ins> LintSource::CommandLine(name, _) => name, </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. --Simply building the rusty-xinput crate in the dependency chain seems to have triggered it. See <!-- 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. --Rust version from the build <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pI'm sorry - I don't have access to a windows environment to reproduce this! </p</details
I think is the cause, cc Note that you should set to reproduce it. I don't feel this is Windows-specific but it just depends on the Windows-specific crate, marking . <details<summary<strongBacktrace</strong</summary</details
MCVE: run on:
Assigning and removing .
I got the same error on Linux while compiling lazy_static. https://cirrus- .
This will be fixed by
Change:
let body = self.tcx.hir().body(anon_const.body); // Create a new function context. <del> let fcx = FnCtxt::new(self, self.param_env, body.value.hir_id); </del> <ins> let fcx = FnCtxt::new(self, self.param_env.with_const(), body.value.hir_id); </ins> crate::check::GatherLocalsVisitor::new(&fcx).visit_body(body); let ty = fcx.check_expr_with_expectation(&body.value, expected);

Discussion:
Given the following code (): The current output is: Ideally, the output should be the same as when such a call is made in a item: ... which can be improved further with the suggestion given in : modify labels: +A-const-eval +A-traits +D-confusing +D-terse +F-consttraitimpl +F-inlineconst <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
match *ext { MultiModifier(ref mac) => { <del> let meta = attr.parse_meta(self.cx.parse_sess).ok()?; </del> <ins> let meta = attr.parse_meta(self.cx.parse_sess) .map_err(|mut e| { e.emit(); }).ok()?; </ins> let item = mac.expand(self.cx, attr.span, &meta, item); Some(kind.expect_from_annotatables(item)) } MultiDecorator(ref mac) => { let mut items = Vec::new(); <del> let meta = attr.parse_meta(self.cx.parse_sess).ok()?; </del> <ins> let meta = attr.parse_meta(self.cx.parse_sess) .expect("derive meta should already have been parsed"); </ins> mac.expand(self.cx, attr.span, &meta, &item, &mut |item| items.push(item)); items.push(item); Some(kind.expect_from_annotatables(items))

Discussion:
Hi! I'm trying to compile my Rocket/Diesel/R2d2 task management project, which has previously successfully compiled, and when I add the newest piece which relies on macros in some new/different way (sorry for vague, I'm new to rust) it starts failing to compile. Looking at the backtrace, the error seems to be in MacroExpander::expandinvoc. I expect it to have the same behavior as the simpler version of the route: which warns about unused query result on compile but successfully runs, builds the NewTask struct from url components, and inserts it into the database. it fails to compile during cargo run, and the same exact error shows during cargo check. I've pasted the whole command with outputs here: Check out my project's for the exact code where I get the bug. Check out my project's master branch at commit to see the functional version (requires a local postgresql instance and a DATABASEURL env variable in a env file).
I minimized down to nothing but 14 looping macros in order to squarely place the blame on a single culprit once and for all: A function that just loops surely cannot be responsible for dropping a , so the must be a bug in rustc. (I still rather doubt it is in though, but rather, in a function that gets inlined into it)
So... I mentioned in the other issue how terrifying of a concept I thought was. For the uninitiated, is a type alias for a with a in its variant, which acts like a ticking timebomb; it explodes if the error is ever dropped. Simply put, has some methods that you must never call on a . Do you see it? :wink:
Ha! Thank you for the digging That stray is really cheeky, ain't it?
I'll probably submit a PR; I'm just browsing around the existing test cases for plugins trying to glean "best practices." (I'm also trying to see if there's any test case that causes the other in the branch to blow up. I don't think there is since it appears that the full attribute gets parsed before it tries to expand .)
Change:
PRINT-BANG INPUT (DISPLAY): FirstStruct PRINT-BANG INPUT (DEBUG): TokenStream [ <del> Group { delimiter: None, stream: TokenStream [ Ident { ident: "FirstStruct", span: $DIR/auxiliary/nested-macro-rules.rs:16:14: 16:25 (#7), }, ], span: $DIR/auxiliary/nested-macro-rules.rs:9:30: 9:35 (#6), </del> <ins> Ident { ident: "FirstStruct", span: $DIR/auxiliary/nested-macro-rules.rs:16:14: 16:25 (#7), </ins> }, ] PRINT-ATTR INPUT (DISPLAY): struct FirstAttrStruct {}

Discussion:
As of , some of our code utilizing macros in [] started to fail to compile. The code that is failing is some macro magic for making nice pin name aliases for microcontrollers, so it's not surprising that broke it. I see that some other repos were broken as well and that helped fix it, but I'm really not sure how to do the fix in our repo. To reproduce: clone the [] repo I expect this to compile properly like on stable, instead it fails to compile with: It most recently worked on: Regressed to with () : modify labels: +regression-from-stable-to-nightly -regression-untriaged []:
Fixed in
Thanks for the quick fix!
Change:
} } <ins> // The placeholder expander gives ids to statements, so we avoid folding the id here. </ins> // We don't use `assign_id!` - it will be called when we visit statement's contents // (e.g. an expression, item, or local) <del> let res = noop_flat_map_stmt(stmt, self); </del> <ins> let ast::Stmt { id, kind, span } = stmt; let res = noop_flat_map_stmt_kind(kind, self) .into_iter() .map(|kind| ast::Stmt { id, kind, span }) .collect(); </ins> self.cx.current_expansion.is_trailing_mac = false; res

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. --Context: "regression" caught by future-proofing CI from After working on reducing the code, I've identified the root cause of the ICE. For context: this patterns stem from "old" Rust code wanting to support proc-macros emitting item definitions in "statement" position for Rust: the trick is to use the to wrap an item-defs-emitting proc-macro call inside a function so that Rust doesn't interpret it as a statement, refusing the then-unstable stmt-emitting proc-macro call (). <!-- 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. --: Bonus: the ICE seems to have been introduced in between today's () and yesterday's nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailscc I suspect this is up your alley
searched nightlies: from nightly-2021-08-01 to nightly-2021-08-10 regressed nightly: nightly-2021-08-07 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: </details
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +A-macros
Thanks nice job
Change:
|         ^^^^^^^^^^^^^ | = note: ...which again requires processing `Y::A::{{constant}}#0`, completing the cycle <del> note: cycle used when const-evaluating `Y::A::{{constant}}#0` </del> <ins> note: cycle used when processing `Y::A::{{constant}}#0` </ins> --> $DIR/issue-23302-2.rs:4:9 | LL |     A = Y::B as isize,

Discussion:
Super-High-Level Instructions: Replace with And then follow up by making sure that the compiler doesn't ICE anywhere (e.g. during MIR building). It should probably "just work" nowadays. A crater run isn't necessary, as this will only ICE if an error wasn't handled properly. Successfully compiling code is unaffected.
I took a look at this and all tests seem fine in just dropping in the code you have above as you said. However I just wanted to check is no longer needed? Pretty unfamiliar with this code so I wanted to confirm before submitting as it's not explicitly mentioned in the other thread that it should be removed.
Yes that should be removed, too. It will automatically be run when fetching the MIR of the current constant.
ok, cool! I have filed a PR for this in Let me know if anything needs to be updated!
Change:
[tuples]: primitive-types.html#tuples [enums]: enums.html <ins> # Ignoring bindings You can use `_` in a pattern to disregard the value. For example, here’s a `match` against a `Result<T, E>`: ```rust # let some_value: Result<i32, &'static str> = Err("There was an error"); match some_value { Ok(value) => println!("got a value: {}", value), Err(_) => println!("an error occurred"), } ``` In the first arm, we bind the value inside the `Ok` variant to `value`. But in the `Err` arm, we use `_` to disregard the specific error, and just print a general error message. `_` is valid in any pattern that creates a binding. This can be useful to ignore parts of a larger structure: ```rust fn coordinate() -> (i32, i32, i32) { // generate and return some sort of triple tuple # (1, 2, 3) } let (x, _, z) = coordinate(); ``` Here, we bind the first and last element of the tuple to `x` and `z`, but ignore the middle element. </ins> # Mix and Match Whew! That’s a lot of different ways to match things, and they can all be

Discussion:
Currently there isn't documentation explaining how the character works
Are you referring to its usage or implementation. Currently the book provides a very brief description of what _ does, however I could write up something slightly more detailed if desired. (see below):
Hmm, the conversation that starts here might be interesting
Change:
// extra type arguments present. A suggesting to replace the generic args with // associated types is already emitted. already_has_generics_args_suggestion = true; <del> } else if let (Ok(snippet), false) = (tcx.sess.source_map().span_to_snippet(*span), dupes) </del> <ins> } else if let (Ok(snippet), false, false) = (tcx.sess.source_map().span_to_snippet(*span), dupes, shadows) </ins> { let types: Vec<_> = assoc_items.iter().map(|item| format!("{} = Type", item.name)).collect();

Discussion:
Given the following code: The current output is: is wrong, specifying another isn't going to fix the problem. Writing just has a suggestion where`, which is good, but the concrete syntax would be nice. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We probably should modify E0191 to hint that an supertrait's associated type is shadowed. I think E0719 here is fine to keep as-is, imo.
I agree the message for E0719 is good as-is.
Is this issue fixed ? If not can I take this up, please. Also how exactly should E0191 be modified. Imo, I don't think E0191 should pop up in this case as E0719 conveys the message.
claim
claim
Ask for help How do I specify the association type of supertrait with the same name? In other words, is there an easy way to modify the code in the issue to make it pass compilation? Here's my clumsy way of creating a new trait.
Is this issue still open? If so I would like to take a crack at it.
If you can still reproduce it, then yes indeed. assign
Error: Parsing assign command in failed: ...'zyDutchman' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I have now a hint about the shadowing: But I am not quite sure about what to do about the actual message. Do we want to suggest renaming to something else Or do we want to suggest the work-around by
If the trait is local, then we could suggest renaming it. It's not required to be super specific here--we could just note the conflict to make the user aware of it, for example.
I have updated the help message so that this case: gives this error message: The rename help message is emitted for both the super trait and the subtrait, if they are local. I think I am ready to make a merge request, or does somebody have something else to add?
I recommend you to just open a PR. Any further discussions can happen over there :)
Change:
} } else { // Pattern has wrong number of fields. <del> self.e0023(pat.span, res, qpath, subpats, &variant.fields, expected); </del> <ins> self.e0023(pat.span, res, qpath, subpats, &variant.fields, expected, had_err); </ins> on_error(); return tcx.types.err; }

Discussion:
Source code:
Please provide the source code needed to reproduce this (or preferably a reduced version of that)
Sourced code provided at the end of the document. I'm willing to provide more info if needed.
Reconstructed from first principles:
The problem occurs here:
triage: has PR. P-high, removing nomination.
Change:
_ => elf::ELFOSABI_NONE, }; let abi_version = 0; <ins> add_gnu_property_note(&mut file, architecture, binary_format, endianness); </ins> file.flags = FileFlags::Elf { os_abi, abi_version, e_flags }; Some(file) }

Discussion:
I noticed that the synthetic object files in will disable the IBT (on x86, enabled by ) and BTI (on AArch64, enabled by ) features because the object files are missing sections indicating that the object file is compatible with those features. Normally, if an object file is missing a section, the linker will disable all such features, on the assumption that the object file is not compatible. This issue is reproducible on the master branch (slightly awkwardly because many distros don't ship IBT-enabled files, and neither is it enabled in Rust's standard library by default): In another directory: After commenting out the line of code that adds to the link: the binary has the correct property note: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I can think of three possible solutions: the appropriate GNU property section into the synthetic object file according to the passed flags. This would work, but it could easily get out of sync with the GNU properties produced by the compiler. a change in linker behavior so that the GNU properties are not affected by object files that do not contain sections. This would make sense because an object file without sections cannot on its own affect the contents of the final binary, which means that it cannot cause the binary to become {BTI,IBT}-incompatible. a linker feature that implements equivalent behavior to the synthetic object file, e.g. a flag that is equivalent to but does not inhibit , and then use that on ELF platforms instead of the synthetic object file if the linker supports it. may have thoughts on this.
Option 3 is not enough to solve this. The crate metadata object is also produced without these properties and can't be replaced with a linker option. Option 2 will take a long time before everyone has a new linker and needs coordination with , , and As such option 1 makes most sense to me.
Option 2 needs coordination among linker maintainers and it does impose some complexity to linkers. And as mentioned, it requires very new linkers. If Rust is open to 1, I think it is a great direction.
claim
Change:
error: arguments to `macro_use` are not allowed here <del> --> $DIR/issue-43106-gating-of-macro_use.rs:6:1 </del> <ins> --> $DIR/issue-43106-gating-of-macro_use.rs:12:17 </ins> | <del> LL | #![macro_use(my_macro)] | ^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> LL |     mod inner { #![macro_use(my_macro)] } |                 ^^^^^^^^^^^^^^^^^^^^^^^ </ins> error: arguments to `macro_use` are not allowed here --> $DIR/issue-43106-gating-of-macro_use.rs:9:1

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. --Found an ICE with when trying to use it in the standard library (). cc . <!-- 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
I can hit an additional ICE by using an unknown attribute instead of a valid one: <details<summary<strongBacktrace</strong</summary<p</p</detailsI don't really think it's useful for this issue though, since it's a delayed error.
Fixed in
Change:
if associated_types.values().all(|v| v.is_empty()) { return; } let tcx = self.tcx(); // FIXME: Marked `mut` so that we can replace the spans further below with a more // appropriate one, but this should be handled earlier in the span assignment.

Discussion:
Given the following code: The current output is: is wrong, specifying another isn't going to fix the problem. Writing just has a suggestion where`, which is good, but the concrete syntax would be nice. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We probably should modify E0191 to hint that an supertrait's associated type is shadowed. I think E0719 here is fine to keep as-is, imo.
I agree the message for E0719 is good as-is.
Is this issue fixed ? If not can I take this up, please. Also how exactly should E0191 be modified. Imo, I don't think E0191 should pop up in this case as E0719 conveys the message.
claim
claim
Ask for help How do I specify the association type of supertrait with the same name? In other words, is there an easy way to modify the code in the issue to make it pass compilation? Here's my clumsy way of creating a new trait.
Is this issue still open? If so I would like to take a crack at it.
If you can still reproduce it, then yes indeed. assign
Error: Parsing assign command in failed: ...'zyDutchman' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I have now a hint about the shadowing: But I am not quite sure about what to do about the actual message. Do we want to suggest renaming to something else Or do we want to suggest the work-around by
If the trait is local, then we could suggest renaming it. It's not required to be super specific here--we could just note the conflict to make the user aware of it, for example.
I have updated the help message so that this case: gives this error message: The rename help message is emitted for both the super trait and the subtrait, if they are local. I think I am ready to make a merge request, or does somebody have something else to add?
I recommend you to just open a PR. Any further discussions can happen over there :)
Change:
); this.expr(fn_decl_span, async_body, ThinVec::new()) }); <del> hir::ExprKind::Closure(capture_clause, fn_decl, body_id, fn_decl_span, None) }) </del> <ins> body_id }); // We need to lower the declaration outside the new scope, because we // have to conserve the state of being inside a loop condition for the // closure argument types. let fn_decl = self.lower_fn_decl(&outer_decl, None, false, None); hir::ExprKind::Closure(capture_clause, fn_decl, body_id, fn_decl_span, None) </ins> } /// Destructure the LHS of complex assignments.

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
Doesn't ICE on stable or beta label: regression-from-stable-to-nightly
searched nightlies: from nightly-2020-11-25 to nightly-2020-11-29 regressed nightly: nightly-2020-11-27 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: </detailsMaybe ?
Assigning and removing as in the prioritization working group.
- would you be up for fixing this bug or temporarily reverting PR presuming it is the cause?
Change:
let Some(assoc_ty_did) = self.lookup_assoc_ty(assoc_ident, hir_ref_id, span, impl_) else { continue; }; <del> // FIXME(inherent_associated_types): This does not substitute parameters. let ty = tcx.type_of(assoc_ty_did); </del> <ins> let item_substs = self.create_substs_for_associated_item( span, assoc_ty_did, assoc_segment, adt_substs, ); let ty = tcx.bound_type_of(assoc_ty_did).subst(tcx, item_substs); </ins> return Ok((ty, DefKind::AssocTy, assoc_ty_did)); } }

Discussion:
<details<summary<bbacktrace</b</summary</details<details<summary<bfull stderr (two panics / backtraces)</b</summary</details: label requires-nightly A-associated-items F-inherentassociatedtypes
Context: The recent PR implemented the resolution of inherent associated types but it appears that parameter substitution was overlooked.
Change:
ty::ConstKind::Value(val_val) => val_val, }; // Other cases need layout. <del> let layout = from_known_layout(layout, || self.layout_of(val.ty))?; </del> <ins> let layout = from_known_layout(self.tcx.tcx, layout, || self.layout_of(val.ty))?; </ins> let op = match val_val { ConstValue::ByRef { alloc, offset } => { let id = self.tcx.alloc_map.lock().create_memory_alloc(alloc);

Discussion:
The following ICEs (example by shows This means that is wrong. It might be possible to also trigger this without nightly features through const_prop.
Baring a way to do the proper structural subtyping check, the only solution I see is to go back to comparing layouts in all cases (as a fallback after types mismatch) -- but does not like this, as far as I recall. Any other proposals?