jiebi/CodeConvo huggingface dataset:
Change:
impl_dep_tracking_hash_for_sortable_vec_of!((String, Option<String>, Option<cstore::NativeLibraryKind>)); impl_dep_tracking_hash_for_sortable_vec_of!((String, u64)); <del> impl DepTrackingHash for SearchPaths { fn hash(&self, hasher: &mut DefaultHasher, _: ErrorOutputType) { let mut elems: Vec<_> = self .iter(PathKind::All) .collect(); elems.sort(); Hash::hash(&elems, hasher); } } </del> impl<T1, T2> DepTrackingHash for (T1, T2) where T1: DepTrackingHash,

Discussion:
I was trying to determine if sccache could cache crates built as dependencies of different root crates. When I looked into it I found that the rlibs were not bit-identical despite being built from the same source. Most of the differences were in the debug info because the current directory winds up encoded there. I tried using which removed most of the differences but not all. A small difference in the metadata remains, which from looking at the diff of the serialized metadata said was the . do you know why this would be? I built this twice in different directories using the script. The diff of the rlib from each build (I generated that using .) Presumably this would block and also
Lots of stuff goes into the SVH. It might well be that something directory related accidentally goes into it. The SVH is computed here:
cc This is similar to the GCC build-path issue where other programs (and in the past, GCC's DWATproducer) likes to embed CFLAGS into the output. Suggested options: out -Zremap-path-prefix away from that SVH calculation - but other programs that also embed RUSTFLAGS or similar, would also need similar logic the envvar or something similar cargo support a constant flag (whose value does not depend on build-path) that figures out the right -Zremap-path-prefix for rustc so they don't need to appear in RUSTFLAGS. you'd also need to implement (1) but at least the caveat (about other programs) doesn't apply.
addresses (1), which is kind of orthogonal to (2) and (3) because the SVH will always be part of the output binary and it must change if the result of the mapping changes.
With the latest Rust nightly: which includes the fix from , the outputs from are still not the same:
I think we may still be hashing arguments?
Yes, it seems we do: Good catch! Not sure if we have to hash those at this point. The tracking system should catch resulting changes later on, if we don't have any holes in the tracking. This needs some review.
Edit: never mind - seems fixed now that I've rebased to master. I found that (after implementing it) still affects the SVH, even if the mapping does nothing: will generate different metadata hashes if I change the mapping, even though it doesn't affect anything and nothing else changes.
Change:
<ins> error: unknown start of token: u{a7} --> $DIR/issue-69130.rs:4:4 | LL | M (§& u8)} |    ^ error[E0106]: missing lifetime specifier --> $DIR/issue-69130.rs:4:5 | LL | M (§& u8)} |     ^ expected named lifetime parameter | help: consider introducing a named lifetime parameter | LL | enum F<'a> { LL | M (§&'a  u8)} | error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0106`. </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on and but not on .
Visited from compiler team triage meeting. Categorized as P-medium.
searched nightlies: from nightly-2020-01-01 to nightly-2020-02-10 regressed nightly: nightly-2020-01-22 searched commits: from to regressed commit: source code: <details<summaryICE backtrace</summary<p</p</detailsReproduce bisect report:
Interesting -- the regression report suggests this was caused by , cc
The problem is here: is a character index. It needs to be translated into a byte index before it can be used to slice . I've submitted a
Change:
<del> pub fn test<const N: usize, T>() {} </del>

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. --cc still crashes after <!-- 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 --
Sigh, yeah, this is just the same bug but for lifetime params. I'll fix it, shouldn't be too hard. claim
Hey, , thanks for getting this fixed! Unfortunately, I seem to be running into the same issue (or a very similar one) using the latest nightly, and I've not been able to create a standalone reproducer: <details<summaryBacktrace</summary<p</p</detailsSorry if this is the wrong place to be reporting this ICE, but I wasn't sure whether to file a new issue or maybe get one of the resolved issues re-opened. Thank you!
Change:
class IdentityPrinter: def __init__(self, string): <del> self.string </del> <ins> self.string = string </ins> def to_string(self): return self.string

Discussion:
Debuginfo for (and probably also ) enums is not correct if the pointer that doubles as discriminant is a fat pointer. Steps to reproduce: (1) Compile the following program with (2) Print the value of in LLDB with pretty printers enabled: This should print instead of . Maybe it's just the LLDB pretty printer that needs to be adapted.
Change:
ty_span: Span, ) { if variant.recovered { <ins> self.set_tainted_by_errors(); </ins> return; } let mut err = self.type_error_struct_with_diag(

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on , , and .
I'm looking into this! But mostly as a learning exercise. Spent ~4 hours exploring typeck & error handling today to see why this exact combination of things triggers an error. My friend and I will probably have a solution at some point, but it might be a few weeks from now. If anyone has a good & quick solution, or if it is deemed high-priority, then feel free to ignore me.
~According to , this regressed between 2019-07-30 and 2019-07-31. Unfortunately, seems to be incapable of narrowing it down to a commit because that was more than 167 days ago.~ EDIT: gave me a misleading result. This error is at least as old as .
This error started happening in cc
The ICE goes away if I apply this patch: (Though I'd guess that making this change would cause us to regress on the problems that fixed.)
This change fixes the ICE and avoids regressing on : I'm unsure whether this respects the intended meaning of , though.
on a very cursory look that patch looks reasonable.
has some additional relevant context.
Unfortunately, the patch that I proposed above fails on this modification of :
triage: P-high. Removing nomination. Added regression stable-to-stable tag.
I think I found a way to resolve this without regressing on . The point of this PR is to not emit an error if it might be invalid to the user. But there are errors in context still. The patch I propose is this: This does pass every UI test. I'll open a PR so this can be discussed more easely.
Change:
let instance = monomorphize::resolve(scx, method.def_id, callee_substs); <del> let predicates = tcx.predicates_of(instance.def_id()).predicates .subst(tcx, instance.substs); if !traits::normalize_and_test_predicates(tcx, predicates) { continue; } if should_trans_locally(tcx, &instance) { output.push(create_fn_trans_item(instance)); </del> <ins> let trans_item = create_fn_trans_item(instance); if trans_item.is_instantiable(tcx) && should_trans_locally(tcx, &instance) { output.push(trans_item); </ins> } } }

Discussion:
Compiler panicks instead of showing an appropriate error message in case boundaries are not satisfied. I tried this code: In the result compiler panicked with the following message:
Minimal repr:
Still panics on stable 1.15.1
Change:
kind_name = "structure"; } _ => { <del> let resolved_expected = fcx.infcx().ty_to_str(fcx.infcx().resolve_type_vars_if_possible(expected)); fcx.infcx().type_error_message_str(pat.span, |actual| { </del> <ins> fcx.infcx().type_error_message_str_with_expected(pat.span, |expected, actual| { expected.map_default(~"", |&e| { </ins> fmt!("mismatched types: expected `%s` but found %s", <del> resolved_expected, actual)}, ~"an enum or structure pattern", </del> <ins> e, actual)})}, Some(expected), ~"an enum or structure pattern", </ins> None); fcx.write_error(pat.id); kind_name = "[error]";

Discussion:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in
Change:
_ => " "         // -squigly-line as well (instead of a };                   // space). This way the squigly-line will }                        // usually appear in the correct position. <del> s += "^"; </del> <ins> io::stderr().write_str(s); let mut s = ~"^"; </ins> let hi = cm.lookup_char_pos(sp.hi); if hi.col != lo.col { // the ^ already takes up one space let num_squiglies = hi.col.to_uint()-lo.col.to_uint()-1u; for num_squiglies.times() { s += "~"; } } <del> io::stderr().write_str(s + "n"); </del> <ins> print_maybe_colored(s + "n", term::color_bright_green); </ins> } }

Discussion:
'warning', 'note', and 'error' are colorized; I think it'd be nice to also colorize the underlining of the affected code, as clang does. clang makes it green, I believe.
+1 for doing whatever clang does re error reporting.
Change:
<del> Subproject commit 8888f9428fe9a48f31de6bd2cef9b9bf80791edc </del> <ins> Subproject commit a9fb7d13eadfcc5f457962731f105b97f9a7474a </ins>

Discussion:
Compile the above (faulty) code with gives me this:
Probably related to .
Thanks for the information! Close this one.
Change:
pub fn get_native_libraries(&self, sess: &Session) -> Vec<NativeLibrary> { <del> self.root.native_libraries.decode((self, sess)).collect() </del> <ins> if self.proc_macros.is_some() { // Proc macro crates do not have any *target* native libraries. vec![] } else { self.root.native_libraries.decode((self, sess)).collect() } </ins> } pub fn get_foreign_modules(&self, sess: &Session) -> Vec<ForeignModule> { <del> self.root.foreign_modules.decode((self, sess)).collect() </del> <ins> if self.proc_macros.is_some() { // Proc macro crates do not have any *target* foreign modules. vec![] } else { self.root.foreign_modules.decode((self, sess)).collect() } </ins> } pub fn get_dylib_dependency_formats(&self) -> Vec<(CrateNum, LinkagePreference)> {

Discussion:
: : Steps to reproduce: This is failing when the crate attempts to import the crate (which is a crate). That is, if I modify 's file to only contain: rustc will ICE. <details<summaryBacktrace:</summary</details
I suspect this is a duplicate of , but I only count 2 #[procmacro] and 1 #[procmacro_attribute] in the repository.
The crate only has 1 and 1 . If I comment both of them out, the compiler still ICEs. The crate used to compile a couple weeks ago, so this was a fairly recent change.
To give some bounds on this: the crate compiles with . It fails with . I would bisect this with rustup to determine which nightly the issue started with, but .
Derp, I just remembered I could remove the component. Okay, doing that, I was able to bisect the nightlies: Last working version: First failing version:
I just did a git bisect, and it looks like commit (from PR ) is the source of the breakage. cc
visited for triage. Going to try to followup with . Assigning to self to keep myself honest about that claim.
also, P-high
Am looking at this.
Minified: // #[allow(unused)] // enum ProcMacroHack { // Input = (stringify!(ARGS), 0).1, // } // The problem is caused by containing "host" defids and being used in [trans]. I don't think that this field has any business containing host libraries when compiling a proc macro, but I'll ask for confirmation. [trans]:
visited for triage. Seems like PR handles this. Leaving as P-high
Change:
<del> Subproject commit 593484fc1596707406b0b0b45b97feb08d2a1bfc </del> <ins> Subproject commit 47848665966fc7393cb6f898077994f6dec2b591 </ins>

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: successful compilation Instead, this happened: It most recently worked on (): <!-- Provide the version you are using that has the regression. --: We've determined that is the culprit; either removing that line or replacing with both fix the compiler crashing (although this does not produce the code we want). This looks like it's possibly related to the LLVM version. modify labels: +regression-from-stable-to-stable -regression-untriaged
A bit of reducing could help here. ideally we want to be able to reproduce. label +O-wasm tagging also ping icebreakers-cleanup-crew
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
: (must be compiled with , which can be done on playground by setting to "release" and clicking "WASM" instead of "Run")
searched nightlies: from nightly-2022-01-13 to nightly-2022-05-03 regressed nightly: nightly-2022-03-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThis did indeed regress in the LLVM bump (). label I-crash A-llvm
Assigning priority as discussed in the of the Prioritization Working Group. Great work thanks! label -I-prioritize +P-high -ICEBreaker-Cleanup-Crew
Looks like is the change where it starts failing. Adding does seem to work around the crash. cc
IR: Running this through crashes with LLVM 14 but works fine on main, so this was apparently already fixed in the meantime.
Bisect points to , which probably just hides the problem.
Ah no, I misread.

That does look like the actual fix for the issue.
Filed backport issue:
Apologies for the noise, but did this fix make its way into 1.61? I'm still getting similar issues there.
Change:
.find_map(|(p, s)| get_future_output(p.as_predicate(), s))?, ty::Error(_) => return None, _ => span_bug!( <del> self.tcx.def_span(expr_def_id), </del> <ins> span, </ins> "async fn generator return type not an inference variable: {ret_ty}" ), }; <ins> let output_ty = self.normalize(span, output_ty); </ins> // async fn that have opaque types in their return type need to redo the conversion to inference variables // as they fetch the still opaque version from the signature. let InferOk { value: output_ty, obligations } = self <del> .replace_opaque_types_with_inference_vars( output_ty, body_def_id, self.tcx.def_span(expr_def_id), self.param_env, ); </del> <ins> .replace_opaque_types_with_inference_vars(output_ty, body_def_id, span, self.param_env); </ins> self.register_predicates(obligations); Some(output_ty)

Discussion:
I tried this code: It failed with a confusing error message. (error: concrete type differs from previous defining opaque type use, at the same location) I'm trying to minimize , and found the problem. compiles, but fails. Although not 100% sure, I think it's caused by the same problem as (regression caused by )
cc
I can work on this, and then I can test if it fixes the other issue too.
Change:
<del> // compile-pass </del> <ins> #![deny(unused)] </ins> <del> #[derive()] //~ WARNING empty trait list in `derive` struct Bar; </del> <ins> #[derive()] //~ ERROR unused attribute struct _Bar; </ins> pub fn main() {}

Discussion:
The following code emits an unsquelchable warning. This warning should be a part of .
empty trait list in should have a lint name ... and that name is .
Does not appear to squelch the warning for me...
It seems eminently reasonable to me to include in since it is an attribute applied with no effect; so let's kick off fcp for that. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Implementing this as part of the existing would be complicated by , but it might also be possible to implement where the existing "empty trait list" warning is issued (possibly as a ).
I need to make a buffered early lint for the same thing with .
Seems reasonable. And a macro that might end up with an empty derive list should have no problem turning off locally.
reviewed I certainly agree with moving warnings to lints.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
Change:
Ok(written) } <ins> impl IncompleteUtf8 { pub const fn new() -> IncompleteUtf8 { IncompleteUtf8 { bytes: [0; 4], len: 0 } } } </ins> impl Stdout { pub const fn new() -> Stdout { <del> Stdout </del> <ins> Stdout { incomplete_utf8: IncompleteUtf8::new() } </ins> } } impl io::Write for Stdout { fn write(&mut self, buf: &[u8]) -> io::Result<usize> { <del> write(c::STD_OUTPUT_HANDLE, buf) </del> <ins> write(c::STD_OUTPUT_HANDLE, buf, &mut self.incomplete_utf8) </ins> } fn flush(&mut self) -> io::Result<()> {

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: Program does not panic. Instead, this happened: Program panics with the error . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</detailsTo clarify: This problem occurs with all trait implementations that don't override the default implementation, e.g. with this simple DelegatingWrite:
I see two distinct possibilites to resolve this: 1) Treat incomplete s not ending on a codepoint boundary as a bug and fix that in the stdlib. Also clarify in the docs that indivual calls must be passed complete UTF-8 sequences if a Windows terminal is attached. 2) In the vain of "Be liberal in what you accept" handle incomplete UTF-8 passed in via calls appropriately, as long as the sequence is completed properly in the next call(s).
Hm, so this is ultimately a bug in the buffer uses? It attempts to write 1024 bytes but only 1023 bytes can written in the first OS call. It then has a leftover byte, which I guess it tries to write by itself thus causing this error?
The logic which errors if incomplete UTF-8 is passed in at index 0 is in the std lib at . That is where the error message comes from. As far as I can see the stdio buffer implementation (in stable, it is in , apparently currently being revamped) can not know of the requirement that only complete UTF-8 may be written to the underlying Windows terminal so I think that it should be encapsulated in by just accepting and buffering incomplete UTF-8 when necessary.
I mean, a generic buffer can attempt to avoid small writes (say, less than 16 bytes) by copying those left over bytes to the front of the buffer and waiting for either another to refill the buffer or a to empty it. But I see what you mean. Introducing a small buffer to windows/stdio would fix the problem.
Change:
{ tcx.fold_regions(&ty, &mut false, |region, _| match *region { ty::ReVar(vid) => { <del> let upper_bound = self.universal_upper_bound(vid); </del> <ins> // Find something that we can name let upper_bound = self.approx_universal_upper_bound(vid); </ins> self.definitions[upper_bound].external_name.unwrap_or(region) } _ => region,

Discussion:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.
Change:
let gcc_lld_src_dir = src_dir.join("gcc-ld"); let gcc_lld_dst_dir = dst_dir.join("gcc-ld"); t!(fs::create_dir(&gcc_lld_dst_dir)); <del> let exe_name = exe("ld", compiler.host); builder.copy(&gcc_lld_src_dir.join(&exe_name), &gcc_lld_dst_dir.join(&exe_name)); </del> <ins> for name in crate::LLD_FILE_NAMES { let exe_name = exe(name, compiler.host); builder .copy(&gcc_lld_src_dir.join(&exe_name), &gcc_lld_dst_dir.join(&exe_name)); } </ins> } // Man pages

Discussion:
lld-wrapper is unhappy. I tried this code: Instead, this happened: <!-- 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<summaryBacktrace</summary<p</p</detailsNote that this worked for months. This is a regression for me.
Is this issue related to ?
I found no traces of the last working nightly.
Is this issue related to It's certainly somehow related because didn't exist before that, but I don't know how it can happen, is in fact passed as snipped posted in the original message shows.
Do you need more information?
Do you need more information? Yes, output of lld-wrapper with inserted here (You don't need whole compiler build to rebuild lld-wrapper, it's a single-file standalone program, it can be built with directly or with , and then temporarily put into the directory.)
Note that main:rs73 is the failure case.
I see. The command line is to long so it's moved to a temporary file and passed with . Neither lld-wrapper nor original (flavorless) lld support specifying the flavor inside the file. Due to the way in which and work for naked LLD never gets into the file, we should do something similar with too.
I don't know whether rustc has utilities for handling response files
Ok, it's actually clang that packs the command line into a , not rustc, so we cannot control or predict when it happens. That's pretty bad. I guess we'll have to partially revert and use something based on file names, like
Fixed in Sorry for the delay, I should have fixed this two months ago. could you test the fix on Darwin?