jiebi/CodeConvo huggingface dataset:
Change:
LL | type A = [u8; 4]::AssocTy; |          ^^^^^^^^^^^^^^^^ ambiguous associated type | <del> = note: specify the type using the syntax `<[u8; <unevaluated[]>] as Trait>::AssocTy` </del> <ins> = note: specify the type using the syntax `<[u8; _] as Trait>::AssocTy` </ins> error[E0223]: ambiguous associated type --> $DIR/bad-assoc-ty.rs:15:10

Discussion:
After , when a trait bound fails and the trait was implemented by fixed-size arrays, the compiler will display an error like: Which is pretty unhelpful. A solution would be to evaluate these and/or to show evaluated bounds preferably.
I can't reproduce triggering an error with these messages, do you have an example? I need it for a regression test, the fix was indeed as simple
It only appears if you explicitly disambiguate the trait, like . .
are you displaying these as ? I feel that'd be a reasonable output for this.
that would be a better fallback than , but I'm currently trying to get at the actual value (though that triggers cycle errors atm when building libcore's array impls ^^)
That's better in some ways, but kinda implies that
Change:
// lifetime parameters. let outlives_env = OutlivesEnvironment::with_bounds( param_env, <del> infcx.implied_bounds_tys(param_env, impl_m_def_id, wf_tys.clone()), </del> <ins> infcx.implied_bounds_tys(param_env, impl_m_def_id, wf_tys), </ins> ); let errors = infcx.resolve_regions(&outlives_env); if !errors.is_empty() {

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. --This code compiles on the and channels, but crashes with an ICE on the channel. : (Backtrace omitted) .. And so on for , , etc. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized (from the chumsky crate) to: or (from the above) to: Bisected with v0.6.6 to , which is and that PR does look like it's in the right area to have caused this.
Change:
// They can denote both statically and dynamically-sized byte arrays. let mut pat_ty = ty; if let hir::ExprKind::Lit(Spanned { node: ast::LitKind::ByteStr(..), .. }) = lt.kind { <del> if let ty::Ref(_, inner_ty, _) = *self.structurally_resolved_type(span, expected).kind() && self.structurally_resolved_type(span, inner_ty).is_slice() </del> <ins> let expected = self.structurally_resolved_type(span, expected); if let ty::Ref(_, inner_ty, _) = expected.kind() && matches!(inner_ty.kind(), ty::Slice(_)) </ins> { let tcx = self.tcx; trace!(?lt.hir_id.local_id, "polymorphic byte string lit");

Discussion:
This code previously compiled fine, but as of ~2 weeks ago it began to fail on nightly and has continued to do so since. p.s. Is the output of suppose to be one day behind compared to the toolchain name? In any case, was the last working version, and onward trigger the error. modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc
I can put up a fix for this. I suspected this might cause an issue but couldn't think how.
Change:
<ins> #![feature(negative_impls)] //@ edition: 2021 // Test to ensure we are printing the polarity of the impl trait ref // when printing out conflicting trait impls struct MyType; impl !Clone for &mut MyType {} //~^ ERROR conflicting implementations of trait `Clone` for type `&mut MyType` fn main() {} </ins>

Discussion:
The following code: produces: which reads as: any , which isn't realy true. It realy implements . Perhaps the error message should add a in front of the impl to make it more obvious, like this:
Hi , I'd like to take up this issue if it has not been assigned yet. However this would be my first contribution so I just want to confirm it's a good first task. Thanks!
Yeah, for sure! It should be as simple as updating () to account for the polarity. You can query/obtain the impl polarity with . Feel free to reach out here or on Zulip if you have any questions.
Change:
visit::walk_trait_item(self, item); } <ins> fn visit_impl_item(&mut self, item: &'b ast::ImplItem) { if let ast::ImplItemKind::Macro(..) = item.kind { self.visit_invoc(item.id); } else { self.resolve_visibility(&item.vis); visit::walk_impl_item(self, item); } } </ins> fn visit_token(&mut self, t: Token) { if let token::Interpolated(nt) = t.kind { if let token::NtExpr(ref expr) = *nt {

Discussion:
<short summary of the bugI tried this code: Running on a project that has as its direct or indirect dependency. I expected to see this happen: All packages documented. Instead, this happened: — also fails on . : Does also happen for older nightlies, though I forgot to capture the versions before updating in hope it'd fix the issue. There are more ICE issues pointing at , but none on this line here. Backtrace:
I can confirm that this ICE does not occur on Rust 1.37.0 stable, as shown in This might be a regression that slipped through the stable release somehow.
This still happens on 1.39 stable.
cc
It also does it when documenting a project with on nightly. I had no trouble documenting all deps more than 2 weeks ago though.
This happened on our recent build rust 1.39.0 as well.
cc please triage regressions! If anyone would like to help out here: This is in need of a minimal example that reproduces the issue, as well as a bisection to pinpoint the PR that introduced this regression.
Sorry for not getting to this earlier. I've reduced down to: The is coming from the path inside which is messed up somehow by the macro. Bisecting this pointed to which almost certainly means it was caused by (cc. This is an issue in rustc as well because if you try to use the method from another crate like this for example: rather than the expected new` error since it now produces an ICE: <details<summarybacktrace</summary</detailsAnother interesting case comes from removing the inner module: This compile before but now somehow. Also the regressions in and are a similar but newer regression which I've made a new issue for: .
I guess I'll take a look since it's been a week. Thanks for the minimal code case!
Was this not fixed by ?
I don't know. If so then we're all good?
No, I can confirm there's still an ICE.
Is the nonrustdoc example from still ICEing or is it just the rustdoc issue left?
I'll see what happens.
Similarly to the case in this ICE in rustdoc may mean that a bug or error is silently ignored in rustc. So hiding it like does is not a good idea.
Fixed in
Change:
/// RawVec with capacity 0. If T has 0 size, then it makes a /// RawVec with capacity `usize::MAX`. Useful for implementing /// delayed allocation. <del> pub fn new() -> Self { </del> <ins> pub const fn new() -> Self { </ins> Self::new_in(Global) }

Discussion:
It should either elaborate on AssertUnwindSafe or else drop the claim that it will elaborate below.
Change:
if !self.has_errors() { let bugs = std::mem::replace(&mut self.delayed_span_bugs, Vec::new()); <del> self.flush_delayed(bugs, "no errors encountered even though `delay_span_bug` issued"); </del> <ins> self.flush_delayed( bugs, "no errors encountered even though `delay_span_bug` issued", ExplicitBug, ); </ins> } // FIXME(eddyb) this explains what `delayed_good_path_bugs` are!

Discussion:
With beta but nightly does not show backtraces: edits this is with prioritize
can you share your example code, as it doesn't seem that all ICEs are missing backtraces: on the same nightly and beta, and which has a backtrace on both. (if you have the time to do so and a master checkout, it'd be interesting to know whether ThinLTO could be involved like in ; bisection would also be worthwhile)
Hmm interesting, maybe its' something that only happens with :thinking: does not show a backtrace for me ! I also can't force it with or anything :(
This backtrace was removed on purpose in because it's useless. It just points at the place in the error machinery where delayed bugs get flushed, which is either just noise or misleading at worse.
This also affects explicit calls too -- these should be restored in . Regarding s backtraces being useless, see .
Change:
// (during lowering) and the `librustc_middle` arena (for decoding MIR) [decode] asm_template: rustc_ast::InlineAsmTemplatePiece, [decode] used_trait_imports: rustc_data_structures::fx::FxHashSet<rustc_hir::def_id::LocalDefId>, <ins> [decode] is_late_bound_map: rustc_data_structures::fx::FxIndexSet<rustc_hir::def_id::LocalDefId>, </ins> [decode] impl_source: rustc_middle::traits::ImplSource<'tcx, ()>, [] dep_kind: rustc_middle::dep_graph::DepKindStruct,

Discussion:
The following diff: if done in between s, makes the second check fail with: Aside: that error is printed twice, which is also curious. To reproduce, the following snippet fails on the Playground: I've reported it over to avoid defining a duplicate issue, but now that I've noticed it's a regression, I prefer to risk it being a dup than it going unnoticed. I've also mentioned this over: https://rust- This is causing major breakage with users of who have switched to Rust or up, as showcased by: modify labels: +regression-from-stable-to-stable -regression-untriaged
The bug also reproduces when the is above the impl, but only when that does not change the spans of the impl. It also reproduces when the is add in a different file, or when a or an is instead. This suggests to me that this is somehow related to the overall set of DefIds changing. It does not reproduce when the function is non-async. any ideas? Where there any big refactorings during that time frame that could be the cause of this?
Maybe something related to generators / async functions generates numeric IDs based raw DefIndex values which are then not hashed in a stable way?
Bisection seems to point to
That does sound related. might have an idea.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Let's keep this open until the backporting situation of the fix is clarified.
was backported to 1.63.0-beta in -- ready to close?
Is this worth a stable backport? The experience of developing async code with this issue isn’t great.
I tried a stable backport locally just to see, but it's non-trivial -- builds on changes from and at least, but that's as far as I investigated before giving up. Maybe a more targeted fix for 1.62.0 could be developed though.
Backported to stable.
Change:
<ins> // run-rustfix #![allow(unused, nonstandard_style)] mod m { mod p { #[macro_export] macro_rules! nu { {} => {}; } pub struct other_item; } pub use self::p::{nu, other_item as _}; //~^ ERROR unresolved import `self::p::nu` [E0432] //~| HELP a macro with this name exists at the root of the crate } 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. --Given the following code: The current output is: <details<summaryIf the starting order is reversed, the suggestion puts the macro first in the tree</summary</detailsThis is suggesting to change the code to itself It needs to move the import into a tree; the easy way is to make a new statement (and let rustfmt clean that up); the medium way is to find an existing context; the hard way is when a tree root doesn't already exist (or isn't immediately a tree at that point) determine what the code is using and match that. Related: label +D-confusing +D-incorrect
In this case, the ideal solution is actually to write just and get the import from legacy-lexical-macro-scope into the namespace. I originally hit this with just multiple macros in the use tree, and removing the was the correct fix. I "simplified" for the error report to use a second non-macro item here (to reduce the number of diagnostics). So bonus challenge: handle this case properly and only emit a single help: <details
label +D-invalid-suggestion It's not producing invalid code, but it's surely suggesting a fix which will cause an error (the identical one).
Change:
source, out_of_scope_traits, &unsatisfied_predicates, <ins> unsatisfied_bounds, </ins> ); }

Discussion:
Given the following code (): The output on is: <details<summaryLong diagnostic</summary</details, , , and are suggested three times each: once for , once for , and once for . I'm not sure if this is a problem, but this seems incredibly verbose to me. Note that the output on stable 1.51 and beta 1.52 is different:
My mistake, each repetition is actually different in that two suggest taking a reference to : This still seems like a fairly massive diagnostic, though. I've updated the original post in light of this. Feel free to close if a diagnostic of this size is fine here.
cc
Might be a duplicate of , or at least fixed by the same PR that fixed it
Even if it was considered reasonable to suggest each and every possible type combination, there is no pressing reason for it to generate the intervening lines as well: rustc is a compiler, not a can of spam. This remains unpatched on nightly, and is thus a stable-to-beta diagnostic regression.
AFAICT, this is not present on beta, and is only present on nightly, so it's a stable-to-nightly regression. Please correct me if I misunderstood!
searched nightlies: from nightly-2021-01-01 to nightly-2021-04-24 regressed nightly: nightly-2021-04-09 searched commits: from to regressed commit: That is: so it’s . I guess has already been mentioned. label D-verbose
Yes, yes, I introduced this regression. Mea culpa, everybody. In my defense I keep flip-flopping between being too restrictive and too permissive for new suggestions and someone always ends up getting the short end of the stick. This week, I'm leaning towards "too permissive" and if the suggestion triggers too often, then detect the cases and make it more constrained, because the alternative is that the suggestion isn't shown when it could, and we'll never find out. This is IMO better, as long as regressions are caught in nightly, like it was in this case.&lt;/rantAnyways, fixes this.
Assigning and removing .
This now affects 1.53.0 beta. Updating the labels accordingly.
Still needs to be backported.
the beta backport for patch was approved, can this now be closed?

I think we should wait until it actually lands onto beta
This was merged in beta already, right?
Ah, so it was.
Change:
use rustc_codegen_ssa::mir::debuginfo::{FunctionDebugContext, VariableKind}; use rustc_codegen_ssa::traits::{DebugInfoBuilderMethods, DebugInfoMethods}; use rustc_middle::mir; <del> use rustc_middle::ty::{Instance, Ty}; </del> <ins> use rustc_middle::ty::{Instance, PolyExistentialTraitRef, Ty}; </ins> use rustc_span::{SourceFile, Span, Symbol}; use rustc_target::abi::Size; use rustc_target::abi::call::FnAbi;

Discussion:
The following code from the manual fails with rustboot .
How embarrassing. Thanks for the report, I'll look into it.
Fix mem op= mem bug in (via not terribly good fix). Closed by .
Change:
<del> Subproject commit b269bb07078446c9c153e0f2acaf83bf8f19b935 </del> <ins> Subproject commit 7ef40979157b4117faa52bbe79ec144ebd45b0e3 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Change:
# Append a version-dependent hash to each library, so we can install different # versions in the same place <del> CFG_FILENAME_EXTRA=$(shell printf '%s' $(CFG_RELEASE) | $(CFG_HASH_COMMAND)) </del> <ins> CFG_FILENAME_EXTRA=$(shell printf '%s' $(CFG_RELEASE)$(CFG_EXTRA_FILENAME) | $(CFG_HASH_COMMAND)) </ins> ifeq ($(CFG_RELEASE_CHANNEL),stable) # This is the normal semver version string, e.g. "0.12.0", "0.12.0-nightly"

Discussion:
Some systems, like Gentoo, want to package multiple versions of the Rust compiler along side each other. There are several obstacles to this, but the obvious one is that the installed Rust crates need to not have conflicting names. While we have a mechanism for this , the extra strings appended by the current makefile are not sufficient to discriminate between arbitrary compiler revisions. Most likely we will add a configure switch that specifies an additional string to hash into the filename extra, in addition to what we're already hashing. re
Change:
mkdir $(SRC)/mydir mkdir $(INCR) cp main.rs $(SRC)/main.rs <del> $(RUSTC) --test -C incremental=$(INCR) $(SRC)/main.rs </del> <ins> $(RUSTC) --test -C incremental=$(INCR) $(SRC)/main.rs --target $(TARGET) </ins> mv $(SRC)/main.rs $(SRC)/mydir/main.rs <del> $(RUSTC) --test -C incremental=$(INCR) $(SRC)/mydir/main.rs </del> <ins> $(RUSTC) --test -C incremental=$(INCR) $(SRC)/mydir/main.rs --target $(TARGET) </ins>

Discussion:
Some run-make tests require an directive as a workaround for link failures that occur during CI. and or modified tests to include this directive in order to avoid at least this error: . I assume that this shouldn't be necessary, and that there is actually some deficiency in our CI build system that we can fix.
Never mind, it may not be related. Sorry for the noise.
Change:
<ins> use rustc_data_structures::fx::FxHashMap; </ins> use syntax_pos::Span; use crate::print::pprust::token_to_string;

Discussion:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.
Change:
assert_eq!(v, ["a", "b", "c", "b", "c", "a", "b"]); } <ins> // Regression test for issue #82533 #[test] fn test_extend_from_within_panicing_clone() { struct Panic<'dc> { drop_count: &'dc AtomicU32, aaaaa: bool, } impl Clone for Panic<'_> { fn clone(&self) -> Self { if self.aaaaa { panic!("panic! at the clone"); } Self { ..*self } } } impl Drop for Panic<'_> { fn drop(&mut self) { self.drop_count.fetch_add(1, Ordering::SeqCst); } } let count = core::sync::atomic::AtomicU32::new(0); let mut vec = vec![ Panic { drop_count: &count, aaaaa: false }, Panic { drop_count: &count, aaaaa: true }, Panic { drop_count: &count, aaaaa: false }, ]; // This should clone&append one Panic{..} at the end, and then panic while // cloning second Panic{..}. This means that `Panic::drop` should be called // 4 times (3 for items already in vector, 1 for just appended). // // Previously just appended item was leaked, making drop_count = 3, instead of 4. std::panic::catch_unwind(move || vec.extend_from_within(..)).unwrap_err(); assert_eq!(count.load(Ordering::SeqCst), 4); } </ins>

Discussion:
Looking here, the internal length of the vector is only adjusted at the end of the loop This has the caveat that if cloning panics, the Vec will start to unwind and only drop the first elements which doesn't include the most recently appended ones. Something more in line with how the stdlib does things might look like this: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is not unsafe, leaking items is safe:
Sure; never said it was unsafe. This is more about making sure programs who gracefully handle panics don't wind up eventually exhausting resources.
Assigning as part of the .
I would like to fix this claim
The fix seems pretty straight-forward. The Clone specialization just needs a RAII type that handles adjusting the Vec's new len in its Drop implementation, as I've linked in my MiniVec. Copy can't fail so there's no need to adjust that specialization. The only thing that could theoretically panic in that case would be reallocating and in that case, there's no need to worry about the len.
Change:
<ins> #[macro_export] macro_rules! foo { () => { unsafe fn __unsf() {} unsafe fn __foo() { __unsf(); } }; } </ins>

Discussion:
In some external crate, say : Main crate: : With , this gives the following ICE: <details<summary<strongBacktrace</strong</summary<p</p</detailsThis is because the lint to insert the name in the diagnostic message (this delays a good path bug), then the lint because it's in an external macro, which means we don't emit any diagnostic which triggers the good path bug. This ICE is currently preventing rustc from building with enabled. I see several ways to fix this: don't print the function name. It arguably carries little value, with the span already pointing to the offending function call, and brings THIR unsafeck in line with MIR unsafeck (cc ). 't trim the path. This might lead to longer messages but other lints already do this so it is probably acceptable? 't create the lint if we're in an external macro and we know the lint will be cancelled anyway. It's a little hacky and breaks down if changes are made to lint emission. the lint emission API to allow lint messages to be lazily evaluated. label +A-diagnostics +requires-nightly claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Error: Label thir-unsafeck can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Would not trimming the path also be acceptable ? (via )
It looks like some lints are already not trimming paths so this is probably acceptable? I can do that if that's the preferred option.
claim