jiebi/CodeConvo huggingface dataset:
Change:
// Store off these values as options because if they're not provided // we'll infer default values for them later <ins> let mut llvm_skip_rebuild = None; </ins> let mut llvm_assertions = None; let mut debug = None; let mut debug_assertions = None;

Discussion:
The compiler LLVM is rebuilt whenever the built version of LLVM doesn't have the right hash. (Previously it was rebuilt based on a special marker file, which was easier to work around.) However, most of the time, having the latest LLVM version is not necessary, but makes rebuilding rustc after rebasing take significantly longer, which is a pain. It would be good to be able to disable this as an option in for convenience. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
To fix this, you'll want to add another option: you should be able to look at the logic for something like .
It would be good if this could be changed in the config file so you don't have to pass in the option all the time.
if it's a config file option, then there should be an option to rebuild it if necessary. I.e. it shouldn't be necessarily to temporarily change the to rebuild.
sure that seems good, although they can be implemented separately.
The line you would need to change is near this one: (line 735 of ) It would probably be much easier to add a check against a key in the config, than to add a new flag.
claim
Error: Parsing assign command in failed: claim ... Please let know if you're having trouble with this bot.
, my bad! claim EDIT: oh dear, I'm making it worse
are you still working on this? I wouldn't mind picking it up if not. (Sorry - not really sure what the etiquette is re: dormant tickets!)
Just saw that PR () lapsed. I'm gonna claim this, if that's okay. Will work on something based on the existing comments there. claim
Thank you for picking this up! Getting things fixed is the important thing, and I'm sure I'll find something else to fix in the near future when I have more time
Change:
<ins> // check-pass pub struct A<'a>(&'a ()); impl<'a> A<'a> { const N: usize = 68; pub fn foo(&self) { let _b = [0; Self::N]; } } fn main() {} </ins>

Discussion:
ICE message: <details<summaryBacktrace</summary</summary
This should be erroring in exhaustiveness checking; shouldn't be allowed there. cc
It should be erroring earlier, when trying to create a pattern out of the constant. And it should also not be considered structural-match type-wise.
Triage: This is no longer ICE, seems that it's fixed by , marking as E-needs-test.

gives: My guess is that this has the same underlying cause as , but this one doesn't involve associated consts or arrays at all, so it might be different still.
This appears to be due to a bad interaction between and associated type projections involving lifetimes. When we normalize the function signature during type-checking, we project to . We then convert back to the 'generic' region for , which is . However, this is a distinct early bound region, different from the in (changing the regions to not all be called in the example makes this clearer). This causes issues during , since we've essentially pulled a region out of thin air. This issue doesn't seem to come up for type parameters ( with lifetimes replaced with types). I'm not sure if this is because our handling of type parameters is correct for this kind of projection, or if we need a more complicated example to break things.
The ICE no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

I got an internal compiler error at commit . I dont know how to minimize it. Relevant code is: If I remove the const field and directly put the array size like below, the ICE goes away and I get the expected compilation error that [u8; 68] is not . <details<summaryBacktrace:</summary</details<details<summaryVersion info</summary</details
The ICE also goes away if I change to
Ok. I minimized it to just: It ICEs on latest nightly:
triage: P-high, assiging to self, removing nomination label
Following example fails to compile: <details<summaryError</summary</detailsEven if I add , still issue: or <details<summaryError</summary</detailsBut this works:
Also just got this; no idea how to minimize it and the trace doesn't seem useful:-
If this is referring to the field , it's defined as where is defined inside the impl as .
Inlining resolves the error, ie changing buffer's definition to .
no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.
Change:
} } <del> load_self().and_then(|path| Path::new_opt(path).map(|mut p| { p.pop(); p })) </del> <ins> load_self().and_then(Path::new_opt) } /// Optionally returns the filesystem path to the current executable which is /// running. Like self_exe_name() but without the binary's name. /// If any failure occurs, None is returned. pub fn self_exe_path() -> Option<Path> { self_exe_name().map(|mut p| { p.pop(); p }) </ins> } /**

Discussion:
On OS X at least, it will think the link itself is the executable, then calculate sysroot based on that. Thanks to kyle for the report.
nominating to change to production ready
accepted for production-ready milestone
triage bump. still annoying.
or could be used to resolve the symlink. Would this issue warrant the badge "E_easy"?
Seems so! Adding the E-easy label.
Note that the relevant code is and it probably needs a check to see whether is a symlink or not.
seems important to fix for polish reasons. Accepted for P-high.
Change:
<ins> error[E0308]: mismatched types --> $DIR/lazy_subtyping_of_opaques.rs:10:23 | LL | type Tait = impl FnOnce() -> (); |             ------------------- the found opaque type ... LL |     Thunk::new(|cont| cont) |                       ^^^^ expected `()`, found opaque type | = note: expected unit type `()` found opaque type `Tait` error[E0308]: mismatched types --> $DIR/lazy_subtyping_of_opaques.rs:10:5 | LL | fn reify_as_tait() -> Thunk<Tait> { |                       ----------- expected `Thunk<_>` because of return type LL |     Thunk::new(|cont| cont) |     ^^^^^^^^^^^^^^^^^^^^^^^ expected `Thunk<_>`, found `()` | = note: expected struct `Thunk<_>` found unit type `()` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
https://crater- https://crater- https://crater- https://crater- https://crater- https://crater- probably cc
Yeah Matthias also found . Think it hasn't been fixed b/c oli is on holiday -- I assume he will investigate when he's back next week.
MCVE in
WG-prioritization assigning priority (). I'll mark this as because it seems an unintended breaking change and therefore should probably be fixed before entering into stable. label -I-prioritize +P-critical

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: opaque types got hidden types registered from within subtype predicate: Alias(Opaque, AliasTy { args: [], defid: DefId(0:25 ~ ice[ee90]::Tait::{opaque}) }) vs Continuation', 'error: internal compiler error: opaque types got hidden types registered from within subtype predicate: Alias(Opaque, AliasTy { args: [], defid: DefId(0:25 ~ ice[ee90]::Tait::{opaque}) }) vs Continuation' 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 [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate -- label +F-typealiasimpl_trait
bit smaller
Change:
<ins> error: generic parameters may not be used in const operations --> $DIR/issue-80375.rs:1:41 | LL | struct MyArray<const COUNT: usize>([u8; COUNT + 1]); |                                         ^^^^^ cannot perform const operation using `COUNT` | = help: const parameters may only be used as standalone arguments, i.e. `COUNT` = help: use `#![feature(const_generics)]` and `#![feature(const_evaluatable_checked)]` to allow generic const expressions error: aborting due to previous error </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
According to Godbolt, this regressed in 1.39.0. Adding removes the ICE on latest nightly, which I think means this will be fixed by stabilization in . cc
Note that it doesn't ICE on the latest nightly (2020-12-25) with , but it still errors out because it's not supported under .
This is indeed fixed on master. I'll file a PR to add a regression test for this.
Change:
<ins> // compile-pass fn main() { assert_eq!(&mut [0; 1][..], &mut []); } </ins>

Discussion:
The build of smoltcp on nightly started failing recently with an ICE: https://travis- ~I suspect this might be caused by E0713, but it shouldn't be an ICE in any case.~
I believe the fundamental cause of the error is that the code looks like the following: That's pretty obviously unsound.
Correction for earlier comment: E0713 is completely unrelated. I've eliminated the problematic code that caused it in m-labs/smoltcp but the crash is still there.
cc (also, such an ICE should say "const checking" or similar - we should maybe even rename the pass itself in the compiler - the "qualify" part isn't as primary for MIR as it is for the AST side).
<details<summaryFull backtrace</summary</details<details<summaryfunction </summary</details
MCVE: : ok : ICE I'm bisecting it now.
Bisected to / .
Oh, I forgot about the ZST trickery, sorry, will have a fix tomorrow
What's the ZST here? in ?
Yes. That's a that gets unsized to .
Change:
if !up_to_date(src_file, dst_file) { let mut cmd = Command::new(&builder.initial_rustc); builder.run(cmd.env("RUSTC_BOOTSTRAP", "1") <del> .arg("--cfg").arg("stage0") </del> <ins> .arg("--cfg").arg("bootstrap") </ins> .arg("--target").arg(target) .arg("--emit=obj") .arg("-o").arg(dst_file)

Discussion:
We should only pass stage0 in general, should be sufficient for all use cases. cc for awareness and in case there's any concerns
Change:
<ins> fn main() { let _ = &&[0] as &[_]; //~^ ERROR non-primitive cast: `&&[i32; 1]` as `&[_]` let _ = 7u32 as Option<_>; //~^ ERROR non-primitive cast: `u32` as `std::option::Option<_>` } </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. --When trying to cast a slice, I encountered an ICE in nightly rust. It works in at least two different nightly versions: rustc 1.46.0-nightly ( 2020-06-26) and rustc 1.46.0-nightly ( 2020-06-29). I haven't tested any other versions. In stable rust (1.44.1), no ICE occurs. A minimal example to reproduce this is here: I expected the following result: Instead, I encountered an ICE. From the little testing I have done, it seems to require slices for the ICE to occur. Replacing the slices with structs causes the ICE to disappear. I got the ICE to work with the following two versions: : and It might work with earlier versions of nightly as well, but I haven't checked this. It does not occur with the latest stable version (1.44.1). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Let’s try to find the culprit for this. ping cleanup
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
searched nightlies: from nightly-2020-06-19 to nightly-2020-06-27 regressed nightly: nightly-2020-06-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details modify labels: -E-needs-bisection
Probably cc
Prioritized as as per .
Change:
)) } } <del> // checked by regular const fn checks Rvalue::NullaryOp(..) => Ok(()), </del> <ins> Rvalue::NullaryOp(NullOp::SizeOf, _) => Ok(()), Rvalue::NullaryOp(NullOp::Box, _) => Err(( span, "heap allocations are not allowed in const fn".into(), )), </ins> Rvalue::UnaryOp(_, operand) => { let ty = operand.ty(mir, tcx); if ty.is_integral() || ty.is_bool() {

Discussion:
<short summary of the bugReturning from a const fn causes internal compiler error, with the message 'bad input type for cast'. I tried this code: Minimal example Original example I expected to see this happen: program compiles and prints 'Hello 1' or I get a compiler error. Instead, this happened: ICE
that gives the exact backtrace above.
Relavent code: The types here are and .
The actual bug would be here then, right?
Not quite sure, but the real bug is that we allow the keyword in const fn XD I already have a fix since yesterday, but the german bahn didn't give me electricity so my notebook died while tests were running
no ICE fix from the ICE? :p
Change:
<ins> error[E0517]: attribute should be applied to enum --> $DIR/issue-74082.rs:3:8 | LL | #[repr(i128)] |        ^^^^ LL | struct Foo; | ----------- not an enum error[E0517]: attribute should be applied to enum --> $DIR/issue-74082.rs:6:8 | LL | #[repr(u128)] |        ^^^^ LL | struct Bar; | ----------- not an enum error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0517`. </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: I expected to see this happen: compilation failure Instead, this happened: Compiles, outputs "0" <!-- 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: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Should be a easy fix. claim
Change:
|     ^^^^^^^^^^^^^^^^^^ expected `String`, found `()` | note: method `push_str` modifies its receiver in-place <del> --> $DIR/chain-method-call-mutation-in-place.rs:3:7 </del> <ins> --> $DIR/chain-method-call-mutation-in-place.rs:7:7 </ins> | LL |     s.push_str("asdf") |     - ^^^^^^^^ this call modifies `s` in-place

Discussion:
In long method chains we might inadvertently call a method that is not meant to be chained. When this happens, the most likely error to occur is a type error involving . We should instead look if the rhs expression is a method chain and look at all the chained call's type to find where is introduced. Given Ideally the output would be closer to <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hi, I'd like to try working on this :) claim
Change:
let mut _0: ();                      // return place in scope 0 at $DIR/enum_cast.rs:+0:13: +0:13 let _1: ();                          // in scope 0 at $DIR/enum_cast.rs:+1:5: +6:6 let _2: Droppy;                      // in scope 0 at $DIR/enum_cast.rs:+2:13: +2:14 <del> let mut _4: isize;                   // in scope 0 at $DIR/enum_cast.rs:+5:17: +5:18 let _5: Droppy;                      // in scope 0 at $DIR/enum_cast.rs:+7:9: +7:10 </del> <ins> let _4: Droppy;                      // in scope 0 at $DIR/enum_cast.rs:+5:17: +5:18 let mut _5: isize;                   // in scope 0 at $DIR/enum_cast.rs:+5:17: +5:18 let _6: Droppy;                      // in scope 0 at $DIR/enum_cast.rs:+7:9: +7:10 </ins> scope 1 { debug x => _2;                   // in scope 1 at $DIR/enum_cast.rs:+2:13: +2:14 scope 2 {

Discussion:
noticed this 1.63→1.64 change in I tried this code: I expected to see this happen: because is non-, an error about moving out from behind a reference, like happened in 1.63 , this happened: it compiles fine in 1.64 in nightly is probably cased by Change enum-int casts to not go through MIR casts which is mentioned in It's unclear to me whether this is intentional under the banner of " behaviour", since there's no trait involved.
Prioritized as P-critical in meeting just now. This needs to be fixed by 1.65 at a minimum.
labels +T-compiler This needs work from T-compiler! :)
labels -I-lang-nominated Meeting consensus is that the current behavior is wrong and needs to be fixed.
Change:
# fn main() { unsafe { asm!("xor %eax, %eax" ::: "eax"); # } } <ins> # #[cfg(not(any(target_arch = "x86", target_arch = "x86_64")))] # fn main() {} </ins> ``` ## Operands

Discussion:
Triggers an LLVM assertion when targeting Android:
Something that works on any host (i.e. you needn’t compile libstd for android to repro):
As the error says, isn't a supported calling convention for the ARM target in LLVM. Not really much we can do from the rustc side unless we want to error early based on cc/target combinations. In any case, it should not crash.
I'm hitting this when I tried to run tests for 1.10.0 on arm64 (aarch64-unknown-linux-gnu). The build succeeds otherwise. I'm just adding and to for the time being.
Neither example crashes today. Closing, since I don't see any good opportunity for a test here (it'd have to be something like and that's probably not worth it). With (original example): Updated example:
Change:
#[allow(unused_extern_crates)] extern crate unwind; <ins> #[doc(masked)] #[allow(unused_extern_crates)] extern crate miniz_oxide; </ins> // During testing, this crate is not actually the "real" std library, but rather // it links to the real std library, which was compiled from this same source // code. So any lang items std defines are conditionally excluded (or else they

Discussion:
While looking at the standard library documentation of I found some trait implementations of documented there. These belong to the crate. I do not think this trait implementation belongs in the standard library documentation. See This is also present in the standard library documentation that installs locally. The Version string on is at the time of writing. I was told on the discord channel to tag in this issue.
They should definitely not be displayed.
After taking a look, I have to admit that I have no idea how to handle this... We could add on implementation I guess, but do we want this? Maybe you have an idea ?
This seems related to
Thanks for the link!
I think this is exactly what  is for, isn't it?
It is, but the crate might still want to show these impls though. EDIT: nevermind, you're absolutely right I confused it with ...
Change:
/// Checks whether the non-terminal may contain a single (non-keyword) identifier. fn may_be_ident(nt: &token::Nonterminal) -> bool { match *nt { <del> token::NtItem(_) | token::NtBlock(_) | token::NtVis(_) => false, </del> <ins> token::NtItem(_) | token::NtBlock(_) | token::NtVis(_) | token::NtLifetime(_) => false, </ins> _ => true, } }

Discussion:
https://crater- cc
Possibly accidentally injected by Would be good to find out why this is happening, so let's ping cleanup and see if we can bisect / shrink the problem down to something usable for finding a fix.
ping cleanup
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
Failed to confirm that is the cause: Seems like it regressed prior to
For code I used:
modify labels: -E-needs-bisection
Reduced example: () Errors:
Split the macro in two parts to make it easier to follow, and removed the special lifetime : () Error: I think we can now modify labels: -E-needs-mcve
I believe that the most probable culprit is , cc
is indeed the culprit, I can reproduce the bug on
This was . Assigning for now until we have a better understanding of what's going on.
Fixed in
Change:
<ins> // // popped up in in #94012, where an alternative desugaring was // causing unreachable code errors #![feature(let_else)] #![deny(unused_variables)] #![deny(unreachable_code)] fn let_else_diverge() -> bool { let Some(_) = Some("test") else { let x = 5; //~ ERROR unused variable: `x` return false; }; return true; } fn main() { let_else_diverge(); } </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: I expected to see this happen: A helpful error message pointing to the end of the block. Instead, this happened: An error message with a wrong span: <!-- 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. --: cc labels: +T-compiler +F-let-else +requires-nightly +A-diagnostics
Let's try that again... label +T-compiler +F-let-else +requires-nightly +A-diagnostics
FTR this is the error for the equivalent:
I wonder how is affecting this, as this seems to be a bug in the desugaring and that PR changes it. what is the error output with your PR applied? Does it fix the issue? If so, maybe adding a test to your PR would be helpful.
I meant caused by the desugaring, not in the desugaring.
It won't fix it. This needs a bit of work I think, to push the error further inside the if-let-else branch, so the span marked is the implicit return expression or lack thereof, which is (in the source code) further down in the block.
Hmm if you move the println into the , it gives a similar error to the one emitted by : gives
That's because you have only now reproduced the actual desugaring.
Change:
fn main() { let x = 4u32; let y : &Foo<u32> = &x; <del> let fl = unsafe { fool(y as *const Foo<u32>) }; assert_eq!(fl, (43+4)*(43+4)); </del> <ins> let fl = unsafe { round_trip_and_call(y as *const Foo<u32>) }; assert_eq!(fl, (43+4)); </ins> let s = FooS([0,1,2]); let u: &FooS<[u32]> = &s;

Discussion:
Much of the implementation work for rust-lang/rfcs has been done, but there remain some corner cases to fix: [ ] Casts between raw pointers to different traits are accepted but should not be (e.g. ) [ ] Double-check other cases, ensure adequate tests exist
triage: P-high -- I'm giving this high priority since accepting casts that we ought not to is a backwards compatibility risk, though it is mitigated by the fact that afaik the illegal casts yield an ICE (but I haven't done exhaustive testing)
The newly-illegal casts shouldn't be ICE-s (I mean, on nightly). Casts on stable are just randomly ICE-ey.