jiebi/CodeConvo huggingface dataset:
Change:
cfg.build(); <del> t!(fs::write(&done_stamp, &rebuild_trigger_contents)); </del> <ins> if let Some(llvm_commit) = llvm_commit { t!(fs::write(&done_stamp, &llvm_commit)); } </ins> build_llvm_config }

Discussion:
fortunately: cc
Some potentially useful extra info:
backtrace from running under in details block: <details</details
hmm for some reason this system is using a with ; i wonder if that is relevant... but that should only affect the bootstrap behavior, not the number of codegen-units used in the final build, right? I guess I should double-check this against a nightly that I download via , just to be sure...
yeah okay this doesn't occur on a nightly I downloaded via , ... grr...
And unfortunately the debug does not replicate after I do a rebuild of LLVM with in the ... (I'll have to see if the problem was actually due to some other sort of staleness of my LLVM object files...?)
can't replicate anymore. :( I have a sneaking suspicion that this might be due to my build of LLVM being stale in some way? not sure. I sort of wish I had taken a snapshot of my directory structure at the time before I cleaned it as part of trying to test out alternate configurations...
Fwiw I have the same issue locally
It is LLVM, I had these failures (all segfaults, i.e. "signal 11"): And they were fixed by (LLVM rebuilt a few of its files). We should keep track of the fact that we don't detect LLVM needing a rebuild correctly. IMO should contain the git hash of the submodule. The rebuild is really fast, especially after small deltas, and it's better than weird crashes.
Same issue here, with two separate rustc checkouts. Currently rebuilding LLVM to see if that helps. (Deleting that file triggered a complete rebuild.)
Confirmed that rebuilding LLVM fixes the problem.

I've spent the past few hours looking through documentation for how to build rustc with a patched LLVM without success. Currently, the best I'm at is: And then build with: But even that doesn't rebuild anything unless I . Which completely loses incremental compilation results. Is there any way to make this development workflow better? Rebuilding from scratch at every change is… painful.
You need to modify to rebuild LLVM. (tagging this issue as a documentation problem.)
Thanks! Leaving open for the documentation problem :)

I Changed the submodule, commited the changes; Commited the submodule commit change in the rust repo; Built. Rustbuild did not seem to pick up on the submodule being changed.
LLVM rebuild is currently triggered only when contents of and stamps disagree (including being non-existent), so it's always manual. Full checking of something in LLVM being outdated is not performed because it's expensive thing to do on every build, but the submodule state check can be performed I guess.
Change:
<ins> // assembly-output: emit-asm // compile-flags: --crate-type=lib // only-x86_64 // ignore-sgx #![feature(portable_simd)] use std::simd::Simd; use std::arch::asm; #[target_feature(enable = "avx")] #[no_mangle] // CHECK-LABEL: convert: pub unsafe fn convert(a: *const f32) -> Simd<f32, 8> { // CHECK: vbroadcastss (%{{[er][a-ds0-9][xpi0-9]?}}), {{%ymm[0-7]}} let b: Simd<f32, 8>; unsafe { asm!( "vbroadcastss {b}, [{a}]", a = in(reg) a, b = out(ymm_reg) b, ); } b } </ins>

Discussion:
I tried this code: I expected to see this happen: I thought this would compile and do as it says since, states that accepts vector types., like f64x8 and i64x8. Instead, this happened: <!-- 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. --: No backtrace applicable.
This is partly a diagnostics issue. The type you refer to in is more abstract, in that we permit it to be compiled in a way that does not actually use an AVX512 register. The type that the documentation is trying to refer to is... very not. Thus it needs a conversion step to/from the "definitely a hardware register" type. The implementation that we should be recommending is: Obviously that's a fair few steps to get from here to there and we can also consider ways to smooth this path further.
It turns out this was actually more possible than I expected by simply changing how inline accepts arguments, and validating that still has an equivalence to a register, so this code now passes:
Change:
/// - the self type /// - the *other* type parameters of the trait, excluding the self-type /// - the parameter environment <ins> /// /// Invokes `evaluate_obligation`, so in the event that evaluating /// `Ty: Trait` causes overflow, EvaluatedToRecur (or EvaluatedToUnknown) /// will be returned. </ins> fn type_implements_trait( &self, trait_def_id: DefId,

Discussion:
While trying to migrate  0.11.1 to the 2021 edition, the compiler fails with this error: It is hard to create a small reproduction, but here is the command to run in that package to reproduce the error: I'm not sure if it is feasible to avoid this. I'm guessing that the lint is doing some kind of trait evaluation that happens to add some additional recursion that is not normally there. Adding fixes the problem. Opening this issue to track whether or not there is anything to do here. Note that the lint doesn't actually fire, so this is just during the analysis (presumably somewhere in ). Full error: <!-- 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
don't think I have much context on this one either
I think the problem here is that we are using : But that uses : which is the variant that aborts on overflow we could write into and or something like that. I have to look at the places that call -- in this case, if we see overflow, we could just treat it as false. Scanning where is used: diagnostics, would be better to squelch overflow here too as above as above seems to be for lints, as above (side note that the is-drop-implemented-for-ty is not needed, right?) prelude2021: another 2021 lint, would prefer not to abort clippy: also a lint, probably also true there So, my proposed fix is that we change to return false on overflow. i.e., if it overflows, we don't know that the type implements the trait (we don't, in fact, know anything at all). The function is already approximating in the case of generics -- i.e., a false result doesn't mean that the type does NOT implement the trait, just that we don't know that it does.
Change:
#![allow(dead_code)] struct Foo; <del> impl Fn<(), ()> for Foo { //~ ERROR manual implementations of `Fn` are experimental </del> <ins> impl Fn() for Foo { //~ ERROR manual implementations of `Fn` are experimental </ins> extern "rust-call" fn call(&self, args: ()) -> () {} } struct Bar; <del> impl FnMut<(), ()> for Bar { //~ ERROR manual implementations of `FnMut` are experimental </del> <ins> impl FnMut() for Bar { //~ ERROR manual implementations of `FnMut` are experimental </ins> extern "rust-call" fn call_mut(&self, args: ()) -> () {} } struct Baz; <del> impl FnOnce<(), ()> for Baz { //~ ERROR manual implementations of `FnOnce` are experimental </del> <ins> impl FnOnce() for Baz { //~ ERROR manual implementations of `FnOnce` are experimental </ins> extern "rust-call" fn call_once(&self, args: ()) -> () {} }

Discussion:
We do not expect to completely "unfeature-gate" unboxed closures for 1.0. We wish to reserve the flexibility to change a few aspects: to variadic generics in place of auto-tupling. the and arguments from input types to (possibly) associated types. (cc ) the coherence story with respect to fn-trait hierarchy. (cc ) To this end we will adjust the features to: [ ] Disallow references to the traits using angle bracket notation [x] Disallow user impls of the traits [x] Disallow direct calls to [x] Disallow parenthetical notation () from being used with anything other than the traits In short, we permit unboxed closures to be used as if they are a language builtin, but disallow (for now) a lot of the more generic uses. We should be able to drop this feature gate shortly after 1.0. cc
Nominating for 1.0 or something. :)
P-backcompat-lang, 1.0.
Note that some of this works today though it ought not, e.g. manually implementing traits.
To expand on comment, the following code fails to compile due to the lack of a feature that should be gated: The current solution is to put on the function.
This was done, or done enough.
Oops, I totally overlooked that is still considered legal. It's important to adjust that too!
Change:
#![feature(extend_one)] #![feature(const_panic)] #![feature(const_generics)] <ins> #![feature(once_cell)] </ins> #![allow(rustc::default_hash_types)] #[macro_use]

Discussion:
After is merged, usage of in this module: should be replaced by . The dependency from corresponding can be removed afterwards. It might make sense to request a perf run, as version uses parkinglot, while the standard one uses std mutex, but I expect the difference to not matter -- fast path is equivalent for both.
claim
is done! Though, I am not unsure if we maybe should wait until it tickles down to beta? Not sure how bootstraping works with libstd, I guess, we can just try and see if the build fails.
The compiler always builds with the in-tree standard library, so cfg(bootstrap) should never be necessary (beyond lints, and other compiler-implemented rather than library-implemented) details.
ping this is ready to be implemented.
I'll start soon! Sorry I got a bit overwhelmed with work. If in the next couple of days I haven't replied feel free to re-assign.
On it!
once this is merged, should other sub-crates that depend on also be updated? Like for example. Also, what about ? Some usage can probably be replaced by .
We definitely should actively remove oncecell crate from all rustc’s crates, because having two difference sources of the same data structure feels bad. Replacing lazystatic with std::lazy would also be good!
I'll try to take of it once this issue is fixed :+1:
Change:
<ins> // Copyright 2014 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. // Checks that immutable static items can't have mutable slices static TEST: &'static mut [int] = &mut []; //~^ ERROR static items are not allowed to have mutable slices pub fn main() { } </ins>

Discussion:
This line in my project currently causes an unimplemented expression error, told me to submit an issue
Change:
use crate::query::Providers; use crate::ty::{EarlyBinder, ImplSubject, TyCtxt}; <ins> use rustc_data_structures::fingerprint::Fingerprint; use rustc_data_structures::sorted_map::SortedMap; use rustc_data_structures::stable_hasher::{HashStable, StableHasher}; </ins> use rustc_data_structures::sync::{try_par_for_each_in, DynSend, DynSync}; use rustc_hir::def::DefKind; use rustc_hir::def_id::{DefId, LocalDefId, LocalModDefId};

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' '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: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [associatedtypeforimpltraitintrait] creating the associated item corresponding to the opaque type [associatedtypesforimpltraitsinassociatedfn] creating associated items for opaque types returned by [associateditemdefids] collecting associated items or fields of [associateditems] collecting associated items 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 --
This will probably make a simple crash in a lot of cases :3
cc
minimal repro:
Hmm, when writing I tried to trigger the case by enabling , but it didn't ICE. I'll check what is the difference with what cargo does.
Fixed in
A workaround to this issue should be to use or which should disable incremental compilation.
run on nightly rust also  but. if you use to switch stable version rust will be run will successful
There’s also an environment variable to control incremental compilation, so you could set CARGO_INCREMENTAL=0 to do that.
I think this error should be completely fixed, otherwise it will still fail to compile in the IDE environment and the automatic build environment of GitHub Action
Sure, we were just offering a workaround to unblock people temporarily. The fix is already present on master and should be available in tomorrow’s nightly.
Oh, this is great
Change:
"compiler_builtins", "crc32fast", "flate2", <del> "hashbrown 0.14.0", </del> <ins> "hashbrown 0.14.2", </ins> "indexmap 2.0.0", "memchr", "rustc-std-workspace-alloc",

Discussion:
I tried this code: I expected to see this happen: map = {1: "a"} Instead, error happened: Sometimes it causes Segmentation fault: <!-- 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
Miri reports UB with the target in question: (sorry for reflexively blaming LLVM, it didn't deserve that)
The root cause is that the stdarch SIMD intrinsics are broken on big-endian targets. For now I've disabled the use of NEON in hashbrown on big-endian ARM: We should probably disable/de-stabilize the NEON intrinsics on big-endian targets. They are currently all producing incorrect results.
All of them, or specifically for ARM? (Not sure if we have stdarch support for any other big-endian target.) Is there an issue tracking that and explaining in a bit more detail how they are broken?
This only applies to arm & aarch64 targets. Here is the issue in stdarch:
Miri doesn't support the NEON SIMD intrinsics though. So if Miri reports UB then it seems there are other problems as well?
Some are implemented using the same intrinsics as portable-simd.
It's a combination of a few things: We are missing a check for the NEON implementation. All the NEON intrinsics we happen to use in hashbrown are implemented without LLVM builtins.
Ah so I guess what happens is that Miri correctly implements the portable SIMD intrinsics, but stdarch implements the NEON intrinsics on top of them and it's doing that incorrectly? Miri and codegen/LLVM are fine?
Yes, that's my understanding.
Change:
use rustc::mir::interpret::{ truncate, Allocation, ConstValue, LitToConstError, LitToConstInput, Scalar, }; <del> use rustc::ty::{self, layout::Size, ParamEnv, TyCtxt}; </del> <ins> use rustc::ty::{self, layout::Size, ParamEnv, TyCtxt, TyS}; </ins> use rustc_span::symbol::Symbol; use syntax::ast;

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on and , but not on . <details<summaryNightly backtrace</summary</details
triage: P-high, assigning to self.
(This ended up being a great motivation for me to tie off some work I've been doing...)
ICE was introduced between nightly 2020-01-15 and 2010-01-16. Here are the merges from that time period: ( is independently working to identify which one is the culprit.)
Okay finished: searched nightlies: from nightly-2020-01-15 to nightly-2020-01-22 regressed nightly: nightly-2020-01-16 searched commits: from to regressed commit:
Looks like the problem was injected by PR
reassigning to
The following also causes an ICE: (Same reason, but different message.)
Fixed by
Change:
<ins> // run-pass // edition:2021 pub fn foo() { let ref_x_ck = 123; let _y = || match ref_x_ck { 2_000_000..=3_999_999 => { println!("A")} _ => { println!("B")} }; } fn main() { foo(); } </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. --Regarding a minimal example I am afraid I'm not quite able to provide one, this bug occured when i was migrating to Rust 2021 as part of the testing efforts. The branch/PR with the Rust 2021 modifications can be found here I did cfgment all modules except the ones that are required to trigger the bug out: And removed most code and modules from the rcc module: , nailing the bug down to (as the error message suggested). Then i minized further in (its 200 lines now, the rest is just tests) And I was in fact able to pin point the panic to this piece of code: , if I comment it out the ICE doesn't occur anymore so I would guess that this is what the compiler is having issues with. <!-- 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. --: Compilation command I used was: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Thanks for the report! Here's a somewhat minimized reproduction:
cc
claim
Change:
|                 help: missing comma here error: no rules expected the token `d` <del> --> $DIR/missing-comma.rs:23:18 </del> <ins> --> $DIR/missing-comma.rs:27:18 </ins> | LL | macro_rules! foo { | ---------------- when calling this macro

Discussion:
I don't know what to make of this error. () Errors: On stable (1.34) the output is
I'm pretty sure this is fallout from the "missing comma here" suggestion for macros, that evaluates the macro again with the current arguments but adding a comma token in between the argument tokens in different combinations to see if it would be correct. My guess is that that is causing a parse error that doesn't happen for normal things than only have one token in them. We can disable the suggestion when fully qualified paths are involved.
Change:
<ins> // check-pass // Regression test for issue #90662 // Tests that projection caching does not cause a spurious error trait HasProvider<T: ?Sized> {} trait Provider<M> { type Interface: ?Sized; } trait Repository {} trait Service {} struct DbConnection; impl<M> Provider<M> for DbConnection { type Interface = DbConnection; } struct RepositoryImpl; impl<M: HasProvider<DbConnection>> Provider<M> for RepositoryImpl { type Interface = dyn Repository; } struct ServiceImpl; impl<M: HasProvider<dyn Repository>> Provider<M> for ServiceImpl { type Interface = dyn Service; } struct TestModule; impl HasProvider<<DbConnection as Provider<Self>>::Interface> for TestModule {} impl HasProvider<<RepositoryImpl as Provider<Self>>::Interface> for TestModule {} impl HasProvider<<ServiceImpl as Provider<Self>>::Interface> for TestModule {} fn main() {} </ins>

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 (minimized from [this test] in my library): [this test]: I expected to see this happen: Compile without errors. Instead, this happened: Compiled with errors: Note that it says is not implemented for , but then lists it as an existing implementation. It most recently worked on: 1.55.0 : <!-- 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 --
modify labels: +regression-from-stable-to-stable
Bisects to . cc searched nightlies: from nightly-2021-07-01 to nightly-2021-10-01 regressed nightly: nightly-2021-09-03 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Any advancements on this issue? I currently can't upgrade to Rust 1.56 due to this exact problem
I might try my hand at diagnosing it, but someone with more context would definitely be faster at it.
Sorry for the delay in getting to this. I've opened with a fix.
I noticed that this regression was found in the 1.56 beta crater run: https://crater- Was it just overlooked at that time?
Seems kinda major to Yeah, this seems rather significant. It's right there in the results. https://crater-
Change:
#[inline] #[stable(feature = "rust1", since = "1.0.0")] pub fn iter_mut(&mut self) -> IterMut<'_, T> { <del> IterMut { head: self.head, tail: self.tail, len: self.len, list: self } </del> <ins> IterMut { head: self.head, tail: self.tail, len: self.len, marker: PhantomData } </ins> } /// Provides a cursor at the front element.

Discussion:
(playground) label T-libs-impl, A-collections <hrCaused by violation of safety invariant as documented in yet implementation does I’m not sure where the field is really used at all, so maybe it can be replaced by a marker , similar to ’s implementation.
Assigning according to the and removing I-prioritize. modify labels -I-prioritize +P-critical
Good catch! Iterator debug implementations seem to be woefully under-audited in terms of soundness problems (this is such issue).
maybe you can help me out with how to run miri while hacking (a question that came up for the PR fixing this: ). I have no trouble compiling or testing a modified with , or linking a toolchain for usage (so that or are working) so that I can play around with it in a crate, but I don’t know how to run on such a local crate depending-on/using a modified .
Miri uses xargo for sysroot compilation, so setting will tell Miri which standard library to use. (It must be set to the folder in a rustc checkout.) You can then use a standard Miri, no rustup toolchain linking is required.
Oh, also, if you want to run the alloc/core test suites in Miri, see
Change:
<ins> error: `recursion_limit` must be a non-negative integer --> $DIR/overflow.rs:3:1 | LL | #![recursion_limit = "999999999999999999999999"] | ^^^^^^^^^^^^^^^^^^^^^--------------------------^ |                      | |                      `recursion_limit` is too large error: aborting due to previous error </ins>

Discussion:
The following code since it exceeds the default recursion limit. Using as the recursion limit works as expected. This is because we don't check for integer overflow errors when parsing limits: There's a few options here. My preference would be to silently default to when overflow occurs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi! I'd like to try and handle this. If I understand this correctly, we should check if there is an , and if that error is an overflow. If it's an overflow, we default to ? claim
correct