jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> // Adjust any other errors that come from other cause codes, when these // errors are of the same predicate as one we successfully adjusted, and // when their spans overlap (suggesting they're due to the same root cause). // // This is because due to normalization, we often register duplicate // obligations with misc obligations that are basically impossible to // line back up with a useful ExprBindingObligation. </ins> for error in not_adjusted { for (span, predicate, cause) in &remap_cause { if *predicate == error.obligation.predicate

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: Diesel has a larger amount of compile test to check whether some constructs are rejected at compile time and to check for specific error messages. These tests are implemented using trybuild. We pin specific compiler versions as the output obviously might change with newer compiler versions. From time to time an update of the pinned version is required. While doing such an update we noticed that newer versions of rustc do emit non-deterministic error messages. These sometimes include more or less information. To reproduce this behaviour perform the following steps: We do not observe this behaviour with . I've observed this behaviour at least since (that's the earliest nightly I've checked, so there might be earlier versions as well) Exemplary changes between two runs (obviously that changes as well): <!-- 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 --
If you have time, it would be helpful to find exactly which commit regressed this (using ).
searched nightlies: from nightly-2022-08-12 to nightly-2022-09-15 regressed nightly: nightly-2022-08-23 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: : </detailscc as author of the relevant PR
I'll take a look. claim
Change:
} let ptr = to_arg_ty_ptr(cx, ptr, t); <ins> let align = type_of::align_of(cx.ccx(), t); </ins> if type_is_immediate(cx.ccx(), t) && type_of::type_of(cx.ccx(), t).is_aggregate() { <del> return Load(cx, ptr); </del> <ins> let load = Load(cx, ptr); unsafe { llvm::LLVMSetAlignment(load, align); } return load; </ins> } unsafe {

Discussion:
The attached source produces code that misbehaves on some platforms that are picky about memory access alignment. The code should exit with code 2, but on both Emscripten-generated JavaScript and ARMv5, it finishes with exit code 1 to indicate that the field is incorrectly tested as equal to . Changing the field to a type results in proper execution on these platforms. All optimization levels seem to cause it. Libraries that make use of structs with fields followed by enums seem particularly prone to this problem. It all works fine on platforms that allow unaligned memory access like x86, ARMv6, etc. Expected output: (x86, ARMv6) Actual output: (ARMv5, Emscripten) Note that the same ARM binary runs on both ARMv5 and ARMv6 platforms, producing the different results. See also: ( and removed)
To quote myself:
Change:
} pub fn file_attr(&self) -> io::Result<FileAttr> { <ins> let fd = self.0.raw(); cfg_has_statx! { if let Some(ret) = unsafe { try_statx( fd, b"0" as *const _ as *const libc::c_char, libc::AT_EMPTY_PATH | libc::AT_STATX_SYNC_AS_STAT, libc::STATX_ALL, ) } { return ret; } } </ins> let mut stat: stat64 = unsafe { mem::zeroed() }; cvt(unsafe { <del> fstat64(self.0.raw(), &mut stat) </del> <ins> fstat64(fd, &mut stat) </ins> })?; <del> Ok(FileAttr { stat }) </del> <ins> Ok(FileAttr::from_stat64(stat)) </ins> } pub fn fsync(&self) -> io::Result<()> {

Discussion:
First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?
Change:
}; if !is_simple_error { <del> diag.note_expected_found(&"type", &expected, &found); </del> <ins> if expected == found { if let &TypeError::Sorts(ref values) = terr { diag.note_expected_found_extra( &"type", &expected, &found, &format!(" ({})", values.expected.sort_string(self.tcx)), &format!(" ({})", values.found.sort_string(self.tcx))); } else { diag.note_expected_found(&"type", &expected, &found); } } else { diag.note_expected_found(&"type", &expected, &found); } </ins> } }

Discussion:
This code is wrong, but the error message is confusing: Because I used accidentally as a type name when not using the right syntax ... this is pretty confusing:
One solution would be to add detail after the expected/found lines if primitive shadowing has come into play. This would not change the language, but make the error look like:
Change:
UV_FS, UV_WORK, UV_GETADDRINFO, <ins> UV_GETNAMEINFO, </ins> UV_REQ_TYPE_MAX }

Discussion:
For example, this program prints on unix, and on windows:
The appears to be different on windows for both libgreen and libnative.
I believe this happens because the arguments end up being quoted for Windows. Simplest fix would be to drop empty arguments. Thoughts?
(Alternatively, we could quote empty arguments on Unix.)
I would expect the empty arguments to be passed through as significant argument position. I ran into this in cargo because passed on unix but on windows it would try to consume the next argument for the test args. It looks like to fix this we just need to alter to see if the argument is 0-length, and if so we quote it. Libuv already does . I'm investigating a fix for libgreen, it looks like it should be working...
Change:
} // FIXME #2887: think about span stuff here TokenTree::Token(sp, SubstNt(ident)) => { <del> r.stack.last_mut().unwrap().idx += 1; </del> match lookup_cur_matched(r, ident) { None => { <ins> r.stack.last_mut().unwrap().idx += 1; </ins> r.cur_span = sp; r.cur_tok = SubstNt(ident); return ret_val;

Discussion:
See discussion on .
The ability to convert token-trees AST is also needed to
Do we need that ability here? It's only about interpolated matches.
Fixed in .
Change:
} // FIXME #2887: think about span stuff here TokenTree::Token(sp, SubstNt(ident)) => { <del> r.stack.last_mut().unwrap().idx += 1; </del> match lookup_cur_matched(r, ident) { None => { <ins> r.stack.last_mut().unwrap().idx += 1; </ins> r.cur_span = sp; r.cur_tok = SubstNt(ident); return ret_val;

Discussion:
I haven't finished investigating this, so I'm making an issue just so I don't forget it:
Actually, I'm really not sure this should work. I'm nominating this for well-defined.
Actually... this definitely shouldn't work in our current system. The basic issue is that a lonely sigil is not a complete "thing". The "tt" macro option is only intended for macros that expand into macro invocations. There are a number of ways around this; at the most basic level, you can insist that the user provide the sigil and the thing it's attached to. This works, but it may be unsatisfying if you want the sigil to be attached to names that are introduced by the macro. In this case, you have a couple of choices. use an unhygienic macro (and tell everyone what name you want to attach to the sigil, ugh) explicitly have three different versions of the macro, one for each sigil (bleah) clean up the second option by nesting one macro definition inside another one make sigils expand into macro invocations. Anyhow, I would say that as of right now, at least, this is not a bug. I'm going to leave this as nominated mostly because this came up in Vancouver as something that Graydon and I both expected to work.
Visiting for triage: still doesn't work, nothing more to add.
accepted for well-defined milestone
You can work around this by using a dummy macro so that you can pass the directly to it, e.g. for the example in the issue:
reading this workaround makes me feel like our macro system is really broken :(.
/cc
The modernized example gives me which looks like .
notes that another hacky work-around is a nested macro invocation, which avoids needing to define/export dummy macros (although one will want to be careful about giving that internal macro a fairly unique name to avoid trampling on any other macros in scope, unfortunately :disappointed: ).
Updated example: error:
Triage: This is an ancient P-low bug but per it actually comes up in the wild a lot - macro writers have to know how to do this workaround. Can this be escalated? Is there a solution somebody could mentor?
Discussed at lang meeting, we believe this should remain p-low since we don't know a very easy fix.

It should be fixed by converting macro_rules to expand to pure tokens then parsing, rather than mixing the two steps (which we hop would be back-compat). cc
Fixed in .
Change:
let Foo::D(_y, _z) = x; //~^ ERROR refutable pattern in local binding //~| `Foo::A(_)` not covered <ins> //~| NOTE `let` bindings require an "irrefutable pattern" //~| NOTE for more information //~| NOTE pattern `Foo::A(_)` is currently uninhabited //~| NOTE the matched value is of type `Foo` //~| HELP you might want to use `let else` </ins> }

Discussion:
The following code compiles on nightly (): But if the wrapper type is moved into a module to make the field private, then it does not: (): Making the field makes it compile again. Is this expected? I suppose I could understand if it is; the private fields could change to make actually be constructable and therefore make the pattern refutable. But if that's the case, then I think the compiler should point this out, like . If indeed this is expected, is there any way for me as a library author to somehow convince the compiler that I will never change the fields to make the type constructable? I want users of my library to be able to elide match arms when I give them an . label +T-compiler +F-never_type +D-confusing +requires-nightly +S-bug-has-mcve
label +F-exhaustive_patterns
are we sure this is actually a bug? As I said, I could understand how it's not:
I'm not sure either way - however at the very least, as you point out, it makes sense to have some better diagnostics
This is definitely intentional. But yeah, it should have a better error message. Not currently I don't think. It would probably require us to add an trait, eg. something like: This trait would then need to be a lang item so that the exhaustiveness check could make use of it. Adding this trait would require an RFC but I doubt there'll be much enthusiasm for adding another special trait for such a niche use-case. Alternatively, you could give an or method to expose the uninhabitedness of the inner value. It's not quite what you're asking for but it's still concise-ish:
Is supposed to be “injected” where an otherwise required match arm was omitted? Wouldn't that run into the same discussions project-deref-patterns had about impure code (code with side effects) inside patterns? Their existence would heavily hinder optimizations of match expressions (like translation to jump tables or reordering).
If the type implementing really is uninhabited then there won't actually be any impure code in the match. The call to would only need to be injected for types that fake uninhabitedness with an impl that panics/aborts. We could also rule that out be instead making -only like .

Making a trait isn't straightforward exactly because inhabitedness depends on visibility questions. It would probably have to mean "Uninhabited as far as the outside world is concerned", or it could use a trick like the in to make it depend on the module.
Change:
if len > self.len { return; } <del> let s = self.get_unchecked_mut(len..) as *mut _; </del> <ins> let remaining_len = self.len - len; let s = slice::from_raw_parts_mut(self.as_mut_ptr().add(len), remaining_len); </ins> self.len = len; ptr::drop_in_place(s); }

Discussion:
To my knowledge, the following code is intended to be legal: However, Miri currently flags this as UB. I believe this is , but for . Discovered while writing . cc
Yeah this looks pretty similar. uses under the hood though, so I wonder why the issue still exists here. Looks like is implemented via -- and indeed, this errors, too:
The problem is in this line: The here is a slice method, so this creates a slice covering the entire , which overlaps with the mutable reference created before and thus invalidates it.
It shouldn't be too hard to locally fix this, but that duplicates some code and there are some other uses of in . Ideally, this would all use raw slices to avoid making any uniqueness promises. But without , raw slices are not very useful.
Here's a possible fix:
Fix PR is up:
Change:
self.resolve_error(trait_reference.path.span, msg.as_slice()); } Some(def) => { <del> debug!("(resolving trait) found trait def: {:?}", def); self.record_def(trait_reference.ref_id, def); </del> <ins> match def { (DefTrait(_), _) => { debug!("(resolving trait) found trait def: {:?}", def); self.record_def(trait_reference.ref_id, def); } (def, _) => { self.resolve_error(trait_reference.path.span, format!("`{}` is not a trait", self.path_idents_to_str( &trait_reference.path))); // If it's a typedef, give a note match def { DefTy(_) => { self.session.span_note( trait_reference.path.span, format!("`type` aliases cannot  be used for traits") .as_slice()); } _ => {} } } } </ins> } } }

Discussion:
This code is wrong because ToStr does not define . But what's odd is that the compiler error does not happen in the block but in the : Error message: The expected error message would point to the block that needs to be split into two (one with ToStr and one without a trait).
Reproduced as of
Repro'd with -- but not critical for 0.6, de-milestoning
Appears to be fixed, as per this updated test case: fails with . Closing.
We've regressed: there's a test case (), but it's been xfailed since it was . With I see:
Aaaand, we've un-regressed! Removing all tags except for neesdtest.
Whoops, had the wrong code example, regression still here.
Change:
<ins> // Regression test for #82126. Checks that mismatched lifetimes and types are // properly handled. // edition:2018 use std::sync::Mutex; struct MarketMultiplier {} impl MarketMultiplier { fn buy(&mut self) -> &mut usize { todo!() } } async fn buy_lock(generator: &Mutex<MarketMultiplier>) -> LockedMarket<'_> { //~^ ERROR this struct takes 0 lifetime arguments but 1 lifetime argument was supplied //~^^ ERROR this struct takes 1 type argument but 0 type arguments were supplied LockedMarket(generator.lock().unwrap().buy()) //~^ ERROR cannot return value referencing temporary value } struct LockedMarket<T>(T); fn main() {} </ins>

Discussion:
The following is an attempted minimum reproducible sample that causes ICE. From a few minutes of experimentation, I wasn't able to further minimize the example, but I feel as if it should be possible (perhaps an example can be formed with just an async boundary and a mutex?). <!-- 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. --: Also saw the ICE on nightly, but I can't seem to get my instance of cargo to recognize the 1.52 toolchain. Testing on shows this still is present: The following outputs are the result of building on nightly playgound: <details<summary<strongBacktrace</strong</summary<p</p</details
Smaller:
Relevant code: So I think that just needs to be a .
I've actually been looking to contribute to Rust—would this be a good first issue to tackle?
This would definitely be a good first issue!
Change:
<ins> //@ edition: 2021 //@ check-pass #![feature(async_closure)] pub struct Struct { pub path: String, } // In `upvar.rs`, `truncate_capture_for_optimization` means that we don't actually // capture `&(*s.path)` here, but instead just `&(*s)`, but ONLY when the upvar is // immutable. This means that the assumption we have in `ByMoveBody` pass is wrong. pub fn test(s: &Struct) { let c = async move || { let path = &s.path; }; } fn main() {} </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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Sorry you hit this ICE. This should be fixed by , which landed 15 minutes ago, though will probably not make it into nightly until two days from now (10 April 2024).
Actually, it's not yet fixed. I have a follow-up PR that will fix this :facepalm:
Change:
<del> Subproject commit 3bc0272cab9fdcfc2ef4df9625ec3c9d5909db79 </del> <ins> Subproject commit a8fc4c169fac43a5dc204d4fd56ddb1739f8c178 </ins>

Discussion:
The cross-compiled MIPS host compilers are fine, but stage1 immediately segfaults when asked to do just about anything: Notice the recursion, which is obviously wrong, and non-existent on stage0: This is . Maybe we should incorporate the workaround there as well.
This seems more complete than the one found in the LLVM bug thread.
It looks like the binaries we're distributing don't have this recursion, so I guess this is only happening when you're bootstrapping locally? If so, what compiler are you using? It'd be useful to drill into the command that actually compiled so we can figure out what's going on here.
I'm indeed bootstrapping natively on MIPS64el. output: Rust revision used is with applied. I'll try to look into the actual compiler invocation, as even though I applied the workaround the resulting still is broken.
The compiler invocation is like this (newlines by me): Ignore my previous comment that the workaround was ignored, I forgot to commit the submodule update and rustbuild reverted it to a previously broken one. The generated code now looks like this: But the function called is now (not in the output; MIPS objdump seems feature-lacking). I kicked off compilation now, hopefully stage1 would be done several hours later (the hardware is slow). I'll run some tests to see if the workaround really worked.
Hm ok, so is the same bug still happening? Or we're waiting to see if it's a new bug? Also, what was the workaround you applied? (e.g. the patch)
The commit is xen0n/compiler-rt I just saw a different crash but it's probably unrelated and spurious, I'm restarting the build to see if that's the case.
As for the bug: it is presumably fixed by the workaround. But we can never be sure until we've run the tests.
Quick update: the double free was indeed spurious, the build is happily running now. Unfortunately I can't test the stage1 immediately, it's 3 am here. I'll see if the build can progress to anything more than stage1 later in the day.
If you want to send that patch to our compiler-rt fork, I'd be happy to merge!
Problem solved, finished this morning and test failures are few, currently there are which are all expected to fail on MIPS but not ignored.

I'll prepare a PR to shortly.
I've opened rust-lang/compiler-rt. I'll open another PR to update the submodule after that PR is merged.
Change:
<ins> error[E0107]: this struct takes 0 lifetime arguments but 1 lifetime argument was supplied --> $DIR/issue-82126-mismatched-subst-and-hir.rs:16:59 | LL | async fn buy_lock(generator: &Mutex<MarketMultiplier>) -> LockedMarket<'_> { |                                                           ^^^^^^^^^^^^---- help: remove these generics |                                                           | |                                                           expected 0 lifetime arguments | note: struct defined here, with 0 lifetime parameters --> $DIR/issue-82126-mismatched-subst-and-hir.rs:23:8 | LL | struct LockedMarket<T>(T); |        ^^^^^^^^^^^^ error[E0107]: this struct takes 1 type argument but 0 type arguments were supplied --> $DIR/issue-82126-mismatched-subst-and-hir.rs:16:59 | LL | async fn buy_lock(generator: &Mutex<MarketMultiplier>) -> LockedMarket<'_> { |                                                           ^^^^^^^^^^^^ expected 1 type argument | note: struct defined here, with 1 type parameter: `T` --> $DIR/issue-82126-mismatched-subst-and-hir.rs:23:8 | LL | struct LockedMarket<T>(T); |        ^^^^^^^^^^^^ - help: add missing type argument | LL | async fn buy_lock(generator: &Mutex<MarketMultiplier>) -> LockedMarket<'_, T> { |                                                                          ^^^ error[E0515]: cannot return value referencing temporary value --> $DIR/issue-82126-mismatched-subst-and-hir.rs:19:5 | LL |     LockedMarket(generator.lock().unwrap().buy()) |     ^^^^^^^^^^^^^-------------------------^^^^^^^ |     |            | |     |            temporary value created here |     returns a value referencing data owned by the current function error: aborting due to 3 previous errors Some errors have detailed explanations: E0107, E0515. For more information about an error, try `rustc --explain E0107`. </ins>

Discussion:
The following is an attempted minimum reproducible sample that causes ICE. From a few minutes of experimentation, I wasn't able to further minimize the example, but I feel as if it should be possible (perhaps an example can be formed with just an async boundary and a mutex?). <!-- 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. --: Also saw the ICE on nightly, but I can't seem to get my instance of cargo to recognize the 1.52 toolchain. Testing on shows this still is present: The following outputs are the result of building on nightly playgound: <details<summary<strongBacktrace</strong</summary<p</p</details
Smaller:
Relevant code: So I think that just needs to be a .
I've actually been looking to contribute to Rust—would this be a good first issue to tackle?
This would definitely be a good first issue!