jiebi/CodeConvo huggingface dataset:
Change:
impl From<PathBuf> for FileName { fn from(p: PathBuf) -> Self { <del> assert!(!p.to_string_lossy().ends_with('>')); </del> FileName::Real(RealFileName::LocalPath(p)) } }

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. --Requirement: Create an empty file called '', i.e. using <!-- 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
Hmm, we should only disallow (since that's what we use for non-real "files") although I guess or even just might be a valid path itself? Internally we can tell apart between the two, I'm guessing this is to avoid tools seeing something with or in it and misinterpreting it as not a real file? But in that case we'd want a real error not an assert. cc
Marked as p-medium based on the discussion on the
PR with fix:
Change:
} let sp = ecx.with_def_site_ctxt(attr_sp); <del> let mut item = anno_item.expect_item(); </del> <ins> let (mut item, is_stmt) = match anno_item { Annotatable::Item(item) => (item, false), Annotatable::Stmt(stmt) if let ast::StmtKind::Item(_) = stmt.kind => if let ast::StmtKind::Item(i) = stmt.into_inner().kind { (i, true) } else { unreachable!() }, _ => { ecx.struct_span_err( anno_item.span(), "`#[test_case]` attribute is only allowed on items", ) .emit(); return vec![]; } }; </ins> item = item.map(|mut item| { let test_path_symbol = Symbol::intern(&item_path( // skip the name of the root module

Discussion:
This happens when a test function is declared inside another function, the one where the tests start running to be precise, using a custom testing framework in a nostd environment. link: at lines: 31 [function declared outside] , 40 [comment of function declared inside] I checked with the latest version of the nightly channel, and could not find any related issues <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Running on your current master branch () doesn't reproduce the issue for me, all tests pass.
That is because the section causing the issue is commented out, if you remove function27 (dont mind the name) from and replace the comment from the function init() in with function27, it should reproduce the issue (just checked again) ! I shouldve pushed and linked a version that reproduces the issue, my bad
I'm able to reproduce this with nightly <details<summary<stronglong file</strong</summary<p</p</details
Got it down to this: using (see ).
claim
Change:
<ins> // issue: rust-lang/rust#124022 struct Type<T>; //~^ ERROR type parameter `T` is never used fn main() { { impl<T> Type<T> { fn new() -> Type<T> { Type //~^ ERROR type annotations needed } } }; } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: node HirId(DefId(0:103 ~ a[6a73]::issue4298::::{impl}::deserialize::{impl}::visitmap).102) (expr ) cannot be placed in TypeckResults with hirowner DefId(0:116 ~ a[6a73]::issue4298::::{impl}::deserialize::{impl}::visitmap::{impl}::deserialize)', 'error: internal compiler error: node HirId(DefId(0:103 ~ a[6a73]::issue4298::::{impl}::deserialize::{impl}::visitmap).102) (expr ) cannot be placed in TypeckResults with hirowner DefId(0:116 ~ a[6a73]::issue4298::::{impl}::deserialize::{impl}::visitmap::{impl}::deserialize)' 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 [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
this really needs minimization -- there's a lot going on in that test that's probably hiding the underlying cause
hmm got is as far as
Minimized further:
Regression in nightly-2023-10-24 fetching (via remote github) commits from max(, 2023-10-21) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 14 commit[0] 2023-10-22: Auto merge of - weihanglo:update-cargo, r=weihanglo commit[1] 2023-10-22: Auto merge of - Kobzol:update-rustc-perf,

r=Mark-Simulacrum commit[2] 2023-10-23: Auto merge of - francorbacho:master, r=davidtwco commit[3] 2023-10-23: Auto merge of - calebcartwright:rustfmt-sync, r=calebcartwright commit[4] 2023-10-23: Auto merge of - ChrisDenton:empty, r=dtolnay commit[5] 2023-10-23: Auto merge of - matthiaskrgr:rollup-1tcxdgj, r=matthiaskrgr commit[6] 2023-10-23: Auto merge of - oli-obk:errorshenanigans, r=cjgillot commit[7] 2023-10-23: Auto merge of - oli-obk:evaluatedstaticinmetadata2, r=RalfJung commit[8] 2023-10-23: Auto merge of - oli-obk:smirrunmacro, r=spastorino commit[9] 2023-10-23: Auto merge of - matthiaskrgr:rollup-08kkjkz, r=matthiaskrgr commit[10] 2023-10-23: Auto merge of - cjgillot:jump-threading, r=pnkfelix commit[11] 2023-10-23: Auto merge of - bvanjoi:fix-, r=petrochenkov commit[12] 2023-10-23: Auto merge of - matthiaskrgr:rollup-96zuuom, r=matthiaskrgr commit[13] 2023-10-24: Auto merge of - cjgillot:split-move, r=petrochenkov ERROR: no CI builds available between and within last 167 days
I found it claim
Change:
<ins> // stderr-per-bitwidth use std::mem::{transmute, ManuallyDrop}; const S: &'static mut str = &mut " hello "; //~^ ERROR: mutable references are not allowed in the final value of constants //~| ERROR: mutation through a reference is not allowed in constants //~| ERROR: cannot borrow data in a `&` reference as mutable //~| ERROR: it is undefined behavior to use this value const fn trigger() -> [(); unsafe { let s = transmute::<(*const u8, usize), &ManuallyDrop<str>>((S.as_ptr(), 3)); 0 }] { [(); 0] } 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
A slightly more minimal example that does not use unsafe:
This bug was introduced in 1.46. Rustc 1.45.2 rightfully rejects the code, 37 - 1.44 ICEs with
Run cargo bisect on this: regression in Given that the panic is in , the likely culprit is PR because of the changes to
No longer ICEs since
Change:
base.position_independent_executables = true; base.has_elf_tls = false; base.requires_uwtable = true; <ins> base.crt_static_respected = false; </ins> base }

Discussion:
Reasons for: . According to , musl caused a program to run 9x slower. Musl is also known to be slower in certain configurations in C. This varies a lot with the use case and some might even see a performance increase with musl. docker containers using . It is possible to link glibc statically as demonstrated . From what I can tell, on the user facing side, this would be enable using as described in .
The reddit thread mentions libm. And another source of speedups might be the malloc implementation (glibc 2.26 introduced thread-local caches). One can already use custom global allocators, maybe it would make sense to link a custom libm too?
First blocker is the license. Glibc is licensed under LGPL, it has dynamic linking exception so one can freely link dynamically to it. Static linking doesn't fall under this exception. I'm not a lawyer but I think Rust would have to be licensed as (L)GPL to fit it. Another thing is glibc doesn't really support static linking, sure it works well for small software but bites you when you need more of it's features.
(Obviously not a lawyer but), I'm pretty sure that as long as the code it is linked against is (L)GPLed, it should work.
Also as long as the program it is linked against is licensed under a GPL compatible license, it is allowed. The MIT license, is compatible. All this information can be confirmed by looking at the above link. You can even link proprietary code against LGPL if you provide the object files.
because of we need special linking arguments because of the symbols. see also for and glibc uses for the nss modules.
The former should be doable. The latter is a tradeoff that people will need to understand if they statically link glibc, and it's something they already have to deal with if they use .
Implementation instructions: Add an entry for glibc-based targets you want to support to (Same as for musl, but -, because is undesirable ().) Perhaps libm or libpthread will need to be linked in the same way. Set to in target specifications for glibc-based targets you want to support (in ). Test that it actually works, this will require some building of libstd with cargo overridden libc dependency.

I'd be happy to submit the necessary changes, if you can outline what needs doing. () See the comment above.
Thanks!
I have this successfully working; just waiting on a release of the libc crate containing .
Change:
|        | |        help: provide a definition for the constant: `= <expr>;` <del> error: aborting due to 2 previous errors </del> <ins> error: missing type for `const` item --> $DIR/item-free-const-no-body-semantic-fail.rs:6:7 | LL | const B; |       ^ help: provide a type for the item: `B: <type>` error: aborting due to 3 previous errors </ins>

Discussion:
Reproducible with stable and nightly compilers. : : Maybe this is a duplicated of but I'm not sure as the example there is more complex. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.52.0. The error in 1.51.0 wasn't so great either though, but at least it didn't ICE:
Regression in nightly-2021-03-08 (too long ago to get build artifacts per commit). That's the commit range .... Possibly related to an interaction between (which seems to have landed in that commit range) and dtorck?
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Change:
// Equal types, all is good. return true; } <del> // Type-changing assignments can happen for (at least) two reasons: // - `&mut T` -> `&T` gets optimized from a reborrow to a mere assignment. // - Subtyping is used. While all normal lifetimes are erased, higher-ranked lifetime //   bounds are still around and can lead to type differences. // There is no good way to check the latter, so we compare layouts instead -- but only // for values with `Scalar`/`ScalarPair` abi. // FIXME: Do something more accurate, type-based. match &src.abi { Abi::Scalar(..) | Abi::ScalarPair(..) => src.layout == dest.layout, _ => false, </del> <ins> if src.layout != dest.layout { // Layout differs, definitely not equal. // We do this here because Miri would *do the wrong thing* if we allowed layout-changing // assignments. return false; </ins> } <ins> // Type-changing assignments can happen for (at least) two reasons: // 1. `&mut T` -> `&T` gets optimized from a reborrow to a mere assignment. // 2. Subtyping is used. While all normal lifetimes are erased, higher-ranked types //    with their late-bound lifetimes are still around and can lead to type differences. // Normalize both of them away. let normalize = |ty: Ty<'tcx>| { ty.fold_with(&mut BottomUpFolder { tcx, // Normalize all references to immutable. ty_op: |ty| match ty.kind { ty::Ref(_, pointee, _) => tcx.mk_imm_ref(tcx.lifetimes.re_erased, pointee), _ => ty, }, // We just erase all late-bound lifetimes, but this is not fully correct (FIXME): // lifetimes in invariant positions could matter (e.g. through associated types). // We rely on the fact that layout was confirmed to be equal above. lt_op: |_| tcx.lifetimes.re_erased, // Leave consts unchanged. ct_op: |ct| ct, }) }; normalize(src.ty) == normalize(dest.ty) </ins> } /// Use the already known layout if given (but sanity check in debug mode), /// or compute the layout. #[cfg_attr(not(debug_assertions), inline(always))] pub(super) fn from_known_layout<'tcx>( <ins> tcx: TyCtxt<'tcx>, </ins> known_layout: Option<TyAndLayout<'tcx>>, compute: impl FnOnce() -> InterpResult<'tcx, TyAndLayout<'tcx>>, ) -> InterpResult<'tcx, TyAndLayout<'tcx>> {

Discussion:
The following ICEs (example by shows This means that is wrong. It might be possible to also trigger this without nightly features through const_prop.
Baring a way to do the proper structural subtyping check, the only solution I see is to go back to comparing layouts in all cases (as a fallback after types mismatch) -- but does not like this, as far as I recall. Any other proposals?
Change:
// Make a symbolic link so we can use a consistent directory in the documentation. let build_triple = build.out.join(&build.build.triple); <ins> t!(fs::create_dir_all(&build_triple)); </ins> let host = build.out.join("host"); if let Err(e) = symlink_dir(&build.config, &build_triple, &host) { if e.kind() != ErrorKind::AlreadyExists {

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. --Building rust with the option fails with a symbolic link creation error. Reverting fixes the issue. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.67.1 Rust 1.68.0 <!-- Provide the version you are using that has the regression. --<!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +t-bootstrap Edit: how very convenient, wasn't even aware there was limitations on label, either way, does this issue occur with x86_64-windows-msvc.
Error: Label t-bootstrap can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I am one of the maintainers of the Rust build at The upgrade from 1.67.1 to 1.68.0 broke the aarch64 build (which uses the --enable-local-rust option). We can also reproduce it on other architectures and tool chains.
I ... don't see how this could be related to --enable-local-rust? we're not modifying anything in the stage 0 directory, only in the build directory. do you still see this issue if you remove that option?
oh I see, when that option is enabled doesn't download the toolchain and so there's no folder yet.

the correct fix is to add just after
Using --enable-local-rust will skip downloading and extracting the previous Rust version. The new code tries to create a symlink from to a directory that was supposedly extracted (but was not). There is the same issue with --local-rust-root btw.
claim
Change:
} impl Slice { <ins> #[inline] </ins> pub fn from_str(s: &str) -> &Slice { unsafe { mem::transmute(Wtf8::from_str(s)) } }

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:
= note: see issue #37854 <https://github.com/rust-lang/rust/issues/37854> for more information = help: add `#![feature(exclusive_range_pattern)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date <ins> = help: use an inclusive range pattern, like N..=M </ins> error[E0658]: exclusive range pattern syntax is experimental --> $DIR/range_pat_interactions1.rs:14:23

Discussion:
Came across this when a beginner was very confused about what was wrong with their ; the words "is experimental" and the link to the issue was not sufficient for their discovering what the problem/solution was. The suggested inclusive range pattern doesn't need to contain the actual matching value if producing it is hard or impossible, printing something like is still better than nothing. This issue may of course be ignored/closed if this nightly feature is just about ready to be stabilized or something. No response label +D-terse +C-enhancement +F-exclusiverangepattern <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> error: redundant explicit link target --> $DIR/issue-120444-1.rs:10:13 | LL | /// [`Vfs`][crate::Vfs] |      -----  ^^^^^^^^^^ explicit target is redundant |      | |      because label contains path that resolves to same destination | = note: when a link's destination is not specified, the label is used to resolve intra-doc links note: the lint level is defined here --> $DIR/issue-120444-1.rs:3:9 | LL | #![deny(rustdoc::redundant_explicit_links)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove explicit link target | LL | /// [`Vfs`] |     ~~~~~~~ error: aborting due to 1 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage
Change:
type Foo = extern "C" fn([u8]); //~^ ERROR `extern` fn uses type `[u8]`, which is not FFI-safe <ins> pub trait FooTrait { type FooType; } pub type Foo2<T> = extern "C" fn(Option<&<T as FooTrait>::FooType>); //~^ ERROR `extern` fn uses type `Option<&<T as FooTrait>::FooType>`, which is not FFI-safe </ins> pub struct FfiUnsafe; #[allow(improper_ctypes_definitions)]

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. -- at <details<summary<strongBacktrace</strong</summary<p</p</detailssearched nightlies: from nightly-2023-01-01 to nightly-2023-08-14 regressed nightly: nightly-2023-07-04 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
As referenced in the other issue this now also happens on stable since = 1.70. The culprint seems to be this type alias: Removing the reference in the Option works around this panic.
Here's a minimal example that reproduces the issue: Interestingly, this only happens while the function is extern "C".
WG-prioritization assigning priority (). cc: for the bisection pointing to label -I-prioritize +P-high
claim
The panic originates in the on this line: It happens because returns which it does because normalization of fails. The reason the normalization fails is because trait resolution fails for the projection due to not being sufficiently bound. If, for example, I change in 's example above to by adding a bound, the panic goes away as trait resolution succeeds now. Since the normalization failure can be legitimate as in this case, I feel this unwrap: should be removed to fix the issue. However, I'm not sure what the enclosing method should do upon receiving a from . I'd presume it should return . Please review and let me know if this analysis makes sense. cc:
Closely related PR: . It fixes an ICE due to similar causes but on a different line. In fact the very next line.
Yeah, I think making not and just bubble up the is the right behavior here.
Change:
} } <ins> /// Get the paths to all of the compiler's codegen backends. fn codegen_backends(&self, compiler: Compiler) -> impl Iterator<Item = PathBuf> { fs::read_dir(self.sysroot_codegen_backends(compiler)) .into_iter() .flatten() .filter_map(Result::ok) .map(|entry| entry.path()) } </ins> pub fn rustdoc(&self, host: Interned<String>) -> PathBuf { self.ensure(tool::Rustdoc { host }) }

Discussion:
At the very least, the tests don't appear to be re-checked. It's possible is also not rebuilt.