jiebi/CodeConvo huggingface dataset:
Change:
use super::make_command_line; <ins> use crate::env; </ins> use crate::ffi::{OsStr, OsString}; <ins> use crate::process::Command; </ins> #[test] fn test_make_command_line() {

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. --I tried this code: I expected to see this happen: a case-sensitive list of environment variables and values, matching the output of from C# and .NET and the output of from PowerShell. It seems we should align the output to match the modern APIs for Windows that Microsoft provides. Instead, this happened: returns all environment variable names in all uppercase. Rust via : C# via : <!-- 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. --: </p</details
I don't think this is related to reading environment variables, but is related to process spawning. If you are spawning a process from a Rust program, then they will be uppercased. But if the Rust program is spawned from something else (like PowerShell), then the env keys should be case-preserved. The issue is . This was originally in to I personally don't think that issue is all that important that all environment keys should be forced to be uppercase. However, if there is a desire to fix both issues, then there would need to be a case-insensitive map (maybe just keep a separate set of uppercased keys?).
thanks for the pointer. For our case, Nushell should be able to spawn processes and keep the environment as expected rather than uppercasing. This allows Nushell to work just as PowerShell spawning a program. As best as I can tell, it's the lookup of a single variable that should be case-insensitive and that listing of variables should maintain the case they had, though I'm far from an expert here.
Hm, the current code does look wrong. Windows environment variables are compared case-insensitive but when set they keep the same case. The simplest improvement here would be remove the and instead implement , and in a way that ignores case differences. However, note that Windows uses Unicode casing, not just ASCII. There is for comparing but using it for would mean lots of conversions from OsString to the Windows string type (and back again). Calling Rust's Unicode functions with a WTF-8 OsString looks tricky too (though maybe there's something I'm missing). I'm uncertain how to approach a proper fix.
Change:
pub const RUSAGE_THREAD: c_int = 1; } pub mod posix08 { <ins> use types::os::arch::c95::c_int; pub const O_CLOEXEC: c_int = 0x80000; </ins> } #[cfg(any(target_arch = "arm", target_arch = "aarch64",

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:
} #[test] <ins> fn strslice_issue_104726() { // Edge-case in the simd_contains impl. // The first and last byte are the same so it backtracks by one byte // which aligns with the end of the string. Previously incorrect offset calculations // lead to out-of-bounds slicing. #[rustfmt::skip] let needle =                        "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaba"; let haystack = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab"; assert!(!haystack.contains(needle)); } #[test] </ins> #[cfg_attr(miri, ignore)] // Miri is too slow fn test_strslice_contains() { let x = "There are moments, Jeeves, when one asks oneself, 'Do trousers matter?'";

Discussion:
PR a x8664 SIMD-based implementation of to optimize searching into strings when the needle is at most 32 bytes long. Unfortunately, that implementation doesn't seem to be sound. When compiling the standard library with debug assertions on, running UI tests excluding results in compiletest itself panicking before executing any test due to a in libcore: To reproduce the issue, use the following configuration file: run: cc
Tentatively opened a revert PR in
Ugh. I ran it under miri with quite a combinatorial test that I thought should cover all the edge-cases. It's not immediately obvious what's wrong, so it's fine to land the revert for now.
Last I checked (and a lot has happened since then so I could be working on outdated info -- might be able to confirm), miri can't catch failure in many cases I believe, since it's "just" library UB.
the memory will be accessed after the get_unchecked so it should still be an invalid memory access when it's out of bounds. Unless I'm just doing some shortening slicing and then extending it again so that it's valid within the same allocation but not correct slicing.
What says is correct. The error here is in a situation like Miri (without Stacked Borrows) will not complain about that since the index is in-bounds of the allocation. But the debug assertion will complain since you are causing library UB by going out-of-bounds of the slice. I don't quite understand your last comment,
It seems like the test is just insufficient. Even with debug asserts and overflow checks enabled it doesn't catch it. I'll have to reproduce it first to figure out what's missing.
Ooh, I was getting absolutely unexplainable compiler errors when building stage 1 libstd with a stage 0 rustc which was built with however, could this be the cause for this? :sweat_smile:
Possible, but it would also do incorrect things on x86-64 baseline
has a proper fix
Change:
/// Returns `Some(t)` where `t` is the time `self + duration` if `t` can be represented as /// `SystemTime` (which means it's inside the bounds of the underlying data structure), `None` /// otherwise. <del> #[unstable(feature = "time_checked_add", issue = "55940")] </del> <ins> #[stable(feature = "time_checked_add", since = "1.34.0")] </ins> pub fn checked_add(&self, duration: Duration) -> Option<SystemTime> { <del> self.0.checked_add_duration(&duration).map(|t| SystemTime(t)) </del> <ins> self.0.checked_add_duration(&duration).map(SystemTime) </ins> } /// Returns `Some(t)` where `t` is the time `self - duration` if `t` can be represented as /// `SystemTime` (which means it's inside the bounds of the underlying data structure), `None` /// otherwise. <del> #[unstable(feature = "time_checked_add", issue = "55940")] </del> <ins> #[stable(feature = "time_checked_add", since = "1.34.0")] </ins> pub fn checked_sub(&self, duration: Duration) -> Option<SystemTime> { <del> self.0.checked_sub_duration(&duration).map(|t| SystemTime(t)) </del> <ins> self.0.checked_sub_duration(&duration).map(SystemTime) </ins> } }

Discussion:
This is a tracking issue for PR . This feature adds a function to and as a prerequisite also for all platform specific time structs. This also led to the refactoring of many functions to avoid redundancy (they now unwrap the result of ).
This should be to as well. We're seeing some need for this in to handle wait timeouts.
I pushed a PR () for adding the same functionality to under the same feature gate name. I hope this is fine. They seem extremely related (and share a lot of the implementation) and the feature name fits both.
This has now been extended so the feature covers both and on both and . Together with the fact that already have these, it's now possible to handle all time types without risking panics on nightly (whenever the next nightly comes out).
Covered by this feature: Looks good to me. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
Why no ?
The final comment period, with a disposition to merge, as per the , is now complete.
Implemented :
Could we not keep that as a separate feature? As to not slow this one down. No one reported they might have any need for when we developed and .
OK, renaming the feature in the pull request.
Change:
version = "0.1.0" dependencies = [ "byteorder", <del> "cargo_metadata", </del> <ins> "cargo_metadata 0.8.0", </ins> "colored", "compiletest_rs", "directories",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium. Removing I-nominated.
There is opening PR to fix this:
Change:
<ins> error: invalid comparison operator `===` --> $DIR/js-style-comparison-op.rs:3:10 | LL |     if 1 === 1 { |          ^^^ help: `===` is not a valid comparison operator, use `==` error: invalid comparison operator `!==` --> $DIR/js-style-comparison-op.rs:5:17 | LL |     } else if 1 !== 1 { |                 ^^^ help: `!==` is not a valid comparison operator, use `!=` error: aborting due to 2 previous errors </ins>

Discussion:
Been working in JavaScript a lot lately and find myself accidentally typing this a lot. It would be nice to automatically detect this and offer a proper fix. Lots of languages use this syntax in addition to JavaScript so it seems like a reasonable error to make. Playground example below. () Errors:
I think the current error message is clear enough. Also I don't think providing auto-fix suggestion is easy, because the error happened when parsing AST.
Nice. But I still think the current error message is fine as is.
don't disagree, but handling it was relatively easy because there's no case where would be valid.
Change:
<ins> // Test for ICE: cannot convert ReLateParam to a region vid // https://github.com/rust-lang/rust/issues/125873 #![feature(closure_lifetime_binder)] fn foo() { let a = for<'a> |b: &'a ()| -> &'a () { const { let awd = (); let _: &'a () = &awd; //~^ `awd` does not live long enough }; b }; } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: cannot convert to a region vid', 'error: internal compiler error: cannot convert to a region vid' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [mirborrowck] borrow-checking [mirborrowck] borrow-checking -- label +F-closurelifetimebinder +F-inline_const
another one from
Technically fixed by revert
Do we have a technical regression test?
Technically, I don't think so
Change:
<ins> // build-pass // compile-flags: -Zvalidate-mir // edition: 2021 #![crate_type = "lib"] // Use `PhantomData` to get target-independent size async fn get(_r: std::marker::PhantomData<&i32>) { loop {} } pub fn check() { let mut v = get(loop {}); let _ = || unsafe { v = std::mem::transmute([0_u8; 1]); }; } </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. --: Should be able to consistently trigger on Windows platform <details<summaryBacktrace</summary</details
I attempted to create a minimial reproduction based on the code I saw and was not able to get an ICE on the latest nightly (2023-04-09). Could you try updating to the latest nightly and see whether that fixed it? There have been a few issues with transmute that got fixed in the last few days.
This is fixed by
Change:
None } } <ins> /// Used by `format_args` when all arguments are gone after inlining, /// when using `&[]` would incorrectly allow for a bigger lifetime. /// /// This fails without format argument inlining, and that shouldn't be different /// when the argument is inlined: /// /// ```compile_fail,E0716 /// let f = format_args!("{}", "a"); /// println!("{f}"); /// ``` #[inline(always)] pub fn none() -> [Self; 0] { [] } </ins> } /// This struct represents the unsafety of constructing an `Arguments`.

Discussion:
Before , this gave an error: But after , that no longer gives an error. Ideally it shouldn't give an error in any case, but that's . Inlining/flattening format_args shouldn't change what compiles and what doesn't compile, so, for now, this still shouldn't compile.
Luckily the fix is easy. We just need to make sure that any with arguments still results in an expansion that involves borrowing a temporary.
Fix here:
Change:
To see the valid options and an example of use, run `rustc --print target-features`. <ins> Using this flag is unsafe and might result in [undefined runtime behavior](../targets/known-issues.md). </ins> ## passes This flag can be used to add extra LLVM passes to the compilation.

Discussion:
When discussing in the compiler team triage meeting, it became clear that target-features ought to be considered generally unsafe. We should document this fact in the and in the . Ideally, we'd also start listing out known gotchas. For example, in noted that: and had a . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Compiler triage meeting: Marking as P-medium
claim
The reference section about mentions this: The link to the section of the reference mentions this as well: So maybe the could point people to the reference?
That is one way in which targetfeature is unsafe, but it's not the one which was the subject of so just pointing at the reference as it is is insufficient. Plus, it's also more about than (where the compiler will hit you in the face with ). So the rustc book is a better place for it than the reference IMO.
I think that for users to better properly understand the UB involved, it might be more educational to say that stamps on all functions, but with the subtle difference that it doesn't make them , so no unsafe-check happens when this triggers UB. The reference does not document all current perils of using . In particular, it does not document that these can change the function call ABI, and that rustc neither checks that nor handles it correctly - we just currently assume people don't do that. Independently of whether we document that in the rustc book as well or not, that bit should also probably be documented in the reference, because it is easy to trigger this. On stable Rust, I think one can indeed only trigger this via and the reference should say so, but on nightly one can definitely trigger this with bare within a single Rust crate.
Change:
<del> use crate::spec::{cvs, DebuginfoKind, TargetOptions}; </del> <ins> use crate::spec::{cvs, TargetOptions}; </ins> pub fn opts() -> TargetOptions { let base = super::msvc_base::opts();

Discussion:
The UEFI targets (x8664-unknown-uefi, i686-unknown-uefi, and aarch64-unknown-uefi) started failing to compile in the latest nightly when using , failing with "LLVM ERROR: dwo only supported with ELF and Wasm". : : Build: searched nightlies: from nightly-2022-08-25 to nightly-2022-08-27 regressed nightly: nightly-2022-08-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsCC since bisect pointed to
Can confirm. Definitely needs to be looked into by the team — can you reproduce this?
I see in that is set in . I think that needs to be in , or maybe directly in ? I tested this out locally by using a custom target JSON that matches except adds , and that seems to fix the bug.
Change:
version = "0.1.0" authors = ["Alex Crichton <alex@alexcrichton.com>"] edition = "2018" <ins> autobins = false </ins> [dependencies] cargo_metadata = "0.11" regex = "1" lazy_static = "1" walkdir = "2" <ins> [[bin]] name = "rust-tidy" path = "src/main.rs" </ins>

Discussion:
After I see this spam in output: As I understand wants to run some third-party tool called (with ), but it actually runs the rustbuild's which doesn't support such command line use. (Also this expensive probing happens unconditionally when running any test, even it is not related to rustdoc.) Originally posted by in
I can't replicate this (specifically, confusing for ) on Linux. is on Windows and I think is too. Can you post what your PATH environment variable is?
Semicolons replaced with newlines for clarity: Interestingly a turns up nothing and attempting to run gives a not found as well. Is this something in the environment created by x.py?
This is indeed Windows only. This is the culprit: On windows, is : so PATH is expanded to include and . The strange thing is tidy isn't in either of those directories :confused: it's in (without ). Hopefully I can change this so that only commands that compiletest runs get this variable set, not compiletest itself. If not, maybe I could just rename the binary.
I think I figured it out. The tidy that's being run is in buildx86_64-pc-windows-msvcstage0-tools-bin, which is the same location as That's how it's finding a tidy without one being anywhere in PATH.
Change:
} struct Struct { <ins> //~^ NOTE while parsing this struct </ins> field!(bar:u128), //~^ NOTE macros cannot expand to struct fields //~| ERROR unexpected token: `!` //~| NOTE unexpected token after this a: u32, b: u32, <del> field!(recovers:()), //~ NOTE macros cannot expand to struct fields //~^ ERROR unexpected token: `!` //~^^ NOTE unexpected token after this </del> <ins> field!(recovers:()), </ins> } enum EnumVariant {

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
Regression in nightly-2023-08-05 Regression in cc
This is probably because it recovers from it and gives the field no name. We should probably give it the macro's name instead I believe this is the offending line:
An alternative approach would be to directly throw an error instead of allowing the parser to continue, imo.
label -needs-triage
Change:
assert::is_maybe_transmutable::<(), Void>(); //~ ERROR: cannot be safely transmuted } <ins> // Non-ZST uninhabited types are, nonetheless, uninhabited. fn yawning_void_enum() { enum Void {} enum YawningVoid { A(Void, u128), } const _: () = { assert!(std::mem::size_of::<YawningVoid>() == std::mem::size_of::<u128>()); // Just to be sure the above constant actually evaluated: assert!(false); //~ ERROR: evaluation of constant value failed }; // This transmutation is vacuously acceptable; since one cannot construct a // `Void`, unsoundness cannot directly arise from transmuting a void into // anything else. assert::is_maybe_transmutable::<YawningVoid, u128>(); assert::is_maybe_transmutable::<(), Void>(); //~ ERROR: cannot be safely transmuted } </ins> // References to uninhabited types are, logically, uninhabited, but for layout // purposes are not ZSTs, and aren't treated as uninhabited when they appear in // enum variants.

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking -- label +F-transmutability <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Ah, it's an uninhabited non-ZST!
claim
I guess that answers my ;)
Change:
Ok(()) } <ins> #[instrument(level = "debug", skip(infcx))] </ins> fn extract_spans_for_error_reporting<'a, 'tcx>( infcx: &infer::InferCtxt<'a, 'tcx>, terr: &TypeError<'_>,

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. --: Also get this using stable: You can see it on the playground: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can reproduce even without the type aliases: Edit: even smaller reproducer: Produces this output: () :
After some testing, this can be reproduced since 1.53, might have been introduced in
Change:
|                    help: missing comma here error: no rules expected the token `d` <del> --> $DIR/missing-comma.rs:21:18 </del> <ins> --> $DIR/missing-comma.rs:25: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.