jiebi/CodeConvo huggingface dataset:
Change:
use crate::search_paths::PathKind; use crate::utils::NativeLibKind; <ins> use crate::Session; </ins> use rustc_ast as ast; use rustc_data_structures::sync::{self, MetadataRef}; use rustc_hir::def_id::{CrateNum, DefId, StableCrateId, LOCAL_CRATE};

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. --Assuming that you copied to . <!-- 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 reproduced this ICE locally. On my end I did it by copying the git checkout of into , because I wasn't able to figure out the right invocation to get it setup with files in (Oh, whoops, I think I was accidentally passing instead of . Of course that wasn't going to work.) well, not 100%, my query stack was a little different: but it seemed like a similar bug, nonetheless.
modify labels: +I-prioritize
Assigning as discussed as part of the and removing .
Now happens for when retrying the repro. (with replaced with as it was changed in rustc) <details<summarybacktrace</summary</detailsIt also gives an unstable fingerprint ICE for when compiling : <details<summarybacktrace</summary</details
The compilation now fails when accessing session in : It looks that decodes which in turn decodes which in turn requires access to a session, but by the time of call, the session in no longer threaded through. cc
I can confirm it works now. Pushed to re-enable incremental compilation for compiling the sysroot.
Change:
rustc_transmute::Reason::DstIsTooBig => { format!("The size of `{src}` is smaller than the size of `{dst}`") } <ins> rustc_transmute::Reason::SrcSizeOverflow => { format!( "values of the type `{src}` are too big for the current architecture" ) } rustc_transmute::Reason::DstSizeOverflow => { format!( "values of the type `{dst}` are too big for the current architecture" ) } </ins> rustc_transmute::Reason::DstHasStricterAlignment { src_min_align, dst_min_align,

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
Crashes since 1.65.0.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-81293.rs:6:13 | LL |     a = c + b * 5; |             ^^^^^ expected `usize`, found `u16` error[E0308]: mismatched types --> $DIR/issue-81293.rs:6:9 | LL |     a = c + b * 5; |         ^^^^^^^^^ expected `u16`, found `usize` error[E0277]: cannot add `u16` to `usize` --> $DIR/issue-81293.rs:6:11 | LL |     a = c + b * 5; |           ^ no implementation for `usize + u16` | = help: the trait `Add<u16>` is not implemented for `usize` error: aborting due to 3 previous errors Some errors have detailed explanations: E0277, E0308. For more information about an error, try `rustc --explain E0277`. </ins>

Discussion:
I try this code: () I expect to see this happen: No invalid suggestion for . Instead, I got this errors: label D-invalid-suggestion T-compiler
Change:
max_atomic_width: Some(64), relocation_model: RelocModel::Static, panic_strategy: PanicStrategy::Abort, <del> code_model: Some(CodeModel::Medium), </del> <ins> code_model: Some(CodeModel::Small), </ins> ..Default::default() }, }

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: outputs version info Instead, this happened: dead loop in entry function. <!-- 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. --:
label O-loongarch
That would be due to the LLVM 18 upgrade.
Yeah. It seems that the CI loongarch64-unknown-linux-gnu ld does not handle relocations correctly.
There is no version of crosstool-ng that supports , I'll revert the until the issue is resolved.
Oooops. Is this communicated with crosstool-ng maintainers?
But maybe crosstool-ng maintainers can't act as well due to the incompatibility between GCC 13.2 and Binutils 2.42 (loongson-community/discussions) :(. I'm not sure how to fix such an incompatibility...
Not yet. binutils 2.42 in progress:
is merged recently that bumped the LoongArch binutils to 2.42, so can we try again?
Yes, with merged, we can retry .
Today's nightly is built off of , which contains and does work: And the code model is indeed in use: So this issue is finally resolved. Thanks for everyone involved!
Change:
"{:?}", move_place.ty(self.body, self.infcx.tcx).ty, ); <del> let snippet = self.infcx.tcx.sess.source_map().span_to_snippet(span).unwrap(); let is_option = move_ty.starts_with("std::option::Option"); let is_result = move_ty.starts_with("std::result::Result"); if  is_option || is_result { err.span_suggestion( span, &format!("consider borrowing the `{}`'s content", if is_option { "Option" } else { "Result" }), format!("{}.as_ref()", snippet), Applicability::MaybeIncorrect, ); </del> <ins> if let Ok(snippet) = self.infcx.tcx.sess.source_map().span_to_snippet(span) { let is_option = move_ty.starts_with("std::option::Option"); let is_result = move_ty.starts_with("std::result::Result"); if is_option || is_result { err.span_suggestion( span, &format!("consider borrowing the `{}`'s content", if is_option { "Option" } else { "Result" }), format!("{}.as_ref()", snippet), Applicability::MaybeIncorrect, ); } </ins> } err }

Discussion:
When trying to compile the tests for my I get this error: <details<summary</summary</detailsMy understanding is that the compiler was trying to tell me about a borrow checker error; but I have no idea where to start minimizing this error(sorry).
I have managed to get it down to two files: It doesn't work with a in the , it has to be a different file. is then needed to trigger the ICE.
modify labels: I-ICE A-macros C-Bug T-compiler
cc
Seems to be related to 2018 edition? If I use the nightly-2018-10-01 and execute it doesn't ICE, but with it does ICE. well...
Most likely related to the fact that NLL is active in Rust 2018 then.
Bisecting: Somewhere in
Confirmed. gave me the ICE on 2015 as well (forgot that in the good ol' days nll was not a thing) Also confirmed, that edition 2015 does ICE with on and not on (like edition 2018 did above).
Also ICE with
Change:
// We probably need some winnowing logic similar to select here. <ins> // Drop duplicates. // // Note: `candidates.vec` seems to be on the critical path of the // compiler. Replacing it with an hash set was also tried, which would // render the following dedup unnecessary. It led to cleaner code but // prolonged compiling time of `librustc` from 5m30s to 6m in one test, or // ~9% performance lost. if candidates.vec.len() > 1 { let mut i = 0; while i < candidates.vec.len() { let has_dup = (0..i).any(|j| candidates.vec[i] == candidates.vec[j]); if has_dup { candidates.vec.swap_remove(i); } else { i += 1; } } } </ins> if candidates.ambiguous || candidates.vec.len() > 1 { return Err(ProjectionTyError::TooManyCandidates); }

Discussion:
That's a mouthful! To exemplify: This doesn't compile with , even though it does without it. Note that the only difference between the two configurations is that the function on is a free function instead of a default method. With , this fails with: Tested on
cc me
I've been running into very similar errors all day while updating my libs to the latest nightly. Here's an example of a method that works fine along with one that does not (simplest example I could come up with).
This example works now. I think this was a dup of
I just updated to master and I'm still running into the same error - perhaps my error is a separate issue?
Edwardw's PR does seem to fix my issue however, perhaps it addresses something extra?
The original issue is still present if the example on the first post is compiled with . I tested on , which contains Edit: just compiled . Still reproducible
Change:
desc { "whether the item should be made inlinable across crates" } separate_provide_extern } <del> query find_field((def_id, ident): (DefId, rustc_span::symbol::Ident)) -> Option<rustc_target::abi::FieldIdx> { desc { |tcx| "find the index of maybe nested field `{ident}` in `{}`", tcx.def_path_str(def_id) } } </del> } rustc_query_append! { define_callbacks! }

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'forcing query with already existing '', 'thread 'rustc' panicked at 'forcing query with already existing '' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [findfield] find the index of maybe nested field in [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to :thinking:
WG-prioritization assigning priority (). cc: + for label -I-prioritize +P-medium
I'm going to fix it in (still WIP), where the query will be removed.
Testing out on this issue:
I seems like does not have proper or impls, possibly due to the differing . Are you familiar with that part of spans?
Change:
let ty = OpportunisticRegionResolver::new(self).fold_ty(ty); // We do not expect existential variables in implied bounds. <del> // We may however encounter unconstrained lifetime variables in invalid // code. See #110161 for context. </del> <ins> // We may however encounter unconstrained lifetime variables // in very rare cases. // // See `ui/implied-bounds/implied-bounds-unconstrained-2.rs` for // an example. </ins> assert!(!ty.has_non_region_infer()); <del> if ty.has_infer() { self.tcx.sess.delay_span_bug( self.tcx.def_span(body_id), "skipped implied_outlives_bounds due to unconstrained lifetimes", ); return vec![]; } </del> let mut canonical_var_values = OriginalQueryValues::default(); let canonical_ty =

Discussion:
I tried this code: (minimized) I expected to see this happen: It should compile as it does on rust 1.69 and earlier (or at least not ICE). Instead, this happened: The program fails to compile with an ICE (see backtrace). <!-- 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 gluon issue that reported this (the error is coming from , a fork of ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
searched nightlies: from nightly-2023-01-01 to nightly-2023-06-19 regressed nightly: nightly-2023-03-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
probably or
has a try build and it does reproduce the issue.
The issue still persists on rust 1.72. I have tried to compile example that was provided by author of issue: <details<summaryError log</summary</detailsI have tried to fix compilation issue in gluon_salsa by explicitly specifying lifetimes, but I have ran into ICE.
<a href=""<img src="" /</aI enjoy using gluon and would really like for this to be solved to enable using it with the current compiler. Hopefully this helps
Change:
return place; } <del> let mut truncated_length = usize::MAX; </del> <ins> if place.base_ty.is_union() { place.projections.truncate(0); return place; } </ins> for (i, proj) in place.projections.iter().enumerate() { if proj.ty.is_unsafe_ptr() { <del> // Don't apply any projections on top of an unsafe ptr truncated_length = truncated_length.min(i + 1); </del> <ins> // Don't apply any projections on top of an unsafe ptr. place.projections.truncate(i + 1); </ins> break; } <ins> if proj.ty.is_union() { // Don't capture preicse fields of a union. place.projections.truncate(i + 1); break; } } place } /// Truncate projections so that following rules are obeyed by the captured `place`: /// - No Index projections are captured, since arrays are captured completely. /// - No unsafe block is required to capture `place` /// Truncate projections so that following rules are obeyed by the captured `place`: fn restrict_capture_precision<'tcx>(mut place: Place<'tcx>) -> Place<'tcx> { place = restrict_precision_for_unsafe(place); if place.projections.is_empty() { // Nothing to do here return place; } for (i, proj) in place.projections.iter().enumerate() { </ins> match proj.kind { ProjectionKind::Index => { // Arrays are completely captured, so we drop Index projections <del> truncated_length = truncated_length.min(i); </del> <ins> place.projections.truncate(i); </ins> break; } ProjectionKind::Deref => {}

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: no error Instead, this happened: rustc 1.55.0-nightly 2018 edition rustc 1.55.0-nightly 2021 edition <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Change:
<ins> error: unexpected token: `stringify!(b)` --> $DIR/key-value-expansion-on-mac.rs:12:17 | LL | #[rustc_dummy = stringify!(b)] |                 ^^^^^^^^^^^^^ 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. --Found an ICE with when trying to use it in the standard library (). cc . <!-- 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 hit an additional ICE by using an unknown attribute instead of a valid one: <details<summary<strongBacktrace</strong</summary<p</p</detailsI don't really think it's useful for this issue though, since it's a delayed error.
Fixed in
Change:
} impl<'a, Ty> TyAndLayout<'a, Ty> { <ins> /// Returns `true` if this is an aggregate type (including a ScalarPair!) </ins> fn is_aggregate(&self) -> bool { match self.abi { Abi::Uninhabited | Abi::Scalar(_) | Abi::Vector { .. } => false,

Discussion:
Crate bytecount compilation fails with latest nightly on NanoPC-T6 (RK3588 ARM / aarch64). It worked yesterday. I tried this code: Updating index Adding bytecount v0.6.7 to dependencies. Features: generic-simd htmlreport packedsimd runtime-dispatch-simd Updating index Compiling bytecount v0.6.7 Intrinsic has incorrect return type! ptr in function ZN4core9corearch10armshared4neon9generated11vld1qu8x417hd6e0965b4ff7ff22E LLVM ERROR: Broken function found, compilation aborted! error: could not compile (lib) Compiling bytecount v0.6.7 Compiling bytecounttest v0.1.0 (/home/pi/bytecounttest) Finished dev [unoptimized + debuginfo] target(s) in 0.90s Linux NanoPC-T6 5.10.160 SMP Thu Jul 20 15:53:55 CST 2023 aarch64 aarch64 aarch64 GNU/Linux PRETTYNAME="Ubuntu 22.04.3 LTS" NAME="Ubuntu" VERSIONID="22.04" VERSION="22.04.3 LTS (Jammy Jellyfish)" VERSIONCODENAME=jammy ID=ubuntu IDLIKE=debian HOMEURL="" SUPPORTURL="" BUGREPORTURL="" PRIVACYPOLICYURL="" UBUNTUCODENAME=jammy I expected to see this happen: Finished dev [unoptimized + debuginfo] target(s) in 1.32s Instead, this happened: LLVM ERROR: Broken function found, compilation aborted!
searched nightlies: from nightly-2023-11-19 to nightly-2023-11-20 regressed nightly: nightly-2023-11-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </detailslooks like something in that PR changed ABI behavior and now LLVM and rustc disagree. Don't know who's wrong.
Hm, I don't know how that "unadjusted" ABI stuff works...
should fix this. I am not sure how to add a test.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
<ins> // Copyright 2018 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. #![crate_type = "rlib"] #![feature(linkage)] pub fn foo<T>() -> *const() { extern { #[linkage = "extern_weak"] static FOO: *const(); } unsafe { FOO } } </ins>

Discussion:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by
Change:
} if let Some(ref suffix) = builder.config.llvm_version_suffix { <del> cfg.define("LLVM_VERSION_SUFFIX", suffix); </del> <ins> // Allow version-suffix="" to not define a version suffix at all. if !suffix.is_empty() { cfg.define("LLVM_VERSION_SUFFIX", suffix); } } else { let mut default_suffix = format!( "-rust-{}-{}", channel::CFG_RELEASE_NUM, builder.config.channel, ); let llvm_info = if self.emscripten { &builder.emscripten_llvm_info } else { &builder.in_tree_llvm_info }; if let Some(sha) = llvm_info.sha_short() { default_suffix.push_str("-"); default_suffix.push_str(sha); } cfg.define("LLVM_VERSION_SUFFIX", default_suffix); </ins> } if let Some(ref linker) = builder.config.llvm_use_linker {

Discussion:
Which means that programs that run from a build script, or from cargo in some other way, fail. Steps to Reproduce: a clang binary pointing to clang-8 installed and in your path. install nightly clone && cd $ test Actual results: /usr/bin/clang: relocation error: symbol ZTIN4llvm14FoldingSetBaseE version LLVM8 not defined in file libLLVM-8.so with link time reference Expected results: not so This only happens if ran from cargo, if I run the test executable manually then stuff works, so I suspect this is some LDLIBRARYPATH mungling that cargo or rustup do under the hood. This is technically a regression from , same problem does not exist with rust stable / beta and clang 7. There's a slight chance that there's an issue on how clang-8 is built in Fedora, so I also filed , but I think it's unexpected that clang when called from cargo / build scripts uses rust's , and probably should be avoided. cc
Is invoked from a build script? It is possible that cargo neglects removing the unnecessary or similar environment variables before invoking the script in question. EDIT: oh you wrote that in the report already. I remember there being an issue like this in cargo repo from a long long time ago, but cannot find it now.
cc
See also . We should probably set a custom suffix per . Maybe even include the Rust version to help avoid bootstrap issues like what commit saw. (cc
Yep, I think a suffix of rust version (or maybe LLVM submodule commit?) would be good. I think we'd appreciate a PR for something like that; I would expect it to be a matter of making the version suffix default be or something along those lines.
Sure, that sounds good, I can give that a shot.
I sent with a change that I hope will address this, but see there why I cannot confirm it will :)
triage: P-high, assigning to
Change:
<ins> // aux-build:issue-76736-1.rs // aux-build:issue-76736-2.rs #![crate_name = "foo"] #![feature(rustc_private)] extern crate issue_76736_1; extern crate issue_76736_2; // @has foo/struct.Foo.html // @has - '//*[@class="impl"]//h3[@class="code-header"]' 'MaybeResult' pub struct Foo; // @has foo/struct.Bar.html // @has - '//*[@class="impl"]//h3[@class="code-header"]' 'MaybeResult' pub use issue_76736_2::Bar; </ins>

Discussion:
This is a regression from stable to beta, although this issue will be P-low. The problem is ignored documenting unstable traits for non-local types, fixes some regressions caused by it but the regression in nightly-rustc / compiler docs still opens. For example: Compare and . The doc in 1.46.0 has impl, while on nightly it doesn't have. A way to fix this issue is ignoring this check when the compiling-crates are being passed flag or the crate/module has feature: : Version 1.48.0-nightly ( 2020-09-14)
Hey! I would like to check this out if that is okay
Is this actually a regression?
Dropping regression label. nightly-rustc docs are, well, not really important on non-nightly channels, as they cannot be used by normal consumers.
if you're still interested in working on this we'd love to have the help! If you have trouble, feel free to ask for help in or :)
Thanks! Yes, I am still interested, I have been busy that past few weeks. I will give it a shot this weekend and will reach out if I can't figure it out!
Since zulip is lag in my region at night, I post a respond here. You could use to check for flag passed during compilation.
I think I'll hop onto this if that's OK. I've always wanted to contribute :)
Go for it!
It doesn't seem to be fixed by I'll check the cause