jiebi/CodeConvo huggingface dataset:
Change:
*/ }; <del> let metadata = if let Some(metadata_def_id) = tcx.lang_items().metadata_type() { </del> <ins> let metadata = if let Some(metadata_def_id) = tcx.lang_items().metadata_type() // Projection eagerly bails out when the pointee references errors, // fall back to structurally deducing metadata. && !pointee.references_error() { </ins> let metadata = tcx.normalize_erasing_regions( cx.param_env(), tcx.mk_projection(metadata_def_id, [pointee]),

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. --This is a fuzzed test case, found with and minimized with , but found no similar issues. <!-- 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 --
searched nightlies: from nightly-2021-01-01 to nightly-2023-03-12 regressed nightly: nightly-2023-01-05 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsNote that this requires edition 2015/2018, as edition 2021 hard errors on the bare trait object before ever getting to layout code. cc
claim
Change:
.expect("cargo fmt expected to build - essential tool"); let mut tarball = Tarball::new(builder, "rustfmt", &target.triple); tarball.set_overlay(OverlayKind::Rustfmt); <ins> tarball.is_preview(true); </ins> tarball.add_file(rustfmt, "bin", 0o755); tarball.add_file(cargofmt, "bin", 0o755); tarball.add_legal_and_readme_to("share/doc/rustfmt");

Discussion:
It should not be possible that clippy component is missing since we are gating on it in CI..? cc
I think this is a rustup bug somehow, it's looking specifically for : I can back this out to give rustup time to fix it in a new release, this wasn't an urgent fix. I want to spend another few minutes investigating first though.
I don't think rustup's rename system is designed to allow changing the name of a component. contains more information about how and why this was done.
says I need at a minimum to keep the key for clippy-preview. I will try to test that out today but I don't have permissions for a dist-static build and it might take me a bit so I'll put up a revert in the meantime.
I'm happy to run dev-static builds as needed, but I agree that a revert is appropriate for the time being. Please feel free to poke on Zulip if you need a quick review, etc. I'm a little surprised our testing in didn't catch this -- let's make sure we understand how to test it in the future.
what went wrong in is that worked before and after, but running before and after did not. I'll make sure to test that in any future PR.
Change:
<ins> // min-llvm-version: 15.0.0 // ignore-debug: The debug assertions get in the way // compile-flags: -O #![crate_type = "lib"] // There should be no calls to panic / len_mismatch_fail. #[no_mangle] pub fn test(a: &mut [u8], offset: usize, bytes: &[u8]) { // CHECK-LABEL: @test( // CHECK-NOT: call // CHECK: call void @llvm.memcpy // CHECK-NOT: call // CHECK: } if let Some(dst) = a.get_mut(offset..offset + bytes.len()) { dst.copy_from_slice(bytes); } } </ins>

Discussion:
In code like the following, the compiler misses a possible optimization: in , the length of is equal to the length of , yet the compiler generates a call to . The compiler knows the lengths are equal (and thus, the panic is unreachable), because the following snippet optimizes the panic away: This is a regression between rustc versions 1.51 and 1.52.
label I-slow, E-needs-bisection
This seems to be fixed on nightly. label E-needs-test Bisection would still be interesting IMO, both for the regression and the fix.
Alright, that’s pretty boring in terms of rustc-bisection: it was fixed by (Update to LLVM 15), and it regressed in which includes (Upgrade[^1] to LLVM 12). label -E-needs-bisection, +A-llvm. [^1]: what’s up with the inconsistent naming, upgrade vs. update?
Change:
<ins> error[E0412]: cannot find type `Foo` in this scope --> $DIR/import-alias-issue-121168.rs:11:12 | LL |     let _: Foo<i32> = todo!(); |            ^^^ not found in this scope | help: consider importing this struct | LL + use nice_crate_name::Foo; | error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0412`. </ins>

Discussion:
Some build environments (e.g. Chromium (), Bazel) may generate crate names based on names of build targets. While this results in globally-unique () crate names, it results in long and quite unwieldy crate names. Both Chromium and Blaze provide a macro to help working with such crate names: The macro usage above expands to something like: Unfortunately, it seems that some diagnostics keep referring to the long and unwieldy name. () see () globally-unique crate names = within a given build tree No response More detailed repro can be found below:
Is this something worth fixing? Is the original crate name worth preferring over the aliased name in some scenarios?
BTW: I also want to note/highlight that I am not able to repro the problem without using . For example (same files):
/cc
Change:
finish_fn(&fcx, bcx, sig.output); <del> llfn </del> <ins> (llfn, method_bare_fn_ty) </ins> } /// Creates a returns a dynamic vtable for the given type and vtable origin.

Discussion:
Discovered this ICE in the rollup that I'm preparing:
In Grust, I tried to change to: The crate compiles without an issue, but compiling another crate where this is used results in an ICE that looks to be this one.
Looks like I missed a case in
Nominating for 1.0 beta.
Are there any known workarounds for this problem? I ran into this in a hard way trying to update to the newest nightlies.
not sure, I'll try to get a PR up today
a new type wrapper around the object would probably work, ping me on irc () for more details
I just wanna run iron example on MAC 10.10 with rust-nightly, the same error occurs, I don't know if it's of the same case: error: internal compiler error: static call to invalid vtable: VtableObject(VtableObject(object_ty=error::Error + 'static))
This is also blocking Iron, which itself compiles well, but using the crate fails:
Fix in , sorry for the delay.
thanks for the work! I pulled your PR and built with it, and my code compiles again. Hooray!
Change:
self.bump(); // `in` let path = self.parse_path(PathStyle::Mod)?; // `path` self.expect(&token::CloseDelim(Delimiter::Parenthesis))?; // `)` <del> let vis = VisibilityKind::Restricted { path: P(path), id: ast::DUMMY_NODE_ID }; </del> <ins> let vis = VisibilityKind::Restricted { path: P(path), id: ast::DUMMY_NODE_ID, shorthand: false, }; </ins> return Ok(Visibility { span: lo.to(self.prev_token.span), kind: vis,

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: it to print . Instead, this happened: it prints . <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.62.1 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-beta -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Similar effect can already be observed on stable too prints already. But it is indeed a (small?) behavior change in this beta for the case.
I would expect to see this issue in 2020, but not now when we are collecting tokens in (almost) all cases instead of converting them from AST. Apparently for visibilities they are collected incorrectly for some reason. cc (in case you have time for this)
bisection points to searched nightlies: from nightly-2022-01-01 to nightly-2022-08-03 regressed nightly: nightly-2022-05-24 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsThe commit is a rollup so I think_ it's in cc ?
Without even looking at the rest of the rollup, it's definitely my PR. Short of storing whether was used, I'm not sure what could be done.
This will slip into 1.63.

I'll work on this this evening to get it resolved quickly, even if it is too late to patch the beta. I don't think it'll be too difficult.
PR is up: . This also fixes to be , which is certainly better than the status quo of .
Change:
} else { self.misc(cause_span) }; <del> self.demand_eqtype_with_origin(&cause, expected, actual).map(|mut err| err.emit()); </del> <ins> self.demand_eqtype_with_origin(&cause, expected, actual) </ins> } <ins> pub fn demand_eqtype_pat( &self, cause_span: Span, expected: Ty<'tcx>, actual: Ty<'tcx>, match_expr_span: Option<Span>, ) { self.demand_eqtype_pat_diag(cause_span, expected, actual, match_expr_span) .map(|mut err| err.emit()); } </ins> pub fn demand_coerce(&self, expr: &hir::Expr,

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:
<ins> // test for suggestion on fieldless enum variant #[derive(PartialEq, Debug)] enum FarmAnimal { Worm, Cow, Bull, Chicken { num_eggs: usize }, Dog (String), } fn what_does_the_animal_say(animal: &FarmAnimal) { let noise = match animal { FarmAnimal::Cow(_) => "moo".to_string(), //~^ ERROR expected tuple struct or tuple variant, found unit variant `FarmAnimal::Cow` FarmAnimal::Chicken(_) => "cluck, cluck!".to_string(), //~^ ERROR expected tuple struct or tuple variant, found struct variant `FarmAnimal::Chicken` FarmAnimal::Dog{..} => "woof!".to_string(), _ => todo!() }; println!("{:?} says: {:?}", animal, noise); } fn main() {} </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. 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> error[E0277]: the trait bound `UnconstDrop: Drop` is not satisfied --> $DIR/const-block-const-bound.rs:14:11 | LL |         f(UnconstDrop); |         - ^^^^^^^^^^^ the trait `Drop` is not implemented for `UnconstDrop` |         | |         required by a bound introduced by this call | note: required by a bound in `f` --> $DIR/const-block-const-bound.rs:4:15 | LL | const fn f<T: ~const Drop>(x: T) {} |               ^^^^^^^^^^^ required by this bound in `f` help: consider introducing a `where` bound, but there might be an alternative better way to express this requirement | LL | fn main() where UnconstDrop: Drop { |           +++++++++++++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

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:
lint: &'static lint::Lint, source_info: SourceInfo, message: &'static str, <del> panic: AssertKind<ConstInt>, </del> <ins> panic: AssertKind<impl std::fmt::Debug>, </ins> ) -> Option<()> { let lint_root = self.lint_root(source_info)?; self.tcx.struct_span_lint_hir(lint, lint_root, source_info.span, |lint| {

Discussion:
UPDATE: MCVE can be found . Nightly compilation error due to rustc bug I tried this code: I expected to see this happen: explanation Successful compilation. Instead, this happened: tells to report a bug, see backtrace. : Reproduce with (1st update) <details<summaryBacktrace</summary<p</p</details
cc
Also occured with
I'm getting this when I try to repro: On a side note, are there any cargo feature flags I can pass to cut down on how much stuff is being compiled? Compiling 900 crates to get a repo is quite a lot
Also occured with just now.
mmh try with commit hash ? (for )
updated script:
Yeah, sorry for that. One of the difficulties of working with a big framework like Substrate. I'll see if I can narrow it down more.
That did it! Thank you
Some with the same issue (a different chain also using Substrate) found out that apparently works.
Seems is the cause, marking as .
Here's a smaller repro (at least in terms of how much code is built: 33 crates instead of a few hundred):
just confirmed that it does not occur with
I have a minimal repro:
Wild guess: erases the local before we are able to emit the diagnostic message.
I seem to be getting a similar error again on a more current nightly (). Should I open a new issue or do we just reopen this one?
This is still broken. I'm pretty confused because running the test you in on the shows that it ICEs. Is the test not actually working for some reason? Edit: Does that test need in order to actually check the body of those functions since they are uncalled from ?
Assigning as and removing I-prioritize.
Hi and have either of you had a chance to upgrade to a recently nightly? I just wanted to confirm this is fixed for you.
I've updated to rust version 1.47.0-nightly ( 2020-07-22), and tried compiling the crate which was triggering this ICE (). I no longer encounter an ICE, the crate compiles successfully.
I can confirm is not throwing ICE :+1:
Great, thank you!
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::collections::HashMap; fn copy<T: Copy>(&x: &T) -> T { x } fn main() { let arr = [(1i, 1u), (2, 2), (3, 3)]; let v1: Vec<&_> = arr.iter().collect(); let v2: Vec<_> = arr.iter().map(copy).collect(); let m1: HashMap<_, _> = arr.iter().map(copy).collect(); let m2: HashMap<int, _> = arr.iter().map(copy).collect(); let m3: HashMap<_, uint> = arr.iter().map(copy).collect(); } </ins>

Discussion:
This is a minimal reproduction of something I saw when updating some of my projects to use . This manifested in other ways in larger programs, ICEing in one case: This can be reproduced by taking and changing lines 592 and 598 of to use partial type hints. cc
Maybe partial type hints need feature gating.
I knew that feature was too easy to implement... Lets see if I can find the cause.
Well, I'm not sure how to fix this. This inference error implies to me that partial type hints actually don't work at all for the case right now, and the existing tests didn't catch it because they inferred right from both sides. According to this is because the in and don't have any direct constrain to be identical. (Which would be possible with HKT though) While there is a , this link is apparently not currently considered, leading to the inference failure here. cc
Any idea why there are so many stacks in the backtrace? Does a non- build not contain enough debug info for libbacktrace to work off of?
I expect that there would be other ways of hitting these same inference bugs.
This is working on 0.12 and master: I'm sure one of PR that got merged in the last two months fixed inference from partial hints. Not sure which one though. I think this should be closed. (Unless someone got another test case that fails to infer from partial hints)
:dancer: I've been meaning to look into why this doesn't work. Happy to not have to.
Change:
.emit(); } <ins> fn err_larrow_operator(&self, span: Span) { self.struct_span_err( span, "unexpected token: `<-`" ).span_suggestion( span, "if you meant to write a comparison against a negative value, add a  space in between `<` and `-`", "< -".to_string(), Applicability::MaybeIncorrect ).emit(); } </ins> fn mk_assign_op(&self, binop: BinOp, lhs: P<Expr>, rhs: P<Expr>) -> ExprKind { ExprKind::AssignOp(binop, lhs, rhs) }

Discussion:
produces: It would be nice if it produced a suggestion to split it up: (This , but was broken in a previous change.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi I'd like to try this one. Just found the removed suggestion.
claim
assign Hmm, triagebot is not well...
It doesn't look like you're still working on this. Is it ok if I take over?
Sure. Thanks for your help.
Change:
} let v = clean_maybe_renamed_item(cx, item, *renamed); for item in &v { <del> if let Some(name) = item.name { </del> <ins> if let Some(name) = item.name && !item.attrs.lists(sym::doc).has_word(sym::hidden) { </ins> inserted.insert((item.type_(), name)); } }

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 glob reexport reexports module and there is already module , the documentation duplicates. Current behaviour: ! ( module is duplicated, though both module links point to as expected) The expected behaviour: module is only shown once. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
Fn, Loop(hir::LoopSource), Closure(Span), <del> AsyncClosure(Span), </del> <ins> Coroutine { coroutine_span: Span, kind: hir::CoroutineDesugaring, source: hir::CoroutineSource }, </ins> UnlabeledBlock(Span), LabeledBlock, Constant,

Discussion:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
} } scope 4 { <del> debug z => _5;                   // in scope 4 at $DIR/enum_cast.rs:+7:9: +7:10 </del> <ins> debug z => _6;                   // in scope 4 at $DIR/enum_cast.rs:+7:9: +7:10 </ins> } bb0: {

Discussion:
noticed this 1.63→1.64 change in I tried this code: I expected to see this happen: because is non-, an error about moving out from behind a reference, like happened in 1.63 , this happened: it compiles fine in 1.64 in nightly is probably cased by Change enum-int casts to not go through MIR casts which is mentioned in It's unclear to me whether this is intentional under the banner of " behaviour", since there's no trait involved.
Prioritized as P-critical in meeting just now. This needs to be fixed by 1.65 at a minimum.
labels +T-compiler This needs work from T-compiler! :)
labels -I-lang-nominated Meeting consensus is that the current behavior is wrong and needs to be fixed.
Change:
) } <ins> /// Decodes all inherent impls in the crate (for rustdoc). fn get_inherent_impls(self) -> impl Iterator<Item = (DefId, DefId)> + 'a { (0..self.root.tables.inherent_impls.size()).flat_map(move |i| { let ty_index = DefIndex::from_usize(i); let ty_def_id = self.local_def_id(ty_index); self.root .tables .inherent_impls .get(self, ty_index) .unwrap_or_else(Lazy::empty) .decode(self) .map(move |impl_index| (ty_def_id, self.local_def_id(impl_index))) }) } /// Decodes all traits in the crate (for rustdoc and rustc diagnostics). </ins> fn get_traits(self) -> impl Iterator<Item = DefId> + 'a { self.root.traits.decode(self).map(move |index| self.local_def_id(index)) } <ins> /// Decodes all trait impls in the crate (for rustdoc). </ins> fn get_trait_impls(self) -> impl Iterator<Item = (DefId, DefId, Option<SimplifiedType>)> + 'a { self.cdata.trait_impls.iter().flat_map(move |((trait_cnum_raw, trait_index), impls)| { let trait_def_id = DefId {

Discussion:
Running on nightly causes an ICE. Judging by my for PRs this broken between 2 and 4 days ago (26th-28th Jan). See attached minified project: . Essentially, this is: <details<summary<strongBacktrace</strong</summary<p</p</details
I see the same on Docs build fine with latest stable (1.58.1), but I get the same error with
This is probably a duplicate of , right? The fix for that () isn't in yesterday's (2022-01-29) nightly yet, but should be in today's.
I get the same error with , which does include .
works for me on aarch64-apple-darwin, but not on
There are definitely three crates still hitting this ICE on (at least based on message, and backtrace in 2 cases, but I couldn't reproduce on when testing locally) in
You can use () in your code to figure out what change caused this regression.
Not so surprisingly bisection reveals as the cause.
I'm not sure if this is helpful, but this is the stack I get when attempting to run rustdoc with nightly (which is the most recent nightly available on macOS). I also get the same build failure in CI with . This error comes from building the docs on
Fixed in
Assigning same priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
It seems this issue has regressed recently? Hitting the same ICE on . <details<summary<strongBacktrace</strong</summary<p</p</details
The recent regression should be fixed by , most likely.