jiebi/CodeConvo huggingface dataset:
Change:
fn read_link() { if cfg!(windows) { // directory symlink <del> assert_eq!( check!(fs::read_link(r"C:UsersAll Users")).to_str().unwrap(), r"C:ProgramData" ); </del> <ins> assert_eq!(check!(fs::read_link(r"C:UsersAll Users")), Path::new(r"C:ProgramData")); </ins> // junction <del> assert_eq!( check!(fs::read_link(r"C:UsersDefault User")).to_str().unwrap(), r"C:UsersDefault" ); </del> <ins> assert_eq!(check!(fs::read_link(r"C:UsersDefault User")), Path::new(r"C:UsersDefault")); </ins> // junction with special permissions <del> assert_eq!( check!(fs::read_link(r"C:Documents and Settings")).to_str().unwrap(), r"C:Users" ); </del> <ins> assert_eq!(check!(fs::read_link(r"C:Documents and Settings")), Path::new(r"C:Users")); </ins> } let tmpdir = tmpdir(); let link = tmpdir.join("link");

Discussion:
The failing assert is I don't know why my Windows is special in this way and the symlink contains the drive letter in lowercase, this version of Windows was pre-installed on an HP laptop. Anyway, the Rust test suite fails due to this easily fixable mismatch. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Other links in the test have the same lowercase issue:
It might not be a good idea to hardcode these paths in general. I'm not sure what the state of things is with windows 10 but with windows 7 it was at least possible to install on other drives than and so they might not even exist.
Whichever drive you install Windows on, they system drive will be labelled from within the running system. And certain directories must be on the system drive, e.g. the Windows and Users folders. However those folders could, potentially, be called something different. It's happened before with "Documents and Settings" being renamed "Users", hence the existence of all the symlinks being tested. That said, I think it's pretty unlikely to change again anytime soon. But it is possible. In any case the simple fix here is to compare s rather than ings.
claim
Change:
<del> Subproject commit 585a6eb3ebf7c40fd7c1b23e3ece557b3cc2aa36 </del> <ins> Subproject commit ea6fa9c2d43aaf0f11559719eda9b54d356d5416 </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. --When building with on nightly rust the resulting binary will segfault. This does not occur when built with stable rust. This behavior change appears to be gated by lto="thin". I tried this code: I expected to see this happen: alacritty to startup as occurs with Instead, this happened: compiled program segfaults stable-x8664-unknown-linux-gnu unchanged - rustc 1.68.2 ( 2023-03-27) nightly-x8664-unknown-linux-gnu unchanged - rustc 1.70.0-nightly ( 2023-04-11) : </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --This appears to be triggered by lto being set to "thin" in See alacritty issues: and for investigation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
NB This also appears to require that optimization is turned on to reproduce.
Hm fun, I can reproduce this with in alacritty git on x86
I tried to bisect this ` and t looks like this regressed in nightly-2023-03-26, so probably llvm upgrade? rip :(
WG-prioritization assigning priority (). label -I-prioritize +P-high
Upstream candidate patch: . Here is a reproduction example. If you change from to this will work fine.
claim
Change:
} WSAPOLLFD, *PWSAPOLLFD, *LPWSAPOLLFD; #endif <ins> #endif // _FIX_WINSOCK2_H </ins>

Discussion:
Latest mingw has broken headers () therefore missing definitions locally. This causes error on mingw-w64 since its header is not broken. :( cc
Quick fix is adding at . mingw-w64 doesn't define them, defines instead. I think we should prepare a plan when mingw also fixes it. (They already fixed third one of on w32api-4.0.3.) However, seems like mingw doesn't increment : both 4.0.0-1 and 4.0.3 have value .
mingw-w64 gets its' own section in , doesn't it? So adding mingw-fix-include to include path in can be conditioned on some macro defined there. As for mingw fixing their headers, I think we can just remove fixed headers from mingw-fix-include when that happens.
I'm building rust on mingw-w64-32bit but rust thinks it is on mingw. I'm not sure this is "legal", but I don't want to cross-build from mingw to mingw-w64-32bit since their difference is small.
has three mingw entries: i686-pc-mingw32 (normal mingw), i586-mingw32msvc (anyone who know this?), and x86_64-w64-mingw32 (mingw-w64 64bit). We don't have i686-w64-mingw32 (mingw-w64 32-bit). I don't know if it is good idea of adding it, so quick fix seems sufficient for now.
Change:
rt                                        rtstartup                                 rustllvm                                  <ins> rustc                                     </ins> snapshots.txt                             rust-installer                            rustbook                                 

Discussion:
Download and unpack: It should contain the same files as but it's missing the following directories: src/bootstrap, src/build_helper, src/rustc, src/grammar, etc. The files that are present in both cases are equal, so the tarball is only missing files. Perhaps a "whitelist" needs to be updated. cc
Change:
<ins> struct Foo<T>(T); trait GoodBye { type Forget; } impl<T> GoodBye for T { type Forget = (); } trait NeedsWf<'a, 'b> { type Assoc; } impl<'a, 'b> NeedsWf<'a, 'b> for Foo<<&'a &'b () as GoodBye>::Forget> { type Assoc = &'a &'b (); //~^ ERROR in type `&'a &'b ()`, reference has a longer lifetime than the data it references } fn needs_wf<'a, 'b, T: NeedsWf<'a, 'b>>() {} fn foo<'a: 'a, 'b: 'b>(_: &'b String) { needs_wf::<'a, 'b, Foo<()>>(); } fn main() { let x = String::from("hello"); foo::<'static, '_>(&x); } </ins>

Discussion:
this compiles with because we now assume unnormalized types in the impl header to be well formed when computing implied bounds. We don't check that when using the impl so we should be able to transmute lifetimes with this, though I haven't tried that yet. Going to fix that myself once I am back home in 2 weeks. cc
assigning after a very long and deep discussion in https://rust-
(FYI I also nominated PR for discussion at T-compiler meeting, essentially because of this associated issue; I hadn't seen that this was tagged as P-critical at that time. I'm leaving it nominated for now, just to ensure doubly that we discuss the matter.)
this is an existing issue on stable if we prevent the projection from normalizing in the impl while normalizing it when using the impl: that's the same issue as , which has been only fixed for function signatures edit: that's
Change:
<ins> // aux-build:issue-81839.rs // edition:2018 extern crate issue_81839; async fn test(ans: &str, num: i32, cx: &issue_81839::Test) -> u32 { match num { 1 => { cx.answer_str("hi"); } _ => cx.answer_str("hi"), //~ `match` arms have incompatible types } 1 } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --The code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- 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 --
This looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim
Change:
<ins> #[macro_export] macro_rules! m { () => { use issue_85992_extern_2::Outcome; } } </ins>

Discussion:
Exact code unknown code. The error was generated by using . Rerunning after did not fix this. Did not resolve this yet at the time of writing this. This might be related to: But I think this was because I compiles first and got this error: This was expected to give an error (needed to be ) <details<summary<strongFull backtrace on the fist check:</strong</summary<p</p</details: Problem persists after updating to last nightly: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace (After trying to recheck it)</strong</summary<p</p</details
I just found out the problem exists because of: If I comment out that line it will not report an internal error anymore. I had a function but I also use the crate  I now renamed the function but still getting errors. So it is likely because of a ambiguity issue. Trying to reproduce it in minimal code example, but not yet been able to do so.
After some testing a narrowed it down to the following: : : My guess why this fails: The macro uses inside of it. But when I try to export this it can not find it. commenting out/removing any line will give a normal compile error. I hope this helps to find out the problem. The error always happens and can thus be reliably reproduced. I tested this on latest nightly too:
reduced:
Hi can you assign it to me? I would like to give it a try and solve it.
Change:
let (expected_name, actual_name, output, actual) = self.run_common(); if output.is_empty() { <del> // If we can bless (meaning we have a file to write into and the `RUSTC_BLESS_TEST` // environment variable set), then we write into the file and return. if let Some(ref expected_file) = self.expected_file { if std::env::var("RUSTC_BLESS_TEST").is_ok() { println!("Blessing `{}`", expected_file.display()); fs::write(expected_file, actual); return; } </del> <ins> if self.maybe_bless_expected_file(&actual) { return; </ins> } panic!( "test failed: `{}` is not different from `{}`nn{}",

Discussion:
While working on , I noticed that running an test with appears to succeed, but doesn't actually update the snapshot file(s). This seems to be a side-effect of . The test does successfully bless the temporary copy of the snapshot file in , but that has no effect on the original snapshot file in .
cc label +A-run-make T-bootstrap
Change:
if matches!(c, Compatibility::Compatible) { Some(i) } else { None } }) .collect(); <del> if compat.len() != 1 { // this could go into multiple slots, don't bother exploring both </del> <ins> if compat.len() < 1 { // try to find a cycle even when this could go into multiple slots, see #101097 </ins> is_cycle = false; break; }

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: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.
Change:
Some(tcx) => tcx, None => return RegionBound(Lifetime::statik()) }; <del> let fqn = tcx.sess.cstore.item_path(self.def_id); let fqn = fqn.into_iter().map(|i| i.to_string()) .collect::<Vec<String>>(); let path = external_path(cx, fqn.last().unwrap(), </del> <ins> inline::record_extern_fqn(cx, self.def_id, TypeTrait); let path = external_path(cx, &tcx.item_name(self.def_id).as_str(), </ins> Some(self.def_id), vec![], self.substs); <del> cx.external_paths.borrow_mut().as_mut().unwrap().insert(self.def_id, (fqn, TypeTrait)); </del> debug!("ty::TraitRefn  substs.types(TypeSpace): {:?}n", self.substs.types.get_slice(ParamSpace::TypeSpace));

Discussion:
The [src] link on these pages is broken: The links are also broken in the stable docs version of these pages.
I think this should be fixed by . The links wrongly point to instead of because the crate is linked in std like
I've built the docs locally and the issue somehow persists.
Change:
if let Some(res) = res && let Some(def_id) = res.opt_def_id() && !def_id.is_local() <del> && self.r.session.crate_types().contains(&CrateType::ProcMacro) { </del> <ins> && self.r.session.crate_types().contains(&CrateType::ProcMacro) && 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:
y: Box<Vec<u8>>, } <ins> fn use_borrow<T>(_: &T) {} </ins> unsafe fn parent_sibling_borrow() { let mut u = U { x: ((Vec::new(), Vec::new()), Vec::new()) }; let a = &mut u.x.0; <del> let a = &u.y; //~ ERROR cannot borrow `u.y` </del> <ins> let b = &u.y; //~ ERROR cannot borrow `u.y` use_borrow(a); </ins> } unsafe fn parent_sibling_move() { let u = U { x: ((Vec::new(), Vec::new()), Vec::new()) }; let a = u.x.0; <del> let a = u.y; //~ ERROR use of moved value: `u.y` </del> <ins> let b = u.y; //~ ERROR use of moved value: `u.y` </ins> } unsafe fn grandparent_sibling_borrow() { let mut u = U { x: ((Vec::new(), Vec::new()), Vec::new()) }; let a = &mut (u.x.0).0; <del> let a = &u.y; //~ ERROR cannot borrow `u.y` </del> <ins> let b = &u.y; //~ ERROR cannot borrow `u.y` use_borrow(a); </ins> } unsafe fn grandparent_sibling_move() { let u = U { x: ((Vec::new(), Vec::new()), Vec::new()) }; let a = (u.x.0).0; <del> let a = u.y; //~ ERROR use of moved value: `u.y` </del> <ins> let b = u.y; //~ ERROR use of moved value: `u.y` </ins> } unsafe fn deref_sibling_borrow() { let mut u = U { y: Box::default() }; let a = &mut *u.y; <del> let a = &u.x; //~ ERROR cannot borrow `u` (via `u.x`) </del> <ins> let b = &u.x; //~ ERROR cannot borrow `u` (via `u.x`) use_borrow(a); </ins> } unsafe fn deref_sibling_move() { let u = U { x: ((Vec::new(), Vec::new()), Vec::new()) }; let a = *u.y; <del> let a = u.x; //~ ERROR use of moved value: `u.x` </del> <ins> let b = u.x; //~ ERROR use of moved value: `u.x` </ins> }

Discussion:
review comments:
I've looked into this some - NLL misses three errors, all of the form u.yu.x`. In each of the three cases, there is a mutable borrow of some field of the union and then a shared borrow of some other field immediately following. The issue seems to be that the mutable borrow is killed straight away as it isn't used later - therefore not causing a conflict with the shared borrow. I'm inclined to think that this is fine - and that NLL is correct in having less errors here. However, we might want to update the test to use the first mutable borrow for each case in order to make the error happen and demonstrate the diagnostic - if this is the case, I've that we can open a PR for that will update the test. cc
I'm inclined to agree that this is an instance where the test was not robust and that we need to add uses of those first mutable borrows.
I've submitted a PR () that makes the test more robust.
Change:
) -> Option<Discr<'tcx>> { match self.kind() { TyKind::Adt(adt, _) if adt.variants.is_empty() => { <del> bug!("discriminant_for_variant called on zero variant enum"); </del> <ins> // This can actually happen during CTFE, see // https://github.com/rust-lang/rust/issues/89765. None </ins> } TyKind::Adt(adt, _) if adt.is_enum() => { Some(adt.discriminant_for_variant(tcx, variant_index))

Discussion:
Interpreter calls on zero variant enum, when asked unsafely to do so :-). label: +requires-nightly +A-const-eval
cc
Ah, nasty unsafe code is nasty. ;) This reminds me of discussions I had with a while ago about the for 0-variant enums. Basically the bad code is like but is this really the only part of the compiler that assumes that for , we can use ?
FTR this is the layout of the empty enum: The fix could be to make return for 0-variant enums (treating them basically like any other type that does not actually have a discriminant) to add some logic in that avoids calling for 0-variant enums I haven't made up my mind yet about which one seems better... but I am leaning towards the first option.
As pointed out at , our codegen backend actually says that on any uninhabited type is UB. If we want to stick to that, this limits our options, at least for Miri (CTFE does not have to do all the same checks): pretty much the only clean solution I can think of is to require the place to contain data that satisfies the validity invariant. CTFE does not check validity invariants, so this does not clearly say what we should do there; we could still treat all types without discriminants the same (by returning 0).
In release mode returns an undef (look at llvm IR) even though from all docs it should be sound. At least as long as is sound, which I don't know if it has been decided yet.
I have not been able to weaponize it, but we should probably just make the codegen backend return 0
In my book is not sound, but indeed it has not been decided yet.
In , things look like we should properly check full validity of a value when reading its discriminant. However, that on its own cannot fix this ICE since the first thing validity checking will do is of course read the discriminant...
Change:
<ins> // Copyright 2018 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. // Tests for nested self-reference which caused a stack overflow. use std::fmt::Debug; use std::ops::*; fn gen() -> impl PartialOrd + PartialEq + Debug { } struct Bar {} trait Foo<T = Self> {} impl Foo for Bar {} fn foo() -> impl Foo { Bar {} } fn test_impl_ops() -> impl Add + Sub + Mul + Div { 1 } fn test_impl_assign_ops() -> impl AddAssign + SubAssign + MulAssign + DivAssign { 1 } fn main() {} </ins>

Discussion:
I guess this should be erroring with or E0666 (nested impl trait is not allowed).
Continues crashing in 1.26 stable.
This does not crash:
Particularly unfortunate because of and . <strikeWhat is going on here: There is a syntactical check to forbid nested impl Trait, but the default sneaks past that check, so we probably have to check for that substitution after lowering from HIR in type collection. Though it can also be done in the syntax check with some contortion.</strikeI was thinking that this shouldn't be allowed because it's like nested impl Trait, but is not at all like because the latter allows the inner type to be different from the outer one, while the former doesn't. So it might just be a case of fixing the overflow itself . I can take this myself but someone looking for mentorship or who is just faster is welcome.
Change:
///     unaligned: 0x01020304, /// }; /// <del> /// #[allow(unaligned_references)] /// let v = unsafe { ///     // Here we attempt to take the address of a 32-bit integer which is not aligned. ///     let unaligned = ///         // A temporary unaligned reference is created here which results in ///         // undefined behavior regardless of whether the reference is used or not. ///         &packed.unaligned ///         // Casting to a raw pointer doesn't help; the mistake already happened. ///         as *const u32; </del> <ins> /// // Take the address of a 32-bit integer which is not aligned. /// // In contrast to `&packed.unaligned as *const _`, this has no undefined behavior. /// let unaligned = std::ptr::addr_of!(packed.unaligned); </ins> /// <del> ///     let v = std::ptr::read_unaligned(unaligned); /// ///     v /// }; </del> <ins> /// let v = unsafe { std::ptr::read_unaligned(unaligned) }; /// assert_eq!(v, 0x01020304); </ins> /// ``` /// /// Accessing unaligned fields directly with e.g. `packed.unaligned` is safe however. <del> // FIXME: Update docs based on outcome of RFC #2582 and friends. </del> /// /// # Examples ///

Discussion:
Rust 1.51 was released yesterday and included the  macro. Its documentation talks about its usage in creating pointers to unaligned fields without the need for an intermediate reference: Despite that, the documentation of [] states the following: The documentation of [] should be updated to reflect the new changes in the language. : and modify labels: T-doc claim []: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Change:
} bb4: { <del> _10 = move ((_1 as Err).0: i32); </del> <ins> _10 = ((_1 as Err).0: i32); </ins> StorageLive(_11); _11 = Result::<Infallible, i32>::Err(_10); _2 = ControlFlow::<Result<Infallible, i32>, i32>::Break(move _11);

Discussion:
Right: Wrong: The first argument to is partially moved. GVN causes the second argument to use the partially moved value:
I can't provoke the miscompilation on beta using this example (just had to replace with to make it build), so I don't think there's any need to rush to fix this. (Some part of GVN is used in the beta that's about to become stable, but it looks like it doesn't have this bug in it)
Cc
WG-prioritization assigning priority (). label -I-prioritize +P-medium