jiebi/CodeConvo huggingface dataset:
Change:
use rustc_hir as hir; use rustc_hir::Node; use rustc_index::vec::Idx; <ins> use rustc_middle::hir::map::Map; </ins> use rustc_middle::mir::{Mutability, Place, PlaceRef, ProjectionElem}; use rustc_middle::ty::{self, Ty, TyCtxt}; use rustc_middle::{

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. --: The internal compiler error does not occur in stable (): The fix for compilation is to use instead of and this also prevents the panic in the nightly version of rustc. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
It would be nice to reproduce this without the async-std dependency.
Slightly smaller:
I bisected far enough to find it regressed between the 9th and 10th, then ran out of disk space :facepalm:
Smaller example without
Here you go. The async part doesn't seem important and the issue still occurs with the versions of and and removed from dependencies: It could probably be reduced in size further but I'm not much of a Rust expert. I suspect anything which triggers that particular compiler error would do the trick.
searched nightlies: from nightly-2021-02-10 to nightly-2021-02-11 regressed nightly: nightly-2021-02-11 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Probably cc In particular looks suspect.
Are functions registered as items in the hir? edit: nvm just saw that someone posted a non-async example
Change:
dist-install-dir-$(1): PREPARE_LIB_CMD=$(DEFAULT_PREPARE_LIB_CMD) dist-install-dir-$(1): PREPARE_MAN_CMD=$(DEFAULT_PREPARE_MAN_CMD) dist-install-dir-$(1): PREPARE_CLEAN=true <del> dist-install-dir-$(1): prepare-base-dir-$(1) docs compiler-docs </del> <ins> dist-install-dir-$(1): prepare-base-dir-$(1) docs </ins> $$(Q)mkdir -p $$(PREPARE_DEST_DIR)/share/doc/rust $$(Q)$$(PREPARE_MAN_CMD) $$(S)COPYRIGHT $$(PREPARE_DEST_DIR)/share/doc/rust $$(Q)$$(PREPARE_MAN_CMD) $$(S)LICENSE-APACHE $$(PREPARE_DEST_DIR)/share/doc/rust

Discussion:
I got the message above,how to fix it?
Urgh. This should never have gotten through the CI bots. Some rules must be being built by the install target that aren't under the normal build.
I will try to look into this today while I'm investigating other nightly breakage.
I assume this is being introduced by the doc comment I wrote here: So the two bugs here are: the above doc comment in dropck. (Presumably just replace the indents with nested bullets.) rules do we need to change to synchronize with the CI bots (to catch this kind of case in the future) -- presumably its happening because attempts to build documentation for rust itself ... which sounds a lot like good old: ; see also
I posted a PR to stop building compiler docs. It does not fix the bug in the docs though.
Fixed.
Er, oh yeah, the underlying problem is not fixed, that the docs have broken examples.
Sigh, actually, I'll call this fixed since the title of the bug is about install failure and that works now. Broken examples in the rustc crate are nbd to me atm.

Just downloaded a fresh install from git and ran on a virgin arch linux box running on AWS and getting this error again cfg: using CC=gcc (CFGCC) cfg: disabling valgrind run-pass tests cfg: including prepare rules cfg: including dist rules cfg: including install rules cleaning destination tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/bin prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/lib prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/lib/rustlib/etc prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/share/man/man1 rustc: x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-gnu/lib/librustc recipe for target 'x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-' failed make[1]:  [x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-] Killed make[1]: Leaving directory '/root/Downloads/rust' recipe for target 'install' failed make:  [install] Error 2 any ideas
Change:
<ins> error: malformed `coverage` attribute input --> $DIR/bad-attr-ice.rs:10:1 | LL | #[coverage] | ^^^^^^^^^^^ | help: the following are the possible correct uses | LL | #[coverage(off)] | LL | #[coverage(on)] | error: aborting due to 1 previous error </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Cinstrument-coverage -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected value of coverage attribute', 'error: internal compiler error: unexpected value of coverage attribute' 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: [coverageattron] checking for on [mirbuilt] building MIR for -- label +F-coverageattribute
Regression in
Change:
# #![feature(asm)] # #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] # fn main() { unsafe { <del> asm!("xor %eax, %eax" ::: "{eax}"); </del> <ins> asm!("xor %eax, %eax" ::: "eax"); </ins> # } } ```

Discussion:
The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.
Change:
<ins> struct Bug<A = [(); (let a = (), 1).1]> { //~^ `let` expressions are not supported here //~^^ `let` expressions in this position are unstable [E0658] a: A } 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I was just looking at the parsing code for const generic exprs.. claim
actually, so this isn't related to incorrectly parsing , since we're parsing in expr position to allow if-let chains.. -- this is due to const eval lowering to MIR and the fact that const generic parameters have no enclosing scope. Adding around the generic args works, but I don't know where exactly to hack in a scope for these params. release-assignment label A-const-eval A-mir
Maybe fixing this also fixes :slightlysmilingface:
This gives an error without ICE in 1.55
It was unclear to me - I think meant that changing to gives a compile error instead of an ICE. So the proper fix here is probably to add somewhere instead of panicking.
Then this should be easy. claim
Change:
} impl Slice { <ins> #[inline] </ins> fn from_u8_slice(s: &[u8]) -> &Slice { unsafe { mem::transmute(s) } } <ins> #[inline] </ins> pub fn from_str(s: &str) -> &Slice { Slice::from_u8_slice(s.as_bytes()) }

Discussion:
Godbolt link: I expect these two snippets have the same optimized asm but they don't:
I think the bigger problem here is that the quite trivial AsRef and PartialEq implementations did not get inlined. I would not expect anything to optimize well without those getting inlined.
I'm not sure we can expect these two to give you the same assembly. They are actually a bit different -- the first one will construct conditionally ( will call the closure only for ), whereas the second one will create the unconditionally before even checking if the parameter is or . As for the differences in the assembly wrt. comparisons themselves, this seems to be due to the difference between the code to check for equality of vs . I wonder, do you have a particular benchmark/workload where the first function is slower than expected?
Still, if I change the first snippet like below, [the asm][1] is different too: [1]:
is effectively a pointer cast, so it is warranted to expect assembly of at least similar quality. Inlining does not happen because we do happen to have generated machine code for these trivial functions in Tacking some s should suffice?
After inlining some methods in , I got the same asm between those two snippets:
Change:
RawNullablePointer { nndiscr, nnty, ..} => { if discr != nndiscr { let llptrty = type_of::sizing_type_of(bcx.ccx(), nnty); <del> Store(bcx, C_null(llptrty), val) </del> <ins> Store(bcx, C_null(llptrty), val); </ins> } } StructWrappedNullablePointer { nndiscr, ref discrfield, .. } => { if discr != nndiscr { let llptrptr = GEPi(bcx, val, &discrfield[..]); let llptrty = val_ty(llptrptr).element_type(); <del> Store(bcx, C_null(llptrty), llptrptr) </del> <ins> Store(bcx, C_null(llptrty), llptrptr); </ins> } } }

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:
/// vec.extend_from_within(4..8); /// assert_eq!(vec, [0, 1, 2, 3, 4, 2, 3, 4, 0, 1, 4, 2, 3, 4]); /// ``` <del> #[unstable(feature = "vec_extend_from_within", issue = "81656")] </del> <ins> #[stable(feature = "vec_extend_from_within", since = "1.53.0")] </ins> pub fn extend_from_within<R>(&mut self, src: R) where R: RangeBounds<usize>,

Discussion:
Feature gate: This is a tracking issue for , which allows copying elements from a range to the end: <!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] Implementation: [x] Final commenting period (FCP) [x] yet.
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
: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. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Change:
.filter(|arg| arg.is_const()) .position(|arg| arg.id() == hir_id) .map(|index| (index, seg)) <del> }) .unwrap_or_else(|| { bug!("no arg matching AnonConst in path"); </del> }); <ins> let (arg_index, segment) = match filtered { None => { tcx.sess.delay_span_bug( tcx.def_span(def_id), "no arg matching AnonConst in path", ); return None; } Some(inner) => inner, }; </ins> // Try to use the segment resolution if it is valid, otherwise we // default to the path resolution.

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting another error, so low priority. Affected versions: I tried nightly 2021-11-25 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I will give this a try claim
Change:
let loc = info.location().unwrap(); // The current implementation always returns Some let msg = info.message().unwrap(); // The current implementation always returns Some <del> rust_panic_with_hook(&mut PanicPayload::new(msg), info.message(), loc); </del> <ins> crate::sys_common::backtrace::__rust_end_short_backtrace(move || { rust_panic_with_hook(&mut PanicPayload::new(msg), info.message(), loc); }) </ins> } /// This is the entry point of panicking for the non-format-string variants of

Discussion:
v.s. is less verbose, but I remember it also filtering out some stack frames in some previous compiler versions. (Only frame # 6 is really useful to me here.) Indeed, contains some code that looks for a symbol on the stack to find out what to filter. It looks like some functionality has regressed. Stepping through the program in gdb it looks like the function is called, but despite there’s apparently no stack frame (anymore?) for it. CC and for , , and .
contains a fix for this
Now being worked on in instead afaict?
It is.
This issue hasn't been active in almost two years, and so have the issues linked here. Is there any intention of resuming work on this? It's mostly a small papercut because currently when crashing, programs suggest: run with environment variable to display a backtrace. and after setting that, also claim that: Some details are omitted, run with for a verbose backtrace. even though no details were omitted at all (which is the issue of course)
A simple fix would be to just look for "std::rt::lang_start::{{closure}}" instead until the real solution to the disappearing function is found..
This single fix is likely to have the biggest positive effect on my use of Rust since async/await. Thank you so much!
Awesome! I'm happy to see this finally fixed :D Thanks to everyone who had a part in this fix :)
Change:
bug!("encountered a fresh type during canonicalization") } <del> ty::Placeholder(placeholder) => self.canonicalize_ty_var( CanonicalVarInfo { kind: CanonicalVarKind::PlaceholderTy(placeholder) }, t, ), </del> <ins> ty::Placeholder(mut placeholder) => { if !self.canonicalize_mode.preserve_universes() { placeholder.universe = ty::UniverseIndex::ROOT; } self.canonicalize_ty_var( CanonicalVarInfo { kind: CanonicalVarKind::PlaceholderTy(placeholder) }, t, ) } </ins> ty::Bound(debruijn, _) => { if debruijn >= self.binder_index {

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
I can't reproduce this? On master, that is.
Ah oops, looks like I minimized wrongly, give me a sec...
This should do: `
Minimized -- PR coming up.
Change:
<ins> #![feature(inline_const)] #![feature(yeet_expr)] #![allow(incomplete_features)] // Necessary for now, while explicit_tail_calls is incomplete #![feature(explicit_tail_calls)] fn a() { let foo = { 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn b() { let foo = for i in 1..2 { break; } else { //~^ ERROR `for...else` loops are not supported return; }; } fn c() { let foo = if true { 1 } else { 0 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn d() { let foo = loop { break; } else { //~^ ERROR loop...else` loops are not supported return; }; } fn e() { let foo = match true { true => 1, false => 0 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } struct X {a: i32} fn f() { let foo = X { a: 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn g() { let foo = while false { break; } else { //~^ ERROR `while...else` loops are not supported return; }; } fn h() { let foo = const { 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn i() { let foo = &{ 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn j() { let bar = 0; let foo = bar = { 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn k() { let foo = 1 + { 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn l() { let foo = 1..{ 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn m() { let foo = return { () } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn n() { let foo = -{ 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn o() -> Result<(), ()> { let foo = do yeet { () } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return Ok(()); }; } fn p() { let foo = become { () } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn q() { let foo = |x: i32| { x } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn main() {} </ins>

Discussion:
I believe the intention in let-else is that this code should be considered syntactically invalid, but it compiles successfully today. If you replace with , it correctly fails to parse.
I believe here is the missing case for ExprKind::ConstBlock: This should be changed to an exhaustive match so that future new ExprKind variants are forced to touch this code. Some other unhandled cases that can end in : ExprKind::Become ExprKind::FormatArgs ExprKind::IncludedBytes ExprKind::InlineAsm ExprKind::MacCall ExprKind::OffsetOf ExprKind::Yeet
Change:
mod common; use common::test_rng; <ins> use std::thread; </ins> #[track_caller] fn make_rand_name() -> OsString {

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. --Investigating library sources for , I have found that the copying of the env variable value is performed not under the lock: So there is a potential data race with setenv. I tried this code with miri And got Have tried to move under the lock, but still got error with miri. I was not able to trigger the real crash with it yet. <!-- 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. --: Bug was introduced by this commit: (PR: ) Before that changes, read was under the lock. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
I think this happened because implicit scoping of the lock guard, which makes it easy to shorten its lifetime the rwlock isn't coupled to the resource via a lifetime, so it's easy for the extracted pointer to be used longer than the lock is valid The first one could be made more visible by linting to add an explicit to make its lifetime more explicit in the code when a critical section ends. Especially when guard is otherwise unused which indicates that the lock doesn't directly own the resource it protects. The second one could be solved by using a lifetime-tagged raw pointer and coupling that lifetime to the guard.
Side note: even when fixed this assumes all other read/writes acquire Rust's lock and is potentially unsound if they do not. This has often been discussed with a view to making unsafe. Arguably if that happens then the lock would be redundant, although it could also be argued it's still useful to help avoid some footguns even if you can't make it totally safe.
That's
That PR did not add a test, did it? Would be good to add one in (those are run in Miri regularly). We probably don't want iterations though, that will take forever. 100 should easily be enough.
Something like ?
Yeah something like that.

For Miri it's not really necessary to do this "sum of the lengths" computation, not sure why that would be particularly susceptible to a data race. The one existing concurrency test uses , so probably it would make sense to use the same attribute here.
Change:
<ins> error[E0191]: the value of the associated type `Item` in `Iterator` must be specified --> $DIR/associated-type-shadowed-from-non-local-supertrait.rs:8:27 | LL |     type Item; |     --------- `Iterator::Item` shadowed here, consider renaming it ... LL | impl<T> Clone for Box<dyn NewIter<Item = T>> { |                           ^^^^^^^^^^^^^^^^^ associated type `Item` must be specified error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0191`. </ins>

Discussion:
Given the following code: The current output is: is wrong, specifying another isn't going to fix the problem. Writing just has a suggestion where`, which is good, but the concrete syntax would be nice. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We probably should modify E0191 to hint that an supertrait's associated type is shadowed. I think E0719 here is fine to keep as-is, imo.
I agree the message for E0719 is good as-is.
Is this issue fixed ? If not can I take this up, please. Also how exactly should E0191 be modified. Imo, I don't think E0191 should pop up in this case as E0719 conveys the message.
claim
claim
Ask for help How do I specify the association type of supertrait with the same name? In other words, is there an easy way to modify the code in the issue to make it pass compilation? Here's my clumsy way of creating a new trait.
Is this issue still open? If so I would like to take a crack at it.
If you can still reproduce it, then yes indeed. assign
Error: Parsing assign command in failed: ...'zyDutchman' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I have now a hint about the shadowing: But I am not quite sure about what to do about the actual message. Do we want to suggest renaming to something else Or do we want to suggest the work-around by
If the trait is local, then we could suggest renaming it. It's not required to be super specific here--we could just note the conflict to make the user aware of it, for example.
I have updated the help message so that this case: gives this error message: The rename help message is emitted for both the super trait and the subtrait, if they are local. I think I am ready to make a merge request, or does somebody have something else to add?
I recommend you to just open a PR. Any further discussions can happen over there :)