jiebi/CodeConvo huggingface dataset:
Change:
<ins> include ../../run-make-fulldeps/tools.mk # FIXME https://github.com/rust-lang/rust/issues/78911 # ignore-32bit wrong/no cross compiler and sometimes we pass wrong gcc args (-m64) # Regression test for issue #83112 # The generated test harness code contains spans with a dummy location, # but a non-dummy SyntaxContext. Previously, the incremental cache was encoding # these spans as a full span (with a source file index), instead of skipping # the encoding of the location information. If the file gest moved, the hash # of the span will be unchanged (since it has a dummy location), so the incr # cache would end up try to load a non-existent file using the previously # enccoded source file id. SRC=$(TMPDIR)/src INCR=$(TMPDIR)/incr all: mkdir $(SRC) mkdir $(SRC)/mydir mkdir $(INCR) cp main.rs $(SRC)/main.rs $(RUSTC) --test -C incremental=$(INCR) $(SRC)/main.rs mv $(SRC)/main.rs $(SRC)/mydir/main.rs $(RUSTC) --test -C incremental=$(INCR) $(SRC)/mydir/main.rs </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. --The code is my entire project, unfortunately. The ICE appears to be related to incremental compilation, so I'm not sure how to minimise it. (There was a large section here which is irrelevant now I have "steps to reproduce" and a repro on current nightly.) <!-- 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
modify labels +A-incr-comp +E-needs-mcve
Neither nor commit exists when I clone that repository.
Err, sorry. Not sure what happened there. Maybe I deleted the remote branch by mistake somehow. I have the commit locally so I have pushed it again. In case of other confusion I also retried my "steps to repro" and it still goes wrong as I described. Also I noticed that the commitids there have a spurious "ESC" at the end (!), the result of a git+less misbehaviour. I have deleted those from the summary above.
This will be fixed by
Change:
// The number of expressions and patterns visited in the current body expr_and_pat_count: usize, <ins> // When this is `true`, we record the `Scopes` we encounter // when processing a Yield expression. This allows us to fix // up their indices. pessimistic_yield: bool, // Stores scopes when pessimistic_yield is true. fixup_scopes: Vec<Scope>, </ins> // Generated scope tree: scope_tree: ScopeTree,

Discussion:
The code below causes an internal compiler error. I've provided some more details as comments. rustc 1.37.0-nightly ( 2019-05-31) binary: rustc commit-hash: commit-date: 2019-05-31 host: x86_64-unknown-linux-gnu release: 1.37.0-nightly LLVM version: 8.0 Backtrace:
Does this issue still occur? I couldn't reproduce it from given code on playground.
I just checked with nightly 2019-06-03, and it's still there. It requires the line to occur.
minimized:
Marking as blocking -- not entirely clear how general this is but it looks like something people might run across fairly easily.
cc -- maybe you have some idea what the problem is here?
My guess is that implicitly borrows during the type checking phase, so we don't record as being part of the generator.
This seems to be related to the field calculated . When , a computed count of gets compared against a exprcount of , resulting in being set to . However,I'm seeing this line earlier in the logs: which has a count of , as expected. This would seem to suggest that the count is somehow getting overwritten later on.
On further inspection, the count doesn't appear to be getting overwritten. and are both computing it in the same way, but it seems inconsistent with the MIR that ultimately gets generated. I think that due to the way the HIR post-order traversal works, the overall assignment expression is computed to be 'after' the inner , which is interpreted to mean that it isn't live over the yield point. However, consider the MIR for a similar function: The relevant MIR is; Here, the mutable borrow adjustment occurs before the body of the block. When the block includes a , the is clearly live across the yield point.
Change:
[[package]] name = "backtrace" <del> version = "0.3.50" </del> <ins> version = "0.3.52" </ins> dependencies = [ "addr2line", "cfg-if",

Discussion:
~ OK on 1.46: | fails on 1.47: In all cases, we are using gdb 9.2 and LLVM 10. The tests themselves haven't changed since ~1.38, so it must be an actual behavioural change in rustc. <details<summaryui/backtrace-</summary~ </details<details</summary~ </details<details<summaryui/std-</summary~ </details
could this be related to ?
Seems likely! If this is happening on big-endian platforms then there's likely an issue with endianness in (most likely) . It could also be in itself or , but it seems most likely to be in the integration in the crate itself.
Related:
Assigning and removing as in the prioritization working group.
I'll try to run gimli etc things on a sparc, but no promises of success.
I have an s390x machine at hand, so I tried a few things. Plain passes for , , and , but fails two tests: There are also warnings about FFI safety, but I don't know if they're relevant.
It may be easier to reproduce on a mac:
Mac may have a very different issue, since it's apparently a big-endian thing here. (Plus I don't have a mac at all. :wink: )
Well, this will do it: I think this should this be , unless there's support for backtracing other processes.
Side note: does this need to be updated?
Change:
) { debug!("report_region_errors(): {} errors to start", errors.len()); <del> if will_later_be_reported_by_nll && self.tcx.use_mir_borrowck() { </del> <ins> if will_later_be_reported_by_nll && // FIXME: `use_mir_borrowck` seems wrong here... self.tcx.use_mir_borrowck() && // ... this is a band-aid; may be better to explicitly // match on every borrowck_mode variant to guide decision // here. !self.tcx.migrate_borrowck() { </ins> // With `#![feature(nll)]`, we want to present a nice user // experience, so don't even mention the errors from the // AST checker.

Discussion:
D'oh: while investigating , I found a case where we are downgrading the NLL errors to warnings (due to the migration mode in ), but AST-borrowck issues an error for the test! (This may explain , at least in part...) Namely, . Here is the test: Here is the AST-borrowck output (a hard error): And here is the NLL output (another hard error): But here is the output from : ui/borrowck/issue- is one particular instance of this, but now that I've found one, I'm certain there are more. This is pretty bad. Very high priority to fix.
This code looks suspicious:
Ha I should have just left this to to fix, since we seem to have independently identified the culprit.
I think I've already assigned myself to enough issues.
Change:
<ins> // check-pass // edition:2018 #[allow(unused)] async fn foo<'a>() { let _data = &mut [0u8; { 1 + 4 }]; bar().await } async fn bar() {} 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
further minimized: Looks like the generator code incorrectly handles somewhere :thinking:
PR is up. I noticed that an old stable rustc doesn't ICE, so marking as such and nominating the PR for beta backport.
Change:
<ins> // compile-flags: -O // min-llvm-version: 11.0 #![crate_type = "lib"] #[repr(C)] pub enum E { A, } // CHECK-LABEL: @index #[no_mangle] pub fn index(x: &[u32; 3], ind: E) -> u32{ // CHECK-NOT: panic_bounds_check x[ind as usize] } </ins>

Discussion:
I tried this code: I expected to see this happen: no bounds check Instead, this happened (with ) However adding more variants to the enum makes the bound check go away: generates: Here's a godbolt link to play around further: The MIR of the two cases is identical, but the llvm IR in ZST case is lacking , which I assume (heh!) leads to the bounds check being preserved. (However i don't actually understand LLVM, I'm just reading the diff...) rustc 1.50.0 This sounds very closely related to , but I'm not actually sure if it is. Please reroute as appropriate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Removing any attributes from the enum also leads to the optimization occurring as expected ().
We don't emit the enum range assumption if the range only contains one element:
claim
Change:
// Otherwise, check if 2 links are same, if so, skip the resolve process. // // Notice that this algorithm is passive, might possibly miss actual redudant cases. <del> let explicit_link = &explicit_link.to_string(); </del> <ins> let explicit_link = explicit_link.to_string(); </ins> let display_text = ori_link.display_text.as_ref().unwrap(); <del> let display_len = display_text.len(); let explicit_len = explicit_link.len(); if display_len == explicit_len { </del> <ins> if display_text.len() == explicit_link.len() { </ins> // Whether they are same or not, skip the resolve process. return; } <del> if (explicit_len >= display_len && &explicit_link[(explicit_len - display_len)..] == display_text) || (display_len >= explicit_len && &display_text[(display_len - explicit_len)..] == explicit_link) </del> <ins> if explicit_link.ends_with(&display_text[..]) || display_text.ends_with(&explicit_link[..]) </ins> { self.resolve_with_disambiguator_cached( display_res_info,

Discussion:
Reduced from the source code of : <!-- 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</detailsWould have been introduced by since that PR the lint.. cc label -T-compiler +T-rustdoc
Change:
// // `[[fn#'b -> impl_trait#'b], [fn#'b -> impl_sized#'b]]` // <del> // for the opaque type generated on `impl Sized + 'b`, We want the result to be: // impl_sized#'b, so iterating forward is the wrong thing to do. for map in self.generics_def_id_map.iter().rev() { if let Some(r) = map.get(&local_def_id) { debug!("def_id_remapper: remapping from `{local_def_id:?}` to `{r:?}`"); local_def_id = *r; } else { debug!("def_id_remapper: no remapping for `{local_def_id:?}` found in map"); } } local_def_id </del> <ins> // for the opaque type generated on `impl Sized + 'b`, we want the result to be: impl_sized#'b. // So, if we were trying to find first from the start (outermost) would give the wrong result, impl_trait#'b. self.generics_def_id_map .iter() .rev() .find_map(|map| map.get(&local_def_id).map(|local_def_id| *local_def_id)) .unwrap_or(local_def_id) </ins> } /// Freshen the `LoweringContext` and ready it to lower a nested item.

Discussion:
This is an attempt to reproduce a minimal example of a regression problem (backwards compatibility not assured) from a closed-source company codebase. I tried this code: - I expected to see the code building (This code is old and was building for years on rust 1.54, and builds on rust 1.63. the code works as intended in the proprietary codebase) Instead, this happened: It most recently worked on: 1.63 (from my repo, commit : ) It does not work anymore on version 1.64: (from my repo, commit : ) Including the backtrace by setting does not change anything to the error message. I do not know why this problem occured though. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
searched nightlies: from nightly-2022-08-01 to nightly-2022-10-01 regressed nightly: nightly-2022-08-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsOut of the rollup, this was probably caused by ?
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Reopening to track backports.
can this be closed? was backported to stable, right? cc (unsure who to ping)
I have no involvement with this whatsoever.^^ is usually doing backports.
was beta backported to 1.65, which is now released. We won't be having a 1.64.1 release. So this should be considered "fixed", since it is resolved on the current stable release of Rust.
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(const_fn)] enum Cake { BlackForest, Marmor, } use Cake::*; const BOO: (Cake, Cake) = (Marmor, BlackForest); //~^ ERROR: constant evaluation error: non-constant path in constant expression [E0471] const FOO: Cake = BOO.1; const fn foo() -> Cake { Marmor //~ ERROR: constant evaluation error: non-constant path in constant expression [E0471] //~^ ERROR: non-constant path in constant expression } const WORKS: Cake = Marmor; const GOO: Cake = foo(); fn main() { match BlackForest { FOO => println!("hi"), //~ NOTE: in pattern here GOO => println!("meh"), //~ NOTE: in pattern here WORKS => println!("möp"), _ => println!("bye"), } } </ins>

Discussion:
at the current version of error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'internal error: entered unreachable code', playpen: application terminated with error code 101
The reason this is happening is because the code thinks is an enum variant or a tuple struct. The code around this is somewhat redundant and would probably better be solved by making enum variants const evaluable and adding a function that translates s to

This code wrongly states "expected constant integer for repeat count, but non-constant path in constant expression" This one works
accidentally fixed in
Change:
<ins> //@ revisions: current next //@[next] compile-flags: -Znext-solver //@ ignore-compare-mode-next-solver (explicit revisions) // Tests that projection doesn't explode if we accidentally // put an associated type on an auto trait. auto trait Trait { //~^ ERROR auto traits are experimental and possibly buggy type Output; //~^ ERROR auto traits cannot have associated items } fn main() { let _: <() as Trait>::Output = (); //~^ ERROR mismatched types } </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<strongICE location label +A-auto-traits +F-unboxed_closures
Minimized: <details<summaryError output</summary</details label -F-unboxedclosures +F-autotraits
Regression in nightly-2023-06-18 (...)
probably just another duplicate of

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unexpected builtin trait with associated type: <u16 as Z<'b, u16', 'error: internal compiler error: unexpected builtin trait with associated type: <u16 as Z<'b, u16' File: --auto-reduced (treereduce-rust): original: Version 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
Regression in nightly-2023-06-18 Regression in / ping
The depth of the stack at the ICE depends on the recursion limit. Add and it still ICEs, but with only 8 repeated stack portions.
Simplified to use only locally defined traits, not use a lifetime parameter, and hit fewer errors: Oddly enough, this variant hits the same ICE but without such a deep stack.
You can replace the bound with a lifetime bound to reproduce too, such as .
Change:
// an eval_always node, let's try to mark it green recursively. if !dep_dep_node.kind.is_eval_always() { debug!( <del> "try_mark_previous_green({:?}) --- state of dependency {:?}  </del> <ins> "try_mark_previous_green({:?}) --- state of dependency {:?} ({})  </ins> is unknown, trying to mark it green", <del> dep_node, dep_dep_node </del> <ins> dep_node, dep_dep_node, dep_dep_node.hash, </ins> ); let node_index = self.try_mark_previous_green(

Discussion:
This seems to be an incremental error‽ We need an external crate for this to work. Haven't managed it to work in an internal mod only :/ Also this only happens with . Haven't managed to get it running with sadly extern crate (let's call it f) code Then just remove and add afterwards again (or the other way round, it doesn't matter). This script does it for you: <!-- 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<pand with RUST_BACKTRACE=full the LLVMing assert vanishes </p</details
searched nightlies: from nightly-2020-12-08 to nightly-2020-12-10 regressed nightly: nightly-2020-12-10 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: </detailscc
Assigning as discussed as part of the and removing .
I've fixed the issue locally, and I'm working on a PR.
Opened
Change:
// The drop function takes `*mut T` where `T` is the type being dropped, so get that. let args = fn_sig.inputs(); if args.len() != 1 { <del> throw_ub!(InvalidDropFn(fn_sig)); </del> <ins> throw_ub!(InvalidVtableDropFn(fn_sig)); </ins> } <del> let ty = args[0].builtin_deref(true).ok_or_else(|| err_ub!(InvalidDropFn(fn_sig)))?.ty; </del> <ins> let ty = args[0].builtin_deref(true).ok_or_else(|| err_ub!(InvalidVtableDropFn(fn_sig)))?.ty; </ins> Ok((drop_instance, ty)) }

Discussion:
The following code ICEs: To fix this, this code here needs to properly catch the "invalid size/align" error and turn it into a validation failure: But for this we first need to make these errors catchable by introducing separate variants into this enum: You can use the existing variant as a model; it does the same job for invalid drop function pointers in the vtable. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'll take care of this claim
Change:
use crate::ty::subst::{GenericArg, GenericArgKind, SubstsRef}; use crate::ty::{self, Ty, TyCtxt, TypeFoldable}; use crate::ty::error::{ExpectedFound, TypeError}; <del> use crate::mir::interpret::{ConstValue, Scalar}; </del> <ins> use crate::mir::interpret::{ConstValue, get_slice_bytes, Scalar}; </ins> use std::rc::Rc; use std::iter; use rustc_target::spec::abi;

Discussion:
Results in cc
modify labels: I-ICE C-Bug T-compiler A-const-generics
I'm looking into this currently.
Partially as a note to myself and partially as an update to anyone interested The root cause of this bug seems to be the fact that we currently don't explicitly handle slice const values in , and therefore we always say they cannot match. This error eventually bubbles up to to produce all three errors.
Change:
<ins> // Regression test for https://github.com/rust-lang/rust/issues/129205 fn x<T: Copy>() { T::try_from(); //~ ERROR E0599 } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }', 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }' 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: [typeof] computing type of [typeck] type-checking --
mvce:
:thinking: cc
I'm gonna assume that it is this line that needs additional logic:
Change:
<del> //@ compile-flags: -O // This regress since Rust version 1.72. //@ min-llvm-version: 18.1.4 #![crate_type = "lib"] use std::convert::TryInto; const N: usize = 24; // CHECK-LABEL: @example // CHECK-NOT: unwrap_failed #[no_mangle] pub fn example(a: Vec<u8>) -> u8 { if a.len() != 32 { return 0; } let a: [u8; 32] = a.try_into().unwrap(); a[15] + a[N] } </del>

Discussion:
On this test failed, then passed, then failed. That PR modified rustccodegenllvm, so maybe it's a problem with the PR, but... On the test failed as well. And LLVM update should have no impact on the llvm-19 job, so this is an unrelated failure. <details</detailsTest:
Also failed in and
We should remove this test and reopen the issue, especially if it's true that nobody understands why the codegen improved:
"Nobody understands" as in "nobody bothered to run a bisect". This test has been consistently passing with our own LLVM 19 builds, so it's pretty weird that it fails with Ubuntu's.
is it possible that a commit was merged in the past... uhh... 5 months that fixed a behavior that affects this? I think that Ubuntu's LLVM 19 may actually be a snapshot from April.
That would certainly be bad -- where did you find that it is from April? It looks like Ubuntu 24.10 has the final release since yesterday: I can't find a history on their website though. Possibly just regenerating the docker image will fix this issue.
The log from has: So the docker image should currently have rc4, which is close to what our fork currently uses.
ah, I misunderstood something, then. I was looking at their "llvm-toolchain-snapshot" and trying to figure out its relationships to their other llvm repos and which branch would be in use: and I was having trouble finding the version string in the log, too. it seems it isn't always printed?
I've tried running this test in a loop in the x86_64-gnu-llvm-19 docker container and it never failed :( So no idea what's going on here.
Yes, I tried similar antics right before I put up the PR to remove it. I actually probably would have left it if I could have reproduced a failure, because then I'd have any hope of it actually being solved by anything except magic.