jiebi/CodeConvo huggingface dataset:
Change:
<!-- 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. --Compiling With nightly (2024-02-13) fails with nightly 2024-02-08 (with the stdsimd removal and stdarch addition) compiles fine Looks like the update to LLVM 18 could be the culprit <!-- 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. --: Here is the .ll file coming from the emit llvm ir (as recommended in another issue of the sort) changed extension so that github is not annoying about it (what a way to validate data blobs!) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Reduces to something like this:
Just wanted to take a moment and thank you warmly it's a pleasure to interact and work with you on those issues (even if it's only as a bug reporter ) Cheers
This fails: While this works: This also works: I think it's related to this change: It will automatically add only if generic target-cpu is used. I can't say that I understand the logic behind that change, but I guess this means we have to explicitly add in rustc when avx512 features are used.

Discussion:
("riscv32" | "riscv64", "fast-unaligned-access") if get_version().0 <= 17 => { LLVMFeature::new("unaligned-scalar-mem") } <ins> // For LLVM 18, enable the evex512 target feature if a avx512 target feature is enabled. ("x86", s) if get_version().0 >= 18 && s.starts_with("avx512") => { LLVMFeature::with_dependency(s, TargetFeatureFoldStrength::EnableOnly("evex512")) } </ins> (_, s) => LLVMFeature::new(s), } }

<ins> // build-pass // only-x86_64 // compile-flags: --crate-type=lib -C target-cpu=skylake #![feature(avx512_target_feature)] #![feature(stdarch_x86_avx512)] use std::arch::x86_64::*; #[target_feature(enable = "avx512f")] #[no_mangle] pub unsafe fn test(res: *mut f64, p: *const f64) { let arg = _mm512_load_pd(p); _mm512_store_pd(res, _mm512_fmaddsub_pd(arg, arg, arg)); } </ins>
Change:
<!-- 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. --This code compiles in debug mode, but fails in release mode (): On release mode, it errors with: I bisected it down to this patch causing the issue: 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<summaryBacktrace</summary<p</p</details
label +T-compiler +A-mir-opt +S-has-mcve -needs-triage
Shouldn't this be given a priority? label +P-critical cc cc
This fails to compile with either debug or release mode on stable. That means this isn't a regression, but rather an accidental stabilization. Probably still P-critical though
- good catch, I updated the example to use the dyn trait as suggested by the stable compiler, which passes both debug and release, but fails with nightly release.
This is not an accidental stabilization. This was stabilized in . This is a legitimate misoptimization.

Discussion:
let def_id = body.source.def_id(); debug!(?def_id); <ins> // Optimizing coroutines creates query cycles. if tcx.is_coroutine(def_id) { trace!("Skipped for coroutine {:?}", def_id); return; } </ins> let param_env = tcx.param_env_reveal_all_normalized(def_id); let map = Map::new(tcx, body, Some(MAX_PLACES)); let loop_headers = loop_headers(body);

<ins> // Regression test for #121094. // build-pass // compile-flags: -O --crate-type=lib // edition: 2021 use std::{future::Future, pin::Pin}; pub async fn foo(count: u32) { if count == 0 { return } else { let fut: Pin<Box<dyn Future<Output = ()>>> = Box::pin(foo(count - 1)); fut.await; } } </ins>
Change:
<!-- 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. --to on the usize return parameter link goes here: This happens with other parameters. . Nor is it broken on the portable simd docs. There are other things broken, such as slices on the SIMD page as well. It is also on other SIMD types' documentation pages. I don't know the exact pattern though. The link would be to this page: The link is to this page: Basically it seems to not be inserting the "std" directory in the link. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-docs +A-rustdoc-ui +T-rustdoc -needs-triage
claim
Regressed in one of these two commits: . Not sure which because the second one, which is the predecessor of the first one, doesn't build.
Ignore the above comment. It was a wrong bisection. The regression most likely occurred in PR . I say "most likely" because it was impossible to bisect around this part of the git log because builds kept failing with ICE's. Anyway, the cause of the bug is that in type alias docs links to primitives are being rendered relative to the target type not the alias. For example for the link is rendered as instead of because the target type is two levels deep from the root even though is just one level deep. This problem seems limited only type aliases. Internally this is how the rendering of the link works: generates the primitive path as just in the HTML fragment held in the JSONP format. in then prepends this string with the value of which seems to be relative to the target type (i.e. for our above example of ) The end result is that we get a link relative to the type not the alias.
The fix could either be in wherein we could compute the correct path to prepend depending on the path of the alias instead of just using . Or it could be in / methods whereby we could generate the path instead of for the primitive which will ensure that just prepending in front of it will work. What are your thoughts since you where the original author? This is the first time I've ventured into rustdoc so any pointers will be helpful.
I think the second option, generating the link as , is the better choice.

Discussion:
match m.primitive_locations.get(&prim) { Some(&def_id) if def_id.is_local() => { let len = cx.current.len(); <del> let len = if len == 0 { 0 } else { len - 1 }; </del> <ins> let path = if len == 0 { let cname_sym = ExternalCrate { crate_num: def_id.krate }.name(cx.tcx()); format!("{cname_sym}/") } else { "../".repeat(len - 1) }; </ins> write!( f, "<a class="primitive" href="{}primitive.{}.html{fragment}">", <del> "../".repeat(len), </del> <ins> path, </ins> prim.as_sym() )?; needs_termination = true;
Change:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' 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<!-- query stack: [hircrate] getting the crate HIR [hirattrs] getting HIR owner attributes in `` [entry_fn] looking up the entry function of a crate [analysis] running analysis passes on this crate --
cc
label +D-diagnostic-infra +S-has-mcve -needs-triage

Discussion:
) } ExprKind::Yield(opt_expr) => self.lower_expr_yield(e.span, opt_expr.as_deref()), <del> ExprKind::Err => hir::ExprKind::Err(self.dcx().has_errors().unwrap()), </del> <ins> ExprKind::Err => { hir::ExprKind::Err(self.dcx().span_delayed_bug(e.span, "lowered ExprKind::Err")) } </ins> ExprKind::Try(sub_expr) => self.lower_expr_try(e.span, sub_expr), ExprKind::Paren(_) | ExprKind::ForLoop { .. } => {

let body = &tcx.mir_const(def).borrow(); if body.return_ty().references_error() { <del> assert!(tcx.dcx().has_errors().is_some(), "mir_const_qualif: MIR had errors"); </del> <ins> // It's possible to reach here without an error being emitted (#121103). tcx.dcx().span_delayed_bug(body.span, "mir_const_qualif: MIR had errors"); </ins> return Default::default(); }

<ins> #![derive(Clone, Copy)] //~ ERROR `derive` attribute cannot be used at crate level use std::ptr::addr_of; const UNINHABITED_VARIANT: () = unsafe { let v = *addr_of!(data).cast(); //~ ERROR cannot determine resolution for the macro `addr_of` }; fn main() {} </ins>

<ins> error: `derive` attribute cannot be used at crate level --> $DIR/issue-121108.rs:1:1 | LL | #![derive(Clone, Copy)] | ^^^^^^^^^^^^^^^^^^^^^^^ LL | LL | use std::ptr::addr_of; |               ------- the inner attribute doesn't annotate this `use` import | help: perhaps you meant to use an outer attribute | LL - #![derive(Clone, Copy)] LL + #[derive(Clone, Copy)] | error: cannot determine resolution for the macro `addr_of` --> $DIR/issue-121108.rs:6:14 | LL |     let v = *addr_of!(data).cast(); |              ^^^^^^^ | = note: import resolution is stuck, try simplifying macro imports error: aborting due to 2 previous errors </ins>

<ins> fn main(_: <lib2::GenericType<42> as lib2::TypeFn>::Output) {} //~^ ERROR failed to resolve: use of undeclared crate or module `lib2` //~| ERROR failed to resolve: use of undeclared crate or module `lib2` </ins>

<ins> error[E0433]: failed to resolve: use of undeclared crate or module `lib2` --> $DIR/issue-121103.rs:1:38 | LL | fn main(_: <lib2::GenericType<42> as lib2::TypeFn>::Output) {} |                                      ^^^^ use of undeclared crate or module `lib2` error[E0433]: failed to resolve: use of undeclared crate or module `lib2` --> $DIR/issue-121103.rs:1:13 | LL | fn main(_: <lib2::GenericType<42> as lib2::TypeFn>::Output) {} |             ^^^^ use of undeclared crate or module `lib2` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0433`. </ins>
Change:
The compiler compiled with debug assertions has gotten really slow recently. For example, compiling the standard library takes way longer than it used to. This is bad, it makes it way harder to work on rustc.
This is probably because of the recent changes to . It contains a cfg(bootstrap) hack for that's not inlined. Additionally, it outlines the predicate, which is super slow as well. Fixing the former is easy, fixing the latter is harder and requires adding .
turns out this was caused by many different factors compounding in an unfortunate way :D oli's intrinsic changes outlining some important functions, and the unsafe preconditions being quite bad for runtime performance

Discussion:
/// assertions disabled. This intrinsic is primarily used by [`assert_unsafe_precondition`]. #[rustc_const_unstable(feature = "delayed_debug_assertions", issue = "none")] #[unstable(feature = "core_intrinsics", issue = "none")] <ins> #[inline(always)] </ins> #[cfg_attr(not(bootstrap), rustc_intrinsic)] pub(crate) const fn debug_assertions() -> bool { cfg!(debug_assertions)

macro_rules! assert_unsafe_precondition { ($message:expr, ($($name:ident:$ty:ty = $arg:expr),*$(,)?) => $e:expr $(,)?) => { { <del> #[inline(never)] </del> <ins> // When the standard library is compiled with debug assertions, we want the check to inline for better performance. // This is important when working on the compiler, which is compiled with debug assertions locally. // When not compiled with debug assertions (so the precompiled std) we outline the check to minimize the compile // time impact when debug assertions are disabled. // It is not clear whether that is the best solution, see #120848. #[cfg_attr(debug_assertions, inline(always))] #[cfg_attr(not(debug_assertions), inline(never))] </ins> #[rustc_nounwind] fn precondition_check($($name:$ty),*) { if !$e {
Change:
Some build environments (e.g. Chromium (), Bazel) may generate crate names based on names of build targets. While this results in globally-unique () crate names, it results in long and quite unwieldy crate names. Both Chromium and Blaze provide a macro to help working with such crate names: The macro usage above expands to something like: Unfortunately, it seems that some diagnostics keep referring to the long and unwieldy name. () see () globally-unique crate names = within a given build tree No response More detailed repro can be found below:
Is this something worth fixing? Is the original crate name worth preferring over the aliased name in some scenarios?
BTW: I also want to note/highlight that I am not able to repro the problem without using . For example (same files):
/cc

Discussion:
let mut path_segments = path_segments.clone(); path_segments.push(ast::PathSegment::from_ident(ident)); <ins> let alias_import = if let NameBindingKind::Import { import, .. } = name_binding.kind && let ImportKind::ExternCrate { source: Some(_), .. } = import.kind && import.parent_scope.expansion == parent_scope.expansion { true } else { false }; </ins> let is_extern_crate_that_also_appears_in_prelude = name_binding.is_extern_crate() && lookup_ident.span.at_least_rust_2018(); <del> if !is_extern_crate_that_also_appears_in_prelude { </del> <ins> if !is_extern_crate_that_also_appears_in_prelude || alias_import { </ins> // add the module to the lookup if seen_modules.insert(module.def_id()) { if via_import { &mut worklist_via_import } else { &mut worklist }

<ins> pub struct Foo<T>(pub core::ptr::NonNull<T>); </ins>

<ins> error[E0412]: cannot find type `Foo` in this scope --> $DIR/import-alias-issue-121168.rs:11:12 | LL |     let _: Foo<i32> = todo!(); |            ^^^ not found in this scope | help: consider importing this struct | LL + use nice_crate_name::Foo; | error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0412`. </ins>

<ins> error[E0412]: cannot find type `Foo` in this scope --> $DIR/import-alias-issue-121168.rs:11:12 | LL |     let _: Foo<i32> = todo!(); |            ^^^ not found in this scope | help: consider importing one of these items | LL + use crate::nice_crate_name::Foo; | LL + use import_alias_issue_121168_extern::Foo; | error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0412`. </ins>

<ins> //@ revisions: edition2015 edition2018 edition2021 //@ [edition2015] edition:2015 //@ [edition2018] edition:2018 //@ [edition2021] edition:2021 //@ compile-flags: --extern import_alias_issue_121168_extern //@ aux-build: import-alias-issue-121168-extern.rs extern crate import_alias_issue_121168_extern as nice_crate_name; fn use_foo_from_another_crate_without_importing_it_first() { let _: Foo<i32> = todo!(); //~ ERROR cannot find type `Foo` in this scope } fn main() {} </ins>
Change:
<!-- 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!

Discussion:
<del> use crate::spec::{base, CodeModel, Target, TargetOptions}; </del> <ins> use crate::spec::{base, Target, TargetOptions}; </ins> pub fn target() -> Target { Target {

data_layout: "e-m:e-p:64:64-i64:64-i128:128-n64-S128".into(), arch: "loongarch64".into(), options: TargetOptions { <del> code_model: Some(CodeModel::Medium), </del> cpu: "generic".into(), features: "+f,+d".into(), llvm_abiname: "lp64d".into(),

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() }, }
Change:
Importantly note that the closure passed to foo is ; does not ICE. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in ()

Discussion:
span: tcx.def_span(trait_item_id), }) } <del> } else if tcx.fn_trait_kind_from_def_id(trait_ref.def_id).is_some() { </del> <ins> } else if let Some(target_kind) = tcx.fn_trait_kind_from_def_id(trait_ref.def_id) { </ins> // FIXME: This doesn't check for malformed libcore that defines, e.g., // `trait Fn { fn call_once(&self) { .. } }`. This is mostly for extension // methods.

} match *rcvr_args.type_at(0).kind() { ty::Closure(closure_def_id, args) => { <del> let trait_closure_kind = tcx.fn_trait_kind_from_def_id(trait_id).unwrap(); Some(Instance::resolve_closure( tcx, closure_def_id, args, trait_closure_kind, )) </del> <ins> Some(Instance::resolve_closure(tcx, closure_def_id, args, target_kind)) </ins> } ty::FnDef(..) | ty::FnPtr(..) => Some(Instance { def: ty::InstanceDef::FnPtrShim(trait_item_id, rcvr_args.type_at(0)),

} } ty::Closure(closure_def_id, args) => { <del> let trait_closure_kind = tcx.fn_trait_kind_from_def_id(trait_id).unwrap(); Some(Instance::resolve_closure( tcx, closure_def_id, args, trait_closure_kind, )) </del> <ins> Some(Instance::resolve_closure(tcx, closure_def_id, args, target_kind)) </ins> } ty::FnDef(..) | ty::FnPtr(..) => Some(Instance { def: ty::InstanceDef::FnPtrShim(trait_item_id, rcvr_args.type_at(0)),

<ins> //@ edition: 2021 #![feature(async_closure, noop_waker)] use std::future::Future; use std::pin::pin; use std::task::*; pub fn block_on<T>(fut: impl Future<Output = T>) -> T { let mut fut = pin!(fut); // Poll loop, just to test the future... let ctx = &mut Context::from_waker(Waker::noop()); loop { match unsafe { fut.as_mut().poll(ctx) } { Poll::Pending => {} Poll::Ready(t) => break t, } } } </ins>

<ins> //@ aux-build:block-on.rs </ins> //@ edition: 2021 //@ build-pass #![feature(async_fn_traits)] <ins> extern crate block_on; </ins> use std::ops::AsyncFn; async fn foo() {}

} fn main() { <del> let fut = call_asyncly(|x| async move { x + 1 }); </del> <ins> block_on::block_on(async { call_asyncly(|x| async move { x + 1 }).await; }); </ins> }
Change:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'', 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'' File: --auto-reduced (treereduce-rust): original: Version information ` Command:
thanks for the stack trace for this class of ICEs, it's just the right thing that I need. Minimal:

Discussion:
use rustc_middle::ty::{self, GenericArgKind, Ty, TyCtxt, TypeVisitableExt}; use rustc_span::def_id::DefIdSet; use rustc_span::symbol::{kw, sym, Ident}; <del> use rustc_span::Symbol; </del> use rustc_span::{edit_distance, ExpnKind, FileName, MacroKind, Span}; <ins> use rustc_span::{Symbol, DUMMY_SP}; </ins> use rustc_trait_selection::infer::InferCtxtExt; use rustc_trait_selection::traits::error_reporting::on_unimplemented::OnUnimplementedNote; use rustc_trait_selection::traits::error_reporting::on_unimplemented::TypeErrCtxtExt as _;

.filter(|item| matches!(item.kind, ty::AssocKind::Fn) && !item.fn_has_self_parameter) .filter_map(|item| { // Only assoc fns that return `Self`, `Option<Self>` or `Result<Self, _>`. <del> let ret_ty = self.tcx.fn_sig(item.def_id).skip_binder().output(); </del> <ins> let ret_ty = self .tcx .fn_sig(item.def_id) .instantiate(self.tcx, self.fresh_args_for_item(DUMMY_SP, item.def_id)) .output(); </ins> let ret_ty = self.tcx.instantiate_bound_regions_with_erased(ret_ty); let ty::Adt(def, args) = ret_ty.kind() else { return None;

LL |     let ug = Graph::<i32, i32>::new_undirected(); |                                 ^^^^^^^^^^^^^^ function or associated item not found in `Graph<i32, i32>` | <ins> note: if you're trying to build a new `issue_30123_aux::Graph<i32, i32>`, consider using `issue_30123_aux::Graph::<N, E>::new` which returns `issue_30123_aux::Graph<_, _>` --> $DIR/auxiliary/issue-30123-aux.rs:14:5 | LL |     pub fn new() -> Self { |     ^^^^^^^^^^^^^^^^^^^^ </ins> = note: the function or associated item was found for - `issue_30123_aux::Graph<N, E, Undirected>`

<ins> fn hello<Q>() -> Vec<Q> { Vec::<Q>::mew() //~^ ERROR no function or associated item named `mew` found for struct `Vec<Q>` in the current scope } fn main() {} </ins>

<ins> error[E0599]: no function or associated item named `mew` found for struct `Vec<Q>` in the current scope --> $DIR/bad-builder.rs:2:15 | LL |     Vec::<Q>::mew() |               ^^^ |               | |               function or associated item not found in `Vec<Q>` |               help: there is an associated function with a similar name: `new` | note: if you're trying to build a new `Vec<Q>` consider using one of the following associated functions: Vec::<T>::new Vec::<T>::with_capacity Vec::<T>::from_raw_parts Vec::<T, A>::new_in and 2 others --> $SRC_DIR/alloc/src/vec/mod.rs:LL:COL error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0599`. </ins>