jiebi/CodeConvo huggingface dataset:
Change:
// up clobbering `/dev/null`. Instead we'll use a non-existent path, which // also used to ICE, but even root can't magically write there. <del> // compile-flags: -o /does-not-exist/output </del> <ins> // compile-flags: -o ./does-not-exist/output </ins> // The error-pattern check occurs *before* normalization, and the error patterns // are wildly different between build environments. So this is a cop-out (and we

Discussion:
The test fails for me locally on the master branch (and was failing for a while now). I can of course ignore it, but it's annoying. also fails if run after/with . It looks like successfully creates a temp directory even if it's parent does not exist: <details<summaryoutput</summary<p</p</detailsThis causes the failure (as the test is expected to not compile) and also creates the directory, which then observes and also fails. This happens for me on the . cc iirc you had the same problems cc you changed those tests at some point, so maybe you know something
Summing up findings from discord, This test is wrong in its entirity since it gambles on permissions. The underlying subcommand creates the dir if you have enough permission to create in so it would fail. Otherwise, the directory is never created due to insufficient user permission, so the test passes. To sum it up, the test passed (for me) since I did not have enough permission to create a new directory () in : !
The test assumes that the compiler uses and so it must fail to create , but this is actually not the case: The test happens to pass in the CI and for many developers because you generally can't create a directory in . However this is not always the case (for example I happen to run tests in chroot). suggests that the proper fix for the test would be for the test to create an inaccessible directory, basically making a analog to
That still doesn't work if you're the root user, but I guess that's not what you're doing in your chroot? You could use a path like where even root can't create anything, but there's no OS-agnostic path like that.
I guess my point is that was broken on root anyway (because root has access to , same as in chroot). The explanation in the test was because of the original test it looks like, which works because it uses which requires at least the "parent must exist". So change -- now works on root, but doesn't work on chroot anymore does not work on root/chroot, but also doesn't clobber My change: unchanged now works in chroot Sooo, while fails on root, since it doesn't have global effects (clobbering as it originally did), I don't think it's a big deal.

IMO you are not supposed to run tests on root (but it's also bad for tests to have global effects)...
Yeah, that's fair -- we don't have to support root, but it should at least do no harm. While you're poking at that, maybe you can fix the filename spelling to "inaccessible"?
Fixed the spelling, thanks.
Change:
<del> //@ known-bug: rust-lang/rust#128810 #![feature(fn_delegation)] use std::marker::PhantomData; pub struct InvariantRef<'a, T: ?Sized>(&'a T, PhantomData<&'a mut &'a T>); impl<'a> InvariantRef<'a, ()> { pub const NEW: Self = InvariantRef::new(&()); } trait Trait { fn foo(&self) -> u8 { 0 } fn bar(&self) -> u8 { 1 } fn meh(&self) -> u8 { 2 } } struct Z(u8); impl Trait for Z { reuse <u8 as Trait>::{foo, bar, meh} { &const { InvariantRef::<'a>::NEW } } } fn main() { } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [checkmatch] match-checking -- label +F-constgenerics +F-constevaluatablechecked
Slightly minimized with fewer errors: The compiler seems to have trouble figuring out whether the type of matches the returned type <details<summaryProgram output</summary</summary

<!-- 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<strongICE location label +F-fn_delegation
Adding more methods in trait creates more ICE :eyes: <details<summary<strongBacktrace</strong</summary<p</p</details
Change:
<ins> #![feature(layout_for_ptr)] use std::mem; #[repr(packed(4))] struct Slice([u32]); #[repr(packed(2), C)] struct PackedSized { f: u8, d: [u32; 4], } #[repr(packed(2), C)] struct PackedUnsized { f: u8, d: Slice, } impl PackedSized { fn unsize(&self) -> &PackedUnsized { // We can't unsize via a generic type since then we get the error // that packed structs with unsized tail don't work if the tail // might need dropping. let len = 4usize; unsafe { mem::transmute((self, len)) } } } fn main() { unsafe { let p = PackedSized { f: 0, d: [1, 2, 3, 4] }; let p = p.unsize() as *const PackedUnsized; // Make sure the size computation correctly adds exact 1 byte of padding // in front of the `d` field. assert_eq!(mem::size_of_val_raw(p), 1 + 1 + 4*4); // And likewise for the offset computation. let d = std::ptr::addr_of!((*p).d); assert_eq!(d.cast::<u32>().read_unaligned(), 1); } } </ins>

Discussion:
This code panics, but it should not: The panic disappears when the is inlined (because then we hit a different code path in ). What happens here is a bug in the logic that computes the offset of : since it is an unsized field, the offset is computed dynamically, by taking the statically known offset and then rounding it up to the dynamic alignment of the field. However, since the struct is packed, we need to cap the dynamic alignment of the field to the packing of the surrounding struct -- which we currently do not do. This is just yet another case where the non-compositional nature of is causing issues...
A slight variant of this code ICEs: It hits which, it seems, was never updated when support for was implemented.
WG-prioritization assigning priority (). label -I-prioritize +P-medium EDIT: lowered priority after discussion on Zulip
Change:
span: Span, ) -> &'ll DIVariable { let loc = self.lookup_debug_loc(span.lo()); <del> let file_metadata = file_metadata(self, &loc.file.name, dbg_context.defining_crate); </del> <ins> let file_metadata = file_metadata(self, &loc.file, dbg_context.defining_crate); </ins> let type_metadata = type_metadata(self, variable_type, span);

Discussion:
shows a pretty big regression between and . I don't know if this is expected, but I'm putting this out there in case others see the dent in perf charts and wonder what had happened. <hr/EDIT( we how have a for . , the other PR in the range, (but only for a small subset of runs).
cc
The range is so the candidates are: "Make the rustc respect the flag in incremental mode." "Add hash of source files in debug info" EDIT: oops, missed - so it's likely . Slow MD5 implementation? I'm curious, why does (merge commit for ) not have its own perf run? Is there a way to trigger one now?
is in the queue:
It looks like this was caused by . I'll start investigating why. I timed several compilations of locally in debug with and without .
For the record, from . I'll update the issue description to minimize potential confusion. Two things I'm seeing: are way worse regressions than , you can focus on the worse ones to get better contrast in measurements (e.g. even has "patched incremental" runs slowed down a lot, unlike many others, being another example I guess) detailed profile (if you click the percentage for a run) shows a lot of LLVM differences, e.g. for , and most of the regressions are , with effectively no ones, so I think we might be able to get away without a revert, just adding a flag controlling whether LLVM sees these hashes (assuming that's the source of the slowdown)
We have (), which at a glance looks right. looks like noise, and so does , so I believe this confirms the fix is complete. For the cost of MD5 hashing compared to SipHash, based on the changes to runs in the original regression, it looks insignificant.
Change:
Self::Prefix(x) => format!("prefix with `{}@`", x).into(), Self::Function => "add parentheses".into(), Self::Macro => "add an exclamation mark".into(), <ins> Self::RemoveDisambiguator => "remove the disambiguator".into(), </ins> } }

Discussion:
Unfortunately I don't have an easy-to-repro case. This happened while working on Rocket's docs. I renamed a method which made a previously valid link invalid and I got this ICE. Fixing the doc link fixes the error. Backtrace from rustc 1.54.0-nightly ( 2021-05-21) follows: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If someone can compile a build of rustdoc that comments out this line: you should get a much better error message that says exactly what went wrong (it will start with "incompatible link kind"), and that should give an idea of where the bug is.
can you link to the exact commit of Rocket that caused the ICE?
This is the current tip, You may be able to replicate this by referencing in the struct's docs in and then changing the method's name to something else. If this fails, I will try to create a reproducible case.
MCVE: label -E-needs-mcve
claim
Error: Parsing relabel command in failed: ...'needs-MCVE' '): rs'... Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'needs-mcve' '): rs'... Please let know if you're having trouble with this bot.
Change:
<ins> // Regression test for #73727 // revisions: full min //[full]check-pass #![cfg_attr(full, feature(adt_const_params))] #![cfg_attr(full, allow(incomplete_features))] fn a<const X: &'static [u32]>() {} //[min]~^ ERROR `&'static [u32]` is forbidden as the type of a const generic parameter fn main() { a::<{&[]}>(); } </ins>

Discussion:
<!-- 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
This works with because the type is forbidden. However, it continues to ICE with .
No longer ICEs since
Change:
use middle::def_id::DefId; use middle::subst::{self, SelfSpace, TypeSpace}; use middle::traits; <del> use middle::ty::{self, ToPolyTraitRef, Ty}; </del> <ins> use middle::ty::{self, HasTypeFlags, ToPolyTraitRef, Ty}; </ins> use std::rc::Rc; use syntax::ast;

Discussion:
Attempting to compile the following with my  crate yields an ICE: Output from
Reduced:
I'm able to reproduce this exact same error on stable and nightly today using this 8 line example:
Change:
ui/issues/issue-12612.rs ui/issues/issue-12660.rs ui/issues/issue-12677.rs <del> ui/issues/issue-12699.rs </del> ui/issues/issue-12729.rs ui/issues/issue-12744.rs ui/issues/issue-12860.rs

Discussion:
Perhaps I'm holding it wrong? About a fifth of the rustc UI test suite to fail on wasm32-unknown-emscripten when trying to run . In all cases we get an error like this:
Does this target use some different main symbol name?
... do we need to pass --no-entry to lib builds? can you check if (some of) the failing tests are lib crates? Actually what am I doing, I can check
I can't get past the building test helpers for this target cross-compiling from msvc host, not sure what's up with that.
Huh. cc Can you make it any further?
Because there's an open PR for this.
In the open platform support docs PR this says It's recommended to test the  target instead for WebAssembly compatibility. ... so I don't know, is this expected failure?
See I was able to get past the build helpers stage by properly acquring the toolchain and making relevant env vars available to bootstrap. Didn't bother trying to diagnose past stage 1 std and tests because there's like a chain of failures. Notably I see
The failing link command includes: if we replace that with , then it links as expected. But then it fails to run it at: We should invoke with node.
So I guess for starters we should do:
Combined with setting the runner to this fixes most of the failing tests:
The failures seem to be: and seems like it hangs? sounds like an xfail.
Change:
root_ty: ty, }; <del> let ty = generalize.relate(&ty, &ty)?; </del> <ins> let ty = match generalize.relate(&ty, &ty) { Ok(ty) => ty, Err(e) => { debug!("generalize: failure {:?}", e); return Err(e); } }; </ins> let needs_wf = generalize.needs_wf; <ins> debug!("generalize: success {{ {:?}, {:?} }}", ty, needs_wf); </ins> Ok(Generalization { ty, needs_wf }) } }

Discussion:
When using the nightly with the bugfix for the problems with , this error happens when trying to document the crate: note: rustc 1.31.0-nightly ( 2018-10-01) running on x86_64-apple-darwin
cc: FYI
it seemed to document fine for me on the most recent nightly build
This is fixed as of
Closing then! Thanks! :D
Will this need backporting at all?
Change:
NativeLibKind::Static { bundle, whole_archive } => { if link_static { let bundle = bundle.unwrap_or(true); <del> let whole_archive = whole_archive == Some(true) // Backward compatibility case: this can be a rlib (so `+whole-archive` // cannot be added explicitly if necessary, see the error in `fn link_rlib`) // compiled as an executable due to `--test`. Use whole-archive implicitly, // like before the introduction of native lib modifiers. || (whole_archive == None && bundle && cnum == LOCAL_CRATE && sess.is_test_crate()); </del> <ins> let whole_archive = whole_archive == Some(true); </ins> if bundle && cnum != LOCAL_CRATE { if let Some(filename) = lib.filename { // If rlib contains native libs as archives, they are unpacked to tmpdir.

Discussion:
Originally reported as , but the actual bug affects every libraries and platforms. generates the linker command . Without it correctly doesn't link whole archive. It is expected to link whole archive only if passing modifier.
or whoever wants to look at linkage troubles today
Looks like it is a back compat hack:
Not sure to understand why tests are special, but it's intentional from indeed. Feels like a bad workaround for missing +whole-archive modifiers in some projects?
My reading from the code comment is that you can't aren't allowed to use for tests of rlib crates at all, not that some projects are missing it.
Why is that not allowed? That would be the root issue then?
It seems like and are not compatible with each other for rlibs. Someone else may know better why this is the case. It's been a while since I last looked at this code.
The combination was recently stabilized in so it may be possible to remove this hack now. We'll just need to run crater, send fixes to affected crates, and all that stuff.
Fixed in
Change:
None => continue, }; <del> if binding.is_import() || binding.is_macro_def() { </del> <ins> // Filter away "empty import canaries". let is_non_canary_import = binding.is_import() && binding.vis != ty::Visibility::Invisible; if is_non_canary_import || binding.is_macro_def() { </ins> let def = binding.def(); if def != Def::Err { if let Some(def_id) = def.opt_def_id() {

Discussion:
https://crater-, This appears to ICE on nightly so maybe that's the underlying cause? cc
Fixed in
Change:
/// Returns a diagnostic reporting a struct pattern which does not mention some fields. /// /// ```text <del> /// error[E0027]: pattern does not mention field `you_cant_use_this_field` </del> <ins> /// error[E0027]: pattern does not mention field `bar` </ins> ///   --> src/main.rs:15:9 ///    | /// LL |     let foo::Foo {} = foo::Foo::new(); <del> ///    |         ^^^^^^^^^^^ missing field `you_cant_use_this_field` </del> <ins> ///    |         ^^^^^^^^^^^ missing field `bar` </ins> /// ``` fn error_unmentioned_fields( &self,

Discussion:
I tried this code: I expected to see this happen: A suggestion to change to Instead, this happened: A suggestion to change to (note the extra comma!) With the comma at the end, I get a parser error and a suggestion to remove the comma. Nightly on playground: 1.49.0-nightly (2020-10-27 )
modify labels: +A-diagnostics
Change:
asm!("adr r0, {}", sym extern_static); } <ins> // Regression test for #82052. // CHECK-LABEL: issue_82052 // CHECK: push {{.*}}lr // CHECK: @APP // CHECK: @NO_APP pub unsafe fn issue_82052() { asm!("", out("r14") _); } </ins> macro_rules! check { ($func:ident $ty:ident $class:ident $mov:literal) => { #[no_mangle]

Discussion:
I attempted to compile a crate containing the following expression: I expected it to compile successfully. Instead, I received this error: : omitted, it did not produce anything else. diagnosed the cause and offered a solution .
While I try to spin up a rustc development environment, can someone point me to the tests for this code? I don't see any tests in the crate.
I think I have a working development environment now. I'll try to fix this -- thank you for making this easy for me!
Change:
} if GitInfo::new(false, Path::new(submodule)).is_managed_git_subrepository() { <del> self.update_submodule(submodule); </del> <ins> self.config.update_submodule(submodule); </ins> } }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: in is not specified explicitly, the default value is used. I expected to see this happen: LLVM is downloaded from CI, when LLVM version is bumped the new LLVM is downloaded from CI as well. Instead, this happened: LLVM starts building from source code after an LLVM update, instead of being downloaded, unless I remove the build directory and do a fresh build, then it starts downloading from CI again. <!-- 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. --:
Or maybe it's a stage0 toolchain update that triggers this issue, not LLVM update (I observed this today). But I've seen this issue several times in the past as well. cc
The section in is completely empty, nothing is overridden.
Update: LLVM is built from source only on the first build attempt, after that it is correctly downloaded from CI.
This is still an issue that I observe regularly.
There were some issues with the change detection logic for LLVM and I think should fix it. Let's see if it still happens with the next LLVM update.
Change:
<ins> // Make sure the compiler does not ICE when trying to generate the debuginfo name of a type that // causes a layout error. See https://github.com/rust-lang/rust/issues/94961. // compile-flags:-C debuginfo=2 // build-fail // error-pattern: too big for the current architecture // normalize-stderr-64bit "18446744073709551615" -> "SIZE" // normalize-stderr-32bit "4294967295" -> "SIZE" #![crate_type = "rlib"] pub struct Foo<T>([T; usize::MAX]); pub fn foo() -> usize { std::mem::size_of::<Foo<u8>>() } </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. --code from glacier <!-- 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. --: with cc <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This would previously just throw an error but not "crash": `
I'll look into it. Thanks for the bug report!
Change:
<ins> error: expected `::`, found `:` --> $DIR/use-colon-as-mod-sep.rs:3:17 | LL | use std::process:Command; |                 ^ help: use double colon | = note: import paths are delimited using `::` error: expected `::`, found `:` --> $DIR/use-colon-as-mod-sep.rs:5:8 | LL | use std:fs::File; |        ^ help: use double colon error: expected `::`, found `:` --> $DIR/use-colon-as-mod-sep.rs:7:8 | LL | use std:collections:HashMap; |        ^ help: use double colon error: expected `::`, found `:` --> $DIR/use-colon-as-mod-sep.rs:7:20 | LL | use std:collections:HashMap; |                    ^ help: use double colon error: aborting due to 4 previous errors </ins>

Discussion:
I tried this code: I expected to see this happen: I expected to see two diagnostic messages, telling me about the distinct parse errors on lines 1 and 2. Instead, this happened: The first error was treated as non-recoverable, yielding this output (): I'm assuming recovering in the face of this parse error would be a relatively simple task, given that there is already the present that should be a strong hint that someone meant to type . So I'm tagging this with labels indicating that its a good opportunity for someone who wants to acquaint themselves with the code base. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(This needs a mentor. I am thinking that if someone doesn't pick it up by Friday, then I will see about using it as the basis for one or more instructional videos.)
I can mentor whoever wants to work on this. See for the general area where changes need to be made, and ping me if someone needs help on Zulip.
May I work on this?
You can , and I recommend checking out the to find out what the contribution process looks like.
i would like to work on this with your help.
claim
release-assignment
This is mostly about adding checks around such that it recovers when encountering . However, we would also need the ability to recover to be configurable as arguments to , as we would want to recover from as well. PS: don't take this as is.. I am not that familiar with ast and recovery, but I think this is the main idea
I will take a quick look into this. claim
Change:
_, ) => Err((span, "function pointer casts are not allowed in const fn".into())), Rvalue::Cast(CastKind::Pointer(PointerCast::Unsize), op, cast_ty) => { <del> let pointee_ty = cast_ty.builtin_deref(true).unwrap().ty; </del> <ins> let pointee_ty = if let Some(deref_ty) = cast_ty.builtin_deref(true) { deref_ty.ty } else { // We cannot allow this for now. return Err(( span, "unsizing casts are only allowed for references right now".into(), )); }; </ins> let unsized_ty = tcx.struct_tail_erasing_lifetimes(pointee_ty, tcx.param_env(def_id)); if let ty::Slice(_) | ty::Str = unsized_ty.kind { check_operand(tcx, op, span, def_id, body)?;

Discussion:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Is it a regression from stable to beta if it doesn't compile on stable? I this to the original comment: On rust stable 1.45.1, it causes this compilation error instead:
Yes, the error message regressed. I don't know if the code is supposed to compile on beta or if it should still fail with the same error, but an ICE is a regression either way.
I think the failure is introduced in and this unwrap causes it: So, my thought is we shouldn't unwrap here and return instead if it's . is this correct?
Yes, return an error mentioning that unsizing is only allowed for references right now.