jiebi/CodeConvo huggingface dataset:
Change:
use rustc_middle::ty::TypeVisitableExt; use rustc_middle::ty::{self, GenericArgsRef, InstanceDef, TyCtxt}; use rustc_session::Limit; <ins> use rustc_span::sym; </ins> // FIXME: check whether it is cheaper to precompute the entire call graph instead of invoking // this query ridiculously often.

Discussion:
Apply this patch: And you'll get this query cycle error: There's a strange call graph here; which is responsible for emitting string slicing panics uses panicky string slicing. From reading the code, I'm pretty confident that the infinite recursion case is actually impossible, but our query cycle detection doesn't know or care, and is supposed to handle this case.
The cycle detection probably doesn't understand intrinsic. The intrinsic is lowered in query, while cycle detection operates on .
That was my instinct as well. What's tripping me up mentally is that with this patch, I can without a cycle error: There's no inside of the cycle detection logic. I think there should be. But I also think that since the latest beta, we accidentally fixed this somehow?
Nightly reproducer:
Change:
let named_type_param_count = param_counts.types - has_self as usize - synth_type_param_count; let infer_lifetimes = <del> gen_pos != GenericArgPosition::Type && !gen_args.has_lifetime_params(); </del> <ins> (gen_pos != GenericArgPosition::Type || infer_args) && !gen_args.has_lifetime_params(); </ins> if gen_pos != GenericArgPosition::Type && !gen_args.bindings.is_empty() { Self::prohibit_assoc_ty_binding(tcx, gen_args.bindings[0].span);

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: the lifetime is correctly inferred when using Instead, this happened: I have to use one of the work arounds described in the linked code. Swap from GAT lifetime to the trait parameterized by a lifetime it works: <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Interested in fixing this. I think all we need to do is treat like other paths with elided lifetimes (e.g. ). you're the go-to person for GATs, right? If so, does that sound correct? Secondly I might also put up a PR that suggests adding when parsing since that's also what's wrong with the second solution. claim
ah yes, good catch, the second solution does work with . In the way I had originally encountered this it didn't work without more nightly features () - a GAT, on a trait, on a , which parametrized a trait. Which left the type alias way the only way around.
I don't know if I've looked at this code before. But seems about right. I'm wondering if something like works and there's just code somewhere that doesn't take into account that the associated type itself can have substs.
This might be a little bit difficult though. When using a concrete struck like , we can infer that lifetime because we know how it's used in the struct itself. With associated types, we don't know, necessarily. In a way, I would expect that to be somewhat opaque, tbh. I'm not sure how I feel about this tbh. If you can fix it, I'd probably want to get some second thoughts before merging.
Change:
resume_arg }; <ins> let storage_liveness: GrowableBitSet<Local> = self.storage_liveness[block].clone().unwrap().into(); for i in 0..self.always_live_locals.domain_size() { let l = Local::new(i); let needs_storage_dead = storage_liveness.contains(l) && !self.remap.contains_key(&l) && !self.always_live_locals.contains(l); if needs_storage_dead { data.statements .push(Statement { source_info, kind: StatementKind::StorageDead(l) }); } } </ins> self.suspension_points.push(SuspensionPoint { state, resume, resume_arg, drop, <del> storage_liveness: self.storage_liveness[block].clone().unwrap().into(), </del> <ins> storage_liveness, </ins> }); VariantIdx::new(state)

Discussion:
Reproduces with on commit Remove and add to get a lot of ICEs like this:
So, looks like we should either allow StorageLive on an already live local, or we need to ensure that all locals are explicitly marked StorageDead before returning. No idea how realistic it is to achieve the latter. Cc
Change:
LL |     union BeeWhereOutlivesAyTeeWhereDebug<'a, 'b, T> where 'b: 'a, T: Debug { |                                                            ^^^^^^^^ help: remove this bound <del> error: aborting due to 153 previous errors </del> <ins> error: aborting due to 154 previous errors </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: Rustfix will fail to apply this: ` So we need to extend span to include the as well? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The relevant code is in , with . The should be computed using in the loop, instead of crafting a specific computation. Likewise, should use method. If using those 2 methods from is not enough to solve the issue, those methods should perhaps be adapted.
claim
release-assignment Haven't been able to focus on this. Releasing assignment.
claim
Progress report: I'm working on it.
claim
Change:
#[inline] pub fn variant_range(&self, def_id: DefId, tcx: TyCtxt<'tcx>) -> Range<VariantIdx> { // FIXME requires optimized MIR <del> let num_variants = tcx.generator_layout(def_id).variant_fields.len(); </del> <ins> let num_variants = tcx.generator_layout(def_id).unwrap().variant_fields.len(); </ins> VariantIdx::new(0)..VariantIdx::new(num_variants) }

Discussion:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-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: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:
Change:
// Use an inherent impl so that imports are not required: #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> pub impl<T: Owned> Port<T> { fn recv(&self) -> T { port_recv(self) } fn try_recv(&self) -> Option<T> { port_try_recv(self) }

Discussion:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.
Change:
------------------------------------------n {}n ------------------------------------------n <del> n", expected, actual </del> <ins> diff:n ------------------------------------------n {}n", expected, actual, write_diff(expected, actual, 3), </ins> )); } }

Discussion:
Note: missing newline after is essential. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I've not been able to reproduce this on the latest nightly, I've bisected it to have been fixed in 2020-07-15 (report used 2020-07-11), probably by ; I've filed with a regression test.
Me neither.
Change:
<ins> use std::pin::Pin; use std::future::Future; fn main() {} fn await_on_struct_missing() { struct S; let x = S; x.await; //~^ ERROR no field `await` on type //~| NOTE unknown field //~| NOTE to `.await` a `Future`, switch to Rust 2018 //~| HELP set `edition = "2018"` in `Cargo.toml` //~| NOTE for more on editions, read https://doc.rust-lang.org/edition-guide } fn await_on_struct_similar() { struct S { awai: u8, } let x = S { awai: 42 }; x.await; //~^ ERROR no field `await` on type //~| HELP a field with a similar name exists //~| NOTE to `.await` a `Future`, switch to Rust 2018 //~| HELP set `edition = "2018"` in `Cargo.toml` //~| NOTE for more on editions, read https://doc.rust-lang.org/edition-guide } fn await_on_63533(x: Pin<&mut dyn Future<Output = ()>>) { x.await; //~^ ERROR no field `await` on type //~| NOTE unknown field //~| NOTE to `.await` a `Future`, switch to Rust 2018 //~| HELP set `edition = "2018"` in `Cargo.toml` //~| NOTE for more on editions, read https://doc.rust-lang.org/edition-guide } fn await_on_apit(x: impl Future<Output = ()>) { x.await; //~^ ERROR no field `await` on type //~| NOTE to `.await` a `Future`, switch to Rust 2018 //~| HELP set `edition = "2018"` in `Cargo.toml` //~| NOTE for more on editions, read https://doc.rust-lang.org/edition-guide } </ins>

Discussion:
Trivial example: Output on current nightly: Ideally the error message would suggest using the 2018 edition.
Part of
Change:
self.set_binding_parent_module(binding, module); self.update_resolution(module, ident, ns, |this, resolution| { if let Some(old_binding) = resolution.binding { <ins> if binding.def() == Def::Err { // Do not override real bindings with `Def::Err`s from error recovery. return Ok(()); } </ins> match (old_binding.is_glob_import(), binding.is_glob_import()) { (true, true) => { if binding.def() != old_binding.def() {

Discussion:
the code i tried: noticed there was a typo, fixed it, still getting an ICE i expected: cargo-generate/pull/135, to not compile and give an error about typo cargo-generate/pull/136, to compile (and no longer display 2018 warnings about path clarity) instead, what happened: system info:
i also get this on stable and earlier nightlies, if that is at all useful.
(also please feel free to let me know if i can provide any more info- this is my first time filing a compiler bug! thanks for all your hardwork and help <3)
Nominating -- we should keep focus on Rust 2018-related bugs like this, I think.
Did you? I mean, there is a typo, right? Do you mean, you expected a controller error? Specifically I see this in the diff: and I think it should be ?
I guess you are saying you get the same ICE from , which has a fix... did you try a cargo clean? (I'm wondering if it is related to incremental compilation.)
yeah, so i noticed the typo, and then fixed it (hence the 2 PRs- i included both on the offchance that there were 2 issues.) i expected the 2nd one to compile, and the first one (after i noticed the typo, to not compile but give an error re: the typo). i will run a cargo clean and see if it helps!
OK, thanks for the clarification.
just ran and then and have the same error message.
Fixed in
Change:
self.print_fn_full(sig, item.ident, &item.generics, &item.vis, body, &item.attrs); } ast::AssocItemKind::TyAlias(bounds, ty) => { <del> self.print_associated_type(item.ident, bounds, ty.as_deref()); </del> <ins> self.print_associated_type(item.ident, &item.generics, bounds, ty.as_deref()); </ins> } ast::AssocItemKind::Macro(mac) => { self.print_mac(mac);

Discussion:
The following code: is pretty printed as This presumably also affects procedural macros.
Are there tests intended for pretty printing? I got the impression that folder only tests specific features and bugs, not the form
Change:
<ins> #![crate_name = "foo"] #![feature(const_evaluatable_checked, const_generics)] #![allow(incomplete_features)] // make sure that `ConstEvaluatable` predicates dont cause rustdoc to ICE #77647 // @has foo/struct.Ice.html '//pre[@class="rust struct"]'  //      'pub struct Ice<const N: usize> where [(); N + 1]: ;' pub struct Ice<const N: usize> where [(); N + 1]:; </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. --: <details<summary<strongBacktrace</strong</summary<p</p</details
Related:
do you know what's going on here? The rustdoc code is
Yeah, that one's somewhat expected. adds predicates to , so we now have to deal with them in rustdoc, can fix this myself next week
I minimized the failure I'm seeing in rustdoc and it looks like it's this issue and not a separate one. Is there any workaround or is any expected to see this breakage w/rustdoc?
No, there's no workaround that I know of. I don't understand the implementation of const generics very well, nor does anyone else on the team.
Does anyone know what would be needed to fix this, or at least work around it enough to stop from crashing? (This is currently disabling for our project, which relies on some code.)
Change:
| LL |     B(isize, isize), |     --------------- similarly named tuple variant `B` defined here <ins> LL |     C(isize, isize, isize), LL |     D |     - `A::D` defined here </ins> ... LL |         A::D(_) => (), <del> |         ^^^- |            | |            help: a tuple variant with a similar name exists: `B` </del> <ins> |         ^^^^^^^ | help: use this syntax instead | LL |         A::D => (), |         ^^^^ help: a tuple variant with a similar name exists | LL |         A::B(_) => (), |            ^ </ins> error[E0023]: this pattern has 3 fields, but the corresponding tuple variant has 2 fields --> $DIR/pattern-error-continue.rs:17:9

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. -- The current output is: Ideally the output should look like: I'd like it to say "try to use a unit variant like "FarmAnimal::Cow" instead". For example, here's what happens if you use Tuple syntax instead of Struct syntax: So I'd like the new diagnostic to look something like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is an example Ferrous Systems uses in our trainings, and some of our participants have tripped over this lack of suggestion here. The compiler DOES provide diagnostics when you use a struct syntax instead of a tuple syntax.
Alternatively the help could suggest a more direct: "Remove the parenthesis here".
claim
I just wanted to mention , and I wanted to thank you personally for implementing this diagnostics improvement so quickly! Let me know if you have a blog or twitter you'd like us to link to (rather than your GH profile).
Hello, linking to my GH profile is fine. I did not know I would contribute to such an interesting learning experience. Anyway thank you for mentioning me in your blog post .
Change:
<ins> use crate::infer::error_reporting::hir::Path; </ins> use hir::def::CtorKind; use hir::intravisit::{walk_expr, walk_stmt, Visitor}; <ins> use hir::{Local, QPath}; </ins> use rustc_data_structures::fx::FxIndexSet; use rustc_errors::{Applicability, Diag}; use rustc_hir as hir; <ins> use rustc_hir::def::Res; use rustc_hir::MatchSource; use rustc_hir::Node; </ins> use rustc_middle::traits::{ IfExpressionCause, MatchExpressionArmCause, ObligationCause, ObligationCauseCode, StatementAsExpression,

Discussion:
The code below has superfluous semicolons in the branches of the if expression: The error message that results is: This can be confusing to beginners, who may not understand unit type. However, since the expressions and can be shown to have no side effects, the code (as is) can't be what the user intended. Could the compiler produce a more targeted error message that mentions the superfluous semicolon? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label T-compiler A-diagnostics D-newcomer-roadblock D-terse
claim
Thinking more about this, I don't think we should extend the "remove semicolon to make tail expression" suggestion to cover this case, since we don't know the expected type of at the point at which the suggestion would be made. For example, we don't make the suggestion to change to here: But that's just a guess based on my limited knowledge of type mismatch suggestions. Maybe someone else could weigh in?
Change:
# # If `change-id` does not match the version that is currently running, # `x.py` will prompt you to update it and check the related PR for more details. <del> change-id = 117435 </del> <ins> change-id = 116881 </ins> # ============================================================================= # Tweaking how LLVM is compiled

Discussion:
The profile is intended not just for people working on LLVM itself, but also anyone who touches codegen but not LLVM. For example, anyone who modifies or is only changing the IR we send to LLVM, not LLVM itself. We should keep on for them but not for , but ideally we wouldn't build LLVM from source if it's unmodified. points out some things that we should fix before enabling that option by default for the profile: Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Should all 3 tasks be in one PR or is it 3 separate PR's?
I'd say it depends how challenging they are - if it's simple to fix all three in one PR that seems fine, but if it takes a more than a day to do one of the tasks, it probably makes sense to open a PR for it early.
I think I can tackle points 1 and 3 by tonight so I'll make that into one PR. I'll open a separate PR for the second point, since I think it has more work involved, if that's alright :)
release-assignment
Change:
<del> error: expected one of `!`, `,`, or `::`, found `(` --> $DIR/issue-54516.rs:4:58 </del> <ins> error: casts cannot be followed by a function call --> $DIR/issue-54516.rs:4:20 </ins> | LL |     println!("{}", std::mem:size_of::<BTreeMap<u32, u32>>()); <del> |                            -                             ^ expected one of `!`, `,`, or `::` </del> <ins> |                    ^^^^^^^^-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </ins> |                            | |                            help: maybe write a path separator here: `::` | = note: `#![feature(type_ascription)]` lets you annotate an expression with a type: `<expr>: <type>` = note: see issue #23416 <https://github.com/rust-lang/rust/issues/23416> for more information <del> error: aborting due to previous error </del> <ins> error[E0423]: expected value, found module `std::mem` --> $DIR/issue-54516.rs:4:20 | LL |     println!("{}", std::mem:size_of::<BTreeMap<u32, u32>>()); |                    ^^^^^^^^- help: maybe you meant to write a path separator here: `::` |                    | |                    not a value error[E0412]: cannot find type `size_of` in this scope --> $DIR/issue-54516.rs:4:29 | LL |     println!("{}", std::mem:size_of::<BTreeMap<u32, u32>>()); |                            -^^^^^^^ not found in this scope |                            | |                            help: maybe you meant to write a path separator here: `::` error: aborting due to 3 previous errors Some errors have detailed explanations: E0412, E0423. For more information about an error, try `rustc --explain E0412`. </ins>

Discussion:
Summary: Parsing leads to the error: It is currently impossible for a cast expression to have a trailing index expression without surrounding the cast expression by parenthesis. This however seems to be a parser limitation, not a grammar limitation. As currently the macro language guarantees that ty/path expressions can be followed by a "[", this seems like a bug in the parser to me, as it seems to be parsing it as which makes no grammatical sense, compared to parsing it as (value as Type)[index] which should be valid if I read the lexical structure specification correctly.
I think it's parsed correctly, but should get a tailored error message to suggest surrounding the cast with parens.
Considering that a trailing "[" is never valid in the type syntax (otherwise macros break) and the fact that and variants are perfectly legal (even which is another symbol that occurs in type syntax). But if a tailored error message will be made instead, then this should also include other postfix operators like which are currently rejected even though technically being legal by the lexical grammar specification. (another one is the proposed "?" operator)
This is still lacking a tailored error message, and as far as I know no movement has been made here.
Submitted a pull request to fix this!
Thanks!
Change:
if component_start < bytes.len() { let to_hash = &bytes[component_start..]; <ins> chunk_bits = chunk_bits.wrapping_add(to_hash.len()); chunk_bits = chunk_bits.rotate_right(2); </ins> h.write(to_hash); <del> bytes_hashed += to_hash.len(); </del> } <del> h.write_usize(bytes_hashed); </del> <ins> h.write_usize(chunk_bits); </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 : I expected to see this happen: Different hashes since these represent different paths. Instead, this happened: The hashes are equal. This makes sense for redundant path separators (e.g. ), but not for all path separators. I a test case to the standard library — which fails. The relevant code is probably around which last changed in If I revert that commit, the error persists. It looks like the relevant change is , if I revert that commit the test passes. This was the solution I opted for downstream (in ) before performing this investigation. I tested this on stable (1.79.0), nightly (1.81.0), and on (). Discovered via
is not a cryptographic hash, so it does not promise a collision probability so low that practically all inputs map to distinct outputs. So if the correctness of your program relies on the absence of collisions then it's your program that's wrong, not . There may be some quality-of-implementation argument about avoiding collisions for data patterns that are likely to coexist. I'm not sure if it is the case here, I'll have to think about it. And even if it is then there also is the matter of making such a avoidance fast. The current code is optimized for speed.
I think that's a fair point, but the current implementation already goes out if its way to create equal hashes for paths like and — why is and different? It seems like a very surprising collision for a user to encounter. Thanks for taking a look!
The difference is that is a companion for . If things compare equal then they must hash the same because that's what hashmaps rely on. and do compare equally because normalizes the dot away. Therefore they must hash equally, which is why Hash must spend effort on that. Things comparing inequal does not require the Hash to be different. Instead it's only a matter of quality-of-implementation whether they produce distinct hashes, not a matter of correctness.
That's a great point, thanks for clarifying. I agree this is not a "correctness" problem, but more of a practical consideration for the hashing algorithm.