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. --<!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I have no idea why this exists, nor does removing it change test output. Someone should find out what it's for, and also add tests around this code ideally.
claim
Reason add 1 to 0 is to match the "pluralize" macro. In the macro, if x is not 1 (more than 1), then append "s" (indicating as plural). If x is 1, then append nothing. Thus satisfy the "pluralize" macro.
claim
Ok looks like this can be closed because the solution was merged in
claim
Hello, I see someone else already assigned, but this issue is still "open" and has the "help wanted" tags. I'm new to contributing to Rust, so if you're willing to help, I'd be happy to help. Thanks!
Hi David, Apekros has already posted a PR for this one: which has not been merged yet however.

Discussion:
<ins> // check-fail // edition:2021 // test for issue-114912 - debug ice: attempted to add with overflow async fn main() { //~^ ERROR `main` function is not allowed to be `async` [0usize; 0xffff_ffff_ffff_ffff].await; //~^ ERROR `[usize; usize::MAX]` is not a future } </ins>

<ins> error[E0277]: `[usize; usize::MAX]` is not a future --> $DIR/debug-ice-attempted-to-add-with-overflow.rs:8:37 | LL |     [0usize; 0xffff_ffff_ffff_ffff].await; |                                    -^^^^^ |                                    || |                                    |`[usize; usize::MAX]` is not a future |                                    help: remove the `.await` | = help: the trait `Future` is not implemented for `[usize; usize::MAX]` = note: [usize; usize::MAX] must be a future or must implement `IntoFuture` to be awaited = note: required for `[usize; usize::MAX]` to implement `IntoFuture` error[E0752]: `main` function is not allowed to be `async` --> $DIR/debug-ice-attempted-to-add-with-overflow.rs:6:1 | LL | async fn main() { | ^^^^^^^^^^^^^^^ `main` function is not allowed to be `async` error: aborting due to 2 previous errors Some errors have detailed explanations: E0277, E0752. For more information about an error, try `rustc --explain E0277`. </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. --Investigating library sources for , I have found that the copying of the env variable value is performed not under the lock: So there is a potential data race with setenv. I tried this code with miri And got Have tried to move under the lock, but still got error with miri. I was not able to trigger the real crash with it yet. <!-- 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. --: Bug was introduced by this commit: (PR: ) Before that changes, read was under the lock. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
I think this happened because implicit scoping of the lock guard, which makes it easy to shorten its lifetime the rwlock isn't coupled to the resource via a lifetime, so it's easy for the extracted pointer to be used longer than the lock is valid The first one could be made more visible by linting to add an explicit to make its lifetime more explicit in the code when a critical section ends. Especially when guard is otherwise unused which indicates that the lock doesn't directly own the resource it protects. The second one could be solved by using a lifetime-tagged raw pointer and coupling that lifetime to the guard.
Side note: even when fixed this assumes all other read/writes acquire Rust's lock and is potentially unsound if they do not. This has often been discussed with a view to making unsafe. Arguably if that happens then the lock would be redundant, although it could also be argued it's still useful to help avoid some footguns even if you can't make it totally safe.
That's
That PR did not add a test, did it? Would be good to add one in (those are run in Miri regularly). We probably don't want iterations though, that will take forever. 100 should easily be enough.
Something like ?
Yeah something like that. For Miri it's not really necessary to do this "sum of the lengths" computation, not sure why that would be particularly susceptible to a data race. The one existing concurrency test uses , so probably it would make sense to use the same attribute here.

Discussion:
mod common; use common::test_rng; <ins> use std::thread; </ins> #[track_caller] fn make_rand_name() -> OsString {

} } } <ins> #[test] // miri shouldn't detect any data race in this fn #[cfg_attr(any(not(miri), target_os = "emscripten"), ignore)] fn test_env_get_set_multithreaded() { let getter = thread::spawn(|| { for _ in 0..100 { let _ = var_os("foo"); } }); let setter = thread::spawn(|| { for _ in 0..100 { set_var("foo", "bar"); } }); let _ = getter.join(); let _ = setter.join(); } </ins>
Change:
I think would be nice to mention in the Rustc Profile-Guided Optimization documentation. With it's much easier to apply PGO to the Rust programs (I did it many times). I suggest adding the information about to the mentioned above page. Even if this project does not belong directly to Rustc or Cargo - it's still worth mentioning. - ping you as the author. P.S. I am creating the issue here since not sure where it should go. Maybe we want to mention in the Cargo book as well. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I don't know if this is already approved, but in case it is, here's my effort for a chance of contribution.
claim
Well, I would of course like it to be mentioned in the docs :) I'm not sure what's the policy on linking to community maintained Cargo subcommands though (if there is any).

Discussion:
to use PGO with Rust. [clang-pgo]: https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization <ins> ## Community Maintained Tools As an alternative to directly using the compiler for Profile-Guided Optimization, you may choose to go with `cargo-pgo`, which has an intuitive command-line API and saves you the trouble of doing all the manual work. You can read more about it in their repository accessible from this link: https://github.com/Kobzol/cargo-pgo For the sake of completeness, here are the corresponding steps using `cargo-pgo`: ```bash # Install if you haven't already cargo install cargo-pgo cargo pgo build cargo pgo optimize ``` These steps will do the following just as before: 1. Build an instrumented binary from the source code. 2. Run the instrumented binary to gather PGO profiles. 3. Use the gathered PGO profiles from the last step to build an optimized binary. </ins>
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. --can't compile linfa, please show me how to fix <!-- 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
this is due to . It turns out that skipping over projection goals that we get back from leads to unconstrained infer vars. It's pretty difficult to create a minimal repro of this, though. This isn't fixed by because the infer var is coming from within 's own normalization.
I'll take a look.
Pretty rough, but here's an MCVE. Still can probably minimize a bit more: (edit: updating as I minimize a bit more)
Okay, here's the simplest MCVE I can make:
WG-prioritization assigning priority (). label -I-prioritize +P-high -needs-triage

Discussion:
continue; }; for obligation in obligations { <ins> debug!(?obligation); </ins> match obligation.predicate.kind().skip_binder() { <ins> // We need to register Projection oblgiations too, because we may end up with // an implied `X::Item: 'a`, which gets desugared into `X::Item = ?0`, `?0: 'a`. // If we only register the region outlives obligation, this leads to an unconstrained var. // See `implied_bounds_entailment_alias_var` test. </ins> ty::PredicateKind::Clause( <del> ty::ClauseKind::RegionOutlives(..) | ty::ClauseKind::TypeOutlives(..), </del> <ins> ty::ClauseKind::RegionOutlives(..) | ty::ClauseKind::TypeOutlives(..) | ty::ClauseKind::Projection(..), </ins> ) => ocx.register_obligation(obligation), ty::PredicateKind::Clause(ty::ClauseKind::WellFormed(arg)) => { if wf_args_seen.insert(arg) {

<ins> // check-pass trait Data { type Elem; } impl<F, S: Data<Elem = F>> Data for ArrayBase<S> { type Elem = F; } struct DatasetIter<'a, R: Data> { data: &'a R::Elem, } pub struct ArrayBase<S> { data: S, } trait Trait { type Item; fn next() -> Option<Self::Item>; } impl<'a, D: Data> Trait for DatasetIter<'a, ArrayBase<D>> { type Item = (); fn next() -> Option<Self::Item> { None } } fn main() {} </ins>
Change:
here are what I have done to install rust from source, and I am new in rust. can someone offer me some help about this error and give me detailed instruction on how to install rust from source correctly? download the zip file to /public/home/litz/mysw the zip file in the same dir with the error
I think I am hitting the same issue, running git bisect. Edit: nevermind I missread the issue.
i see that you downloaded the repo as a .zip, i suggest cloning it and checking out the submodules, then try again (i encountered a similar error message and checking out the submodules solved my issues):
It seems like you are downloading the source as a zip file without using Git. During the bootstrapping, we fetch the submodules before invoking Cargo on those paths. However, in your case, since your source doesn't have Git, you don't get the submodules. We should definitely provide better error message for such situations. Thanks for reporting this! If you haven't read, there is https://rustc-dev- If you don't want to use git, then you can download dist tarballs from (e.g., ) which includes submodules out of the box(so you don't need to fetch them with git).

Discussion:
"""Configure, fetch, build and run the initial bootstrap""" rust_root = os.path.abspath(os.path.join(__file__, '../../..')) <ins> if not os.path.exists(os.path.join(rust_root, '.git')) and  os.path.exists(os.path.join(rust_root, '.github')): eprint("warn: Looks like you are trying to bootstrap Rust from a source that is neither a " "git clone nor distributed tarball.nThis build may fail due to missing submodules " "unless you put them in place manually.") </ins> # Read from `--config`, then `RUST_BOOTSTRAP_CONFIG`, then `./config.toml`, # then `config.toml` in the root directory. toml_path = args.config or os.getenv('RUST_BOOTSTRAP_CONFIG')
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. --Sorry, haven't tried to minimise this yet. The repro steps are here: <!-- 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. --: Also reproduces in <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Hoisting the inline structure initialisation into s makes the ICE go away. That... doesn't make a lot of sense to me. <details<summary<strongDiff</strong</summary<p</p</details
Also reproduces in which is our current MSRV
The implementation here should probably also recurse into :
I can confirm that the ICE goes away with the suggested patch.
Possibly related -- while this made the ICE go away, the code when compiled in mode seems to not link. <details<summary<strongmysterious link error</strong</summary<p</p</detailsNaively -- with no understanding of rustc internals -- it feels like a reachability pass that doesn't find these values won't emit them into the library? Slapping some extra attributes around the place is a workaround.

Discussion:
self.worklist.push(def_id); } else { match res { <del> // If this path leads to a constant, then we need to // recurse into the constant to continue finding // items that are reachable. Res::Def(DefKind::Const | DefKind::AssocConst, _) => { </del> <ins> // Reachable constants and reachable statics can have their contents inlined // into other crates. Mark them as reachable and recurse into their body. Res::Def(DefKind::Const | DefKind::AssocConst | DefKind::Static(_), _) => { </ins> self.worklist.push(def_id); } <del> // If this wasn't a static, then the destination is // surely reachable. </del> _ => { self.reachable_symbols.insert(def_id); }

pub static V: &u32 = &X; pub static F: fn() = f; <ins> pub static G: fn() = G0; </ins> static X: u32 = 42; <ins> static G0: fn() = g; </ins> pub fn v() -> *const u32 { V } fn f() {} <ins> fn g() {} </ins>

<ins> // Regression test for #84455 and #115052. </ins> // run-pass // aux-build:static_init_aux.rs extern crate static_init_aux as aux; static V: &u32 = aux::V; static F: fn() = aux::F; <ins> static G: fn() = aux::G; </ins> fn v() -> *const u32 { V

fn main() { assert_eq!(aux::v(), crate::v()); F(); <ins> G(); </ins> }
Change:
lists sparc-unknown-none-elf as Tier 2, but it's Tier 3 as you don't build libcore for it. My bad - no idea how I managed to put it in the wrong table. It's not even alphabetically in the right place.
paging Sorry!
lmao whoops.

Discussion:
`thumbv8m.base-none-eabi` | * | Bare ARMv8-M Baseline `thumbv8m.main-none-eabi` | * | Bare ARMv8-M Mainline `thumbv8m.main-none-eabihf` | * | Bare ARMv8-M Mainline, hardfloat <del> [`sparc-unknown-none-elf`](./platform-support/sparc-unknown-none-elf.md) | * | Bare 32-bit SPARC V7+ </del> `wasm32-unknown-emscripten` | ✓ | WebAssembly via Emscripten `wasm32-unknown-unknown` | ✓ | WebAssembly `wasm32-wasi` | ✓ | WebAssembly with WASI

[`riscv64-linux-android`](platform-support/android.md) |   |   | RISC-V 64-bit Android `s390x-unknown-linux-musl` |  |  | S390x Linux (kernel 3.2, MUSL) `sparc-unknown-linux-gnu` | ✓ |  | 32-bit SPARC Linux <ins> [`sparc-unknown-none-elf`](./platform-support/sparc-unknown-none-elf.md) | * | Bare 32-bit SPARC V7+ </ins> [`sparc64-unknown-netbsd`](platform-support/netbsd.md) | ✓ | ✓ | NetBSD/sparc64 [`sparc64-unknown-openbsd`](platform-support/openbsd.md) | ✓ | ✓ | OpenBSD/sparc64 `thumbv4t-none-eabi` | * |  | Thumb-mode Bare ARMv4T
Change:
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

Discussion:
// 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,

let explicit_link = dest.to_string(); let display_link = link_data.resolvable_link.clone()?; <del> let explicit_len = explicit_link.len(); let display_len = display_link.len(); if (explicit_len >= display_len && &explicit_link[(explicit_len - display_len)..] == display_link) || (display_len >= explicit_len && &display_link[(display_len - explicit_len)..] == explicit_link) </del> <ins> if explicit_link.ends_with(&display_link) || display_link.ends_with(&explicit_link) </ins> { match link_type { LinkType::Inline | LinkType::ReferenceUnknown => {

<ins> // check-pass /// [`…foo`] [`…bar`] [`Err`] pub struct Broken {} /// [`…`] [`…`] [`Err`] pub struct Broken2 {} /// [`…`][…] [`…`][…] [`Err`] pub struct Broken3 {} /// […………………………][Broken3] pub struct Broken4 {} /// [Broken3][…………………………] pub struct Broken5 {} pub struct Err; </ins>
Change:
While investigating the ICE in , I saw that every attempt at writing the ICE details to a file (first implemented in ) would fail on my Windows machine with error messages of this kind: The timestamp format used for the file name separates time components with colons, and Windows is generally finicky about having colons in file names since it is already employed as the drive unit delimiter. Could there be a change in the file name format for better compatibility, at least when running rustc on a Windows host? : </p</details
cc
Yes, we can change the format.

Discussion:
rustc_trait_selection = { path = "../rustc_trait_selection" } rustc_ty_utils = { path = "../rustc_ty_utils" } serde_json = "1.0.59" <del> time = { version = "0.3", default-features = false, features = ["formatting", ] } </del> <ins> time = { version = "0.3", default-features = false, features = ["alloc", "formatting"] } </ins> tracing = { version = "0.1.35" } # tidy-alphabetical-end

use std::sync::atomic::{AtomicBool, Ordering}; use std::sync::OnceLock; use std::time::{Instant, SystemTime}; <del> use time::format_description::well_known::Rfc3339; </del> use time::OffsetDateTime; #[allow(unused_macros)]

None => std::env::current_dir().unwrap_or_default(), }; let now: OffsetDateTime = SystemTime::now().into(); <del> let file_now = now.format(&Rfc3339).unwrap_or_default(); </del> <ins> let file_now = now .format( // Don't use a standard datetime format because Windows doesn't support `:` in paths &time::format_description::parse("[year]-[month]-[day]T[hour]_[minute]_[second]") .unwrap(), ) .unwrap_or_default(); </ins> let pid = std::process::id(); path.push(format!("rustc-ice-{file_now}-{pid}.txt")); Some(path)

$RUSTC src/lib.rs -Z treat-err-as-bug=1 1>$TMPDIR/rust-test-default-set.log 2>&1 default_set=$(cat $TMPDIR/rustc-ice-*.txt | wc -l) content=$(cat $TMPDIR/rustc-ice-*.txt) <ins> # Ensure that the ICE dump path doesn't contain `:` because they cause problems on Windows windows_safe=$(echo rustc-ice-*.txt | grep ':') if [ ! -z "$windows_safe" ]; then exit 1 fi </ins> rm $TMPDIR/rustc-ice-*.txt RUST_BACKTRACE=short $RUSTC src/lib.rs -Z treat-err-as-bug=1 1>$TMPDIR/rust-test-short.log 2>&1 short=$(cat $TMPDIR/rustc-ice-*.txt | wc -l)
Change:
In a fresh install of 1.72.0 there are some files: The same thing happens with 1.71.1.
Performed a test on 1.72.0 and was able to reproduce the problem. With HEAD: , it is no longer present(most probably fixed on the cargo side since it doesn't have anything to do with bootstrapping). If you encounter the problem again, please feel free to re-open the issue.
I'm still hitting this with 1.73.0.
Perhaps it's related to my setting. I'll do more experiments tomorrow and report back...
Still happens with 1.74.0. The terminal output of (I've removed the lines):
Would be nice if you can share your Last time I tried I couldn't reproduce it.
I think I see the same with Rust 1.76:
Are you building multiple targets?
No. I just set following in : and .
should handle this problem.

Discussion:
let host = compiler.host; let src = builder.sysroot(compiler); <del> // Copy rustc/rustdoc binaries </del> <ins> // Copy rustc binary </ins> t!(fs::create_dir_all(image.join("bin"))); builder.cp_r(&src.join("bin"), &image.join("bin")); <ins> // If enabled, copy rustdoc binary </ins> if builder .config .tools

} let datadir = prefix.join(default_path(&builder.config.datadir, "share")); <del> let docdir = prefix.join(default_path(&builder.config.docdir, "share/doc/rust")); </del> <ins> let docdir = prefix.join(default_path(&builder.config.docdir, &format!("share/doc/{package}"))); </ins> let mandir = prefix.join(default_path(&builder.config.mandir, "share/man")); let libdir = prefix.join(default_path(&builder.config.libdir, "lib")); let bindir = prefix.join(&builder.config.bindir); // Default in config.rs

Kind::Install => describe!( install::Docs, install::Std, <ins> // During the Rust compiler (rustc) installation process, we copy the entire sysroot binary // path (build/host/stage2/bin). Since the building tools also make their copy in the sysroot // binary path, we must install rustc before the tools. Otherwise, the rust-installer will // install the same binaries twice for each tool, leaving backup files (*.old) as a result. install::Rustc, </ins> install::Cargo, install::RustAnalyzer, install::Rustfmt,

install::Miri, install::LlvmTools, install::Src, <del> install::Rustc, </del> ), Kind::Run => describe!( run::ExpandYamlAnchors,