jiebi/CodeConvo huggingface dataset:
Change:
#![crate_type = "bin"] #![feature(phase)] <ins> // we use our own (green) start below; do not link in libnative; issue #13247. #![no_start] </ins> #![allow(non_camel_case_types)] #![deny(warnings)]

Discussion:
Original title: "compiletest has implicit dependency on libnative" compiletest has implicit dependency on libnative When I tried to do , I get the following: says this is because, despite 's continued use of , there is an implicit attempt to link in unless one puts in a attribute into the crate attributes. I plan to try to fix this pronto. After fixing the above, I get: So there's another separate problem blocking from working.
Still working on this, there was a new problem that came up (run-pass-fulldeps needs libsyntax to have been rebuilt), so I've updated the description and the title to reflect the more general issue here.
Change:
pub use consts::os::c95::*; pub use consts::os::posix88::*; pub use consts::os::posix01::*; <ins> pub use consts::os::posix08::*; </ins> pub use consts::os::bsd44::*; pub use consts::os::extra::*;

Discussion:
After lands we will be setting on all file descriptors on unix in the standard library. Currently we do so in a nonatomic fashion, however, so it's possible to continue to leak file descriptors into children if a thread is concurrently forking. Many platforms have methods of creating file descriptors atomically, but many of the APIs are quite new and they need to be properly detected at runtime. For example, the current instances of that need to be migrated are listed below. A reminder of our minimum platform requirements are linux 2.6.18 and OSX 10.7. [x] - this should specify the flag. This flag was in linux 2.6.23 and appears to exist on OSX 10.7. [x] - this should be specify the flag in the argument (second). This flag was only in linux 2.6.27 and does not exist on OSX. [x] - this should be replaced with a call to . This system call was only in linux 2.6.28 and does not exist on OSX. [x] - this should be replaced with (linux 2.6.27, not on OSX) or (linux 2.6.24, appears to exist on OSX 10.7). [x] - this could be replaced with on linux 2.6.27 and perhaps on OSX (not confirmed). The hard part about this bug is figuring out if it's possible to avoid compile-time detection of these functions (and instead rely on runtime detection).
cc
I know this is closed, but I just have to comment on how well thought out and organised the original description was - how clearly the problem is captured and then it's solution tracked. Well done everyone.
Change:
/// - total and antisymmetric: exactly one of `a < b`, `a == b` or `a > b` is true; and /// - transitive, `a < b` and `b < c` implies `a < c`. The same must hold for both `==` and `>`. /// <ins> /// ## Derivable /// </ins> /// This trait can be used with `#[derive]`. When `derive`d, it will produce a lexicographic /// ordering based on the top-to-bottom declaration order of the struct's members. <ins> /// /// ## How can I implement `Ord`? /// /// `Ord` requires that the type also be `PartialOrd` and `Eq` (which requires `PartialEq`). /// /// Then you must define an implementation for `cmp`. You may find it useful to use /// `cmp` on your type's fields. /// /// Here's an example where you want to sort people by height only, disregarding `id` /// and `name`: /// /// ``` /// use std::cmp::Ordering; /// #[derive(Eq)] /// struct Person { ///     id: u32, ///     name: String, ///     height: u32, /// } /// /// impl Ord for Person { ///     fn cmp(&self, other: &Self) -> Ordering { ///         self.height.cmp(&other.height) ///     } /// } /// /// impl PartialOrd for Person { ///     fn partial_cmp(&self, other: &Self) -> Option<Ordering> { ///         Some(self.cmp(other)) ///     } /// } /// /// impl PartialEq for Person { ///     fn eq(&self, other: &Self) -> bool { ///         self.height == other.height ///     } /// } /// ``` </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait Ord: Eq + PartialOrd<Self> { /// This method returns an `Ordering` between `self` and `other`.

Discussion:
I'm using s as keys in a BtreeMap. I have to look up the map ~15 million times per second (10G ethernet line rate). Ipv4Addr cmp() compiles to this on my system (linux x86-64, rustc 1.10.0-nightly ( 2016-05-21)) Which seems kinda inefficient for a thing which is basically u32. I guess part of the reason is the which converts it to an array(!) first. I copied the definition and implemented Ord like this: It's about 10 times faster on my .
Nice find! Want to send a PR for this? Looks like something that'd be more than welcome :)
Change:
<ins> error[E0124]: field `field` is already declared --> $DIR/duplicated-fields-issue-125842.rs:6:5 | LL |     field: Option<u8>, |     ----------------- `field` first declared here LL |     field: u8, |     ^^^^^^^^^ field already declared error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0124`. </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. --:
with debug assertions: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
without: --<details<summary<strongBacktrace</strong</summary<p</p</details

<!-- 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. --(reduced) <details<summary<strongOriginal Code</strong</summary<p</p</details<!-- 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- has the same ICE location, but this one doesn't require any feature to make ICE. ICE-loc: Original ICE-triggering code is mutated from test-file
bisects to searched nightlies: from nightly-2024-01-01 to nightly-2024-04-30 regressed nightly: nightly-2024-02-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The following already reproduces on 1.77 stable
Change:
} pub fn ns(&self) -> u64 { <del> self.t as u64 * 1_000_000_000 / frequency() as u64 </del> <ins> mul_div_i64(self.t as i64, NANOS_PER_SEC, frequency() as i64) as u64 </ins> } }

Discussion:
The of uses a 64 bit multiplication that will overflow frequently. Using floats would be the easy way out, but it would reduce precision to 53 bits.
As a datapoint, this is literally what . Where is a . But we're multiplying by an extra 1000.
In fairness to Microsoft, they're operating on a time difference computed mod 2^64, so as long as the interval length is reasonable (less than a few thousand hours for a typical tick rate) it can't overflow. But computes an absolute time rather than a difference, so overflows are guaranteed to happen at some point. The 1000x factor only makes it more noticeable.
Since we're dealing with absolute time (and therefore something large), it's probably not unreasonable to divide first, or maybe even partially multiply by . Something like: maybe? What are "typical" and "extreme" tick rates and absolute ticks like? An incredibly robust implementation could presumably branch on the size of ticks to determine the optimal split of the .
The x86_64 architecture has the 64 bit MUL instruction whose result is effectively a 128 bit integer which never overflows. Likewise, the DIV instruction takes an effectively 128 bit integer as the dividened. i386 offers (u32, u32) -u64 MUL and (u64, u32) -(u32, u32) DIV/MOD, so we should be able to implement 64 bit MUL and DIV without overflow. Windows RT runs on ARMv7 (=~ Cortex-A). It has (u32, u32) -u64 UMULL but lacks DIV and we have to call a division routine. Perhaps we can forget about it for now...
We could use techniques similar to . Of course, in this case, we also have the multiplier, which together with the "magic constant" is going to overflow even a 128 bit register, but multiplication can be done "in parts".
Don't OSX and iOS have a similar problem and ? What is the typical value of seems to suggest that is can be large, just like on Windows.
^
Change:
.filter_map(|tr| { if !tr.def_id.is_local() && self.r.session.crate_types().contains(&CrateType::ProcMacro) <ins> && matches!( self.r.session.opts.resolve_doc_links, ResolveDocLinks::ExportedMetadata ) </ins> { // Encoding foreign def ids in proc macro crate metadata will ICE. return None;

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 ran with this code: I expected to see this happen: intra-doc-links work and no warning Instead, this happened: intra-doc-links is not working in the generated docs. <img width="215" alt="doc" src="https://user-"And I got brokenintradoc_links warnings: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: nightly-2023-02-11 <img width="215" alt="doc-old" src="https://user-"<!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. -- modify labels: +regression-from-stable-to-nightly -regression-untriaged
Fixed in
label A-intra-doc-links
Change:
false } } <ins> } else if tcx.trait_is_auto(trait_ref.def_id) { tcx.dcx().span_delayed_bug( tcx.def_span(obligation.predicate.def_id), "associated types not allowed on auto traits", ); false </ins> } else { bug!("unexpected builtin trait with associated type: {trait_ref:?}") }

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<strongICE location label +A-auto-traits +F-unboxed_closures
Minimized: <details<summaryError output</summary</details label -F-unboxedclosures +F-autotraits
Regression in nightly-2023-06-18 (...)
probably just another duplicate of

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unexpected builtin trait with associated type: <u16 as Z<'b, u16', 'error: internal compiler error: unexpected builtin trait with associated type: <u16 as Z<'b, u16' 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
Regression in nightly-2023-06-18 Regression in / ping
The depth of the stack at the ICE depends on the recursion limit. Add and it still ICEs, but with only 8 repeated stack portions.
Simplified to use only locally defined traits, not use a lifetime parameter, and hit fewer errors: Oddly enough, this variant hits the same ICE but without such a deep stack.
You can replace the bound with a lifetime bound to reproduce too, such as .
Change:
#[must_use] pub struct FatalError; <del> pub struct FatalErrorMarker; </del> <ins> pub use rustc_data_structures::FatalErrorMarker; </ins> // Don't implement Send on FatalError. This makes it impossible to panic!(FatalError). // We don't want to invoke the panic handler and print a backtrace for fatal errors.

Discussion:
found while checking with When you run the snipped above with , rustc panics, but the exit status is as if there was just a normal compiler error, instead of a . This tripped up automatic ice-reduction that relies on a somewhat familiar exit code when the program crashes :sweat_smile:
is the problematic line here that turns ICEs into "normal" fatal errors that call exit(1) though actually at least with the non parallel compiler i'm very surprised that we're ending up in a query in the first place after panicking.
It seems that current stable does correctly exit with here... I bisected the exit code 101 -exit code 1 change with a crashing file ( ) and got to Regression in nightly-2023-08-31 Regression in cc /
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
help: use `Box::new()` instead | LL |     let _ = Box::new(T { a: 12, b: 18 }); <del> |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ </del> <ins> |             ~~~~~~~~~                  + </ins> error: `box_syntax` has been removed --> $DIR/removed-syntax-box.rs:12:13

Discussion:
Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).
Change:
<ins> trait Bar { fn foo(&mut self) -> _ { //~^ ERROR the placeholder `_` is not allowed within types on item signatures for return types Self::foo() //~ ERROR  this function takes 1 argument but 0 arguments were supplied } } fn main() {} </ins>

Discussion:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' File: /home/gh- --auto-reduced (treereduce-rust): original: Version information ` <!-- query stack: [typeck] type-checking [fnsig] computing function signature of --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Possibly related to , possibly somewhat related to , cc very astute assertions!
claim
Change:
"""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')

Discussion:
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).
Change:
let source_map = self.r.session.source_map(); <ins> // Make sure this is actually crate-relative. let is_definitely_crate = import .module_path .first() .map_or(false, |f| f.ident.name != kw::SelfLower && f.ident.name != kw::Super); </ins> // Add the import to the start, with a `{` if required. let start_point = source_map.start_point(after_crate_name); <del> if let Ok(start_snippet) = source_map.span_to_snippet(start_point) { </del> <ins> if is_definitely_crate && let Ok(start_snippet) = source_map.span_to_snippet(start_point) { </ins> corrections.push(( start_point, if has_nested {

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <details<summaryIf the starting order is reversed, the suggestion puts the macro first in the tree</summary</detailsThis is suggesting to change the code to itself It needs to move the import into a tree; the easy way is to make a new statement (and let rustfmt clean that up); the medium way is to find an existing context; the hard way is when a tree root doesn't already exist (or isn't immediately a tree at that point) determine what the code is using and match that. Related: label +D-confusing +D-incorrect
In this case, the ideal solution is actually to write just and get the import from legacy-lexical-macro-scope into the namespace. I originally hit this with just multiple macros in the use tree, and removing the was the correct fix. I "simplified" for the error report to use a second non-macro item here (to reduce the number of diagnostics). So bonus challenge: handle this case properly and only emit a single help: <details
label +D-invalid-suggestion It's not producing invalid code, but it's surely suggesting a fix which will cause an error (the identical one).
Change:
Rvalue::Len(place) | Rvalue::Discriminant(place) | Rvalue::Ref(_, _, place) => { check_place(tcx, mir, place, span, PlaceMode::Read) } <del> Rvalue::Cast(_, operand, cast_ty) => { </del> <ins> Rvalue::Cast(CastKind::Misc, operand, cast_ty) => { </ins> use rustc::ty::cast::CastTy; let cast_in = CastTy::from_ty(operand.ty(mir, tcx)).expect("bad input type for cast"); let cast_out = CastTy::from_ty(cast_ty).expect("bad output type for cast");

Discussion:
<short summary of the bugReturning from a const fn causes internal compiler error, with the message 'bad input type for cast'. I tried this code: Minimal example Original example I expected to see this happen: program compiles and prints 'Hello 1' or I get a compiler error. Instead, this happened: ICE
that gives the exact backtrace above.
Relavent code: The types here are and .
The actual bug would be here then, right?
Not quite sure, but the real bug is that we allow the keyword in const fn XD I already have a fix since yesterday, but the german bahn didn't give me electricity so my notebook died while tests were running
no ICE fix from the ICE? :p
Change:
cfg.define("COMPILER_RT_HAS_UNAME", Some("1")); } <ins> // Assume that the Unixes we are building this for have fnctl() available if env::var_os("CARGO_CFG_UNIX").is_some() { cfg.define("COMPILER_RT_HAS_FCNTL_LCK", Some("1")); } // This should be a pretty good heuristic for when to set // COMPILER_RT_HAS_ATOMICS if env::var_os("CARGO_CFG_TARGET_HAS_ATOMIC").map(|features| { features.to_string_lossy().to_lowercase().contains("cas") }).unwrap_or(false) { cfg.define("COMPILER_RT_HAS_ATOMICS", Some("1")); } </ins> // The source for `compiler-rt` comes from the `compiler-builtins` crate, so // load our env var set by cargo to find the source code. let root = env::var_os("DEP_COMPILER_RT_COMPILER_RT").unwrap();

Discussion:
For example and are not being set. Would it be possible to use (i.e. compiler-rt's regular build system) to find out which flags to set? cc
I wonder if I can somehow use for detecting whether to set the flags. I guess that executing this in the build script would only tell me about the host platform, right? Is there a way to query 's target platform spec?
If you execute Cargo will use that to set env vars for the build script. When a build script is executed the env vars match the target we're executing the script for, so Cargo should set (IIRC). Either that should be fine or just simply enabling it via a whitelist of platforms would be fine by me personally
Indeed: :heart:
Change:
#[subdiagnostic] pub string_interp: Vec<UnusedVariableStringInterp>, #[subdiagnostic] <del> pub sugg: UnusedVariableTryPrefixSugg, </del> <ins> pub sugg: UnusedVariableSugg, pub name: String, </ins> } #[derive(Subdiagnostic)] <del> #[multipart_suggestion(passes_suggestion, applicability = "machine-applicable")] pub struct UnusedVariableTryPrefixSugg { #[suggestion_part(code = "_{name}")] pub spans: Vec<Span>, pub name: String, </del> <ins> pub enum UnusedVariableSugg { #[multipart_suggestion(passes_suggestion, applicability = "machine-applicable")] TryPrefixSugg { #[suggestion_part(code = "_{name}")] spans: Vec<Span>, name: String, }, #[help(passes_unused_variable_args_in_macro)] NoSugg { #[primary_span] span: Span, name: String, }, </ins> } pub struct UnusedVariableStringInterp {

Discussion:
Consider the following file in a cargo package: Cargo will warn that is not used. Upon running , cargo will change the second parameter from to , making the compilation fail. Even worse, if contained a field then would change the variable without producing any warning. a new cargo binary project with the above snippet in (presumably with ) No response No response
just applies any  suggestion produced by . In this case, the suggestion from is to replace with . I went ahead and ran to see if it could help me understand what is going on better: ` (I cleaned up the expanded code slightly, but it is the same) Looking at the expanded code, it makes me think that is seeing in as the source of the problem since it expands to and is unused in this case. The normal suggestion is to add an underscore to so it would not be "unused". So suggests to change the being passed to the macro call as it does not understand that the warning is really coming from within the macro, not the call itself. It also could be suggesting this as is not valid rust (macro?) syntax. If you change your example slightly, correctly suggests the problem comes from within the macro call. To me, this seems like a problem with , but I do not know enough about the compiler internals to be 100% certain.
Transferred to rust-lang/rust, since the suggestions are generated by the compiler.
Yes, this issue comes from rustc. The lint is emitted from here Maybe we only point out that there is an unused variable coming from , but without the suggestion? I'm not sure what is a proper lint for this test case. any thoughts on it?
The quick and straightforward way to fix this would be to only emit the suggestion in this lint if the span has the root context, but then a subset of valid suggestions wouldn't be emitted. I had an older PR that I'm having trouble finding that would automatically do that for every diagnostic, but IIRC it had some negative perf impact when not implementing it very simplistic. In this we can probably instead check that all of the spans involved have the same . If they don't, don't suggest changes.