jiebi/CodeConvo huggingface dataset:
Change:
hir::ExprKind::Match(ref discr, arms, _) => { let discr_place = return_if_err!(self.mc.cat_expr(discr)); <del> self.maybe_read_scrutinee( </del> <ins> return_if_err!(self.maybe_read_scrutinee( </ins> discr, discr_place.clone(), arms.iter().map(|arm| arm.pat), <del> ); </del> <ins> )); </ins> // treatment of the discriminant is handled while walking the arms. for arm in arms {

Discussion:
<details</summary</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. --:
I will try to reduce this to an MCVE.
Changing to appears to avoid the ICE, so that may be a useful place to focus.
Minimized it down to 60 lines without any dependencies. Maybe it can be minimized further but it's getting really hard. I've also left a few comments to say what's going on. <details<summary"Minimized" </summary</details
This appears to have regressed in Rust 1.64
This continues to ICE on beta and nightly
I bisected the regression, here is the output of : searched nightlies: from nightly-2022-06-24 to nightly-2022-08-05 regressed nightly: nightly-2022-07-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
Out of these seems the most likely, cc
Zooming onto changeset.
Found MVCE: <details<summaryOutput from Rust Playground</summary</details
Change:
pub const RUSAGE_CHILDREN: c_int = -1; pub const RUSAGE_THREAD: c_int = 1; } <ins> #[cfg(target_os = "freebsd")] </ins> pub mod posix08 { <ins> use types::os::arch::c95::c_int; pub const O_CLOEXEC: c_int = 0x100000; } #[cfg(target_os = "dragonfly")] pub mod posix08 { use types::os::arch::c95::c_int; pub const O_CLOEXEC: c_int = 0x20000; </ins> } pub mod bsd44 { use types::os::arch::c95::c_int;

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:
check_heap_item(cx, it); check_missing_doc_item(cx, it); check_attrs_usage(cx, it.attrs.as_slice()); <ins> check_raw_ptr_deriving(cx, it); </ins> cx.visit_ids(|v| v.visit_item(it, ()));

Discussion:
In the following, the does the wrong thing: it shallow copies the pointer when the semantics mean it should be making a new allocation and copying the data; there's no indication of this until runtime double-frees/segfaults. Some possible resolutions: do nothing: unsafe code is unsafe have lints for + unsafe pointers have completely disabled on unsafe pointers remove the trait impls for raw pointers
I favor a lint.
(I'm happy to mentor this.)
I'm interested in doing this. I'll find on IRC.
Change:
pub type LPSECURITY_ATTRIBUTES = *mut SECURITY_ATTRIBUTES; pub type LPSTARTUPINFO = *mut STARTUPINFO; pub type LPVOID = *mut c_void; <ins> pub type LPCVOID = *const c_void; </ins> pub type LPWCH = *mut WCHAR; pub type LPWIN32_FIND_DATAW = *mut WIN32_FIND_DATAW; pub type LPWSADATA = *mut WSADATA;

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. --Building std library (-Zbuild-std) with nightly for uwp-windows-msvc targets has been failing with compile errors since around after 17/10/22 I expected to see this happen: Last successeful build on 16/10: Instead, this happened: Lastest failed build: It most recently worked on: rustc 1.66.0-nightly ( 2022-10-14) : <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</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 --
Hey, is anyone looking into this because ALXR ci (uwp) builds are failing for over a week. Should this issue be posted in another repo?
This is the right repo, but it fell through the cracks for whatever reason. I can get to it this weekend.
Thank you :)
Oh, sorry I missed this! Since 10.0. console functions are available on UWP (see ). So I think the thing to do here is to simply stop making the function conditionally imported.
Change:
<ins> // run-rustfix pub struct Bytes; impl Bytes { pub fn as_slice(&self) -> &[u8] { todo!() } } impl PartialEq<[u8]> for Bytes { fn eq(&self, other: &[u8]) -> bool { self.as_slice() == other } } impl PartialEq<Bytes> for &[u8] { fn eq(&self, other: &Bytes) -> bool { *other == **self } } fn main() { let _ = &[0u8] == &[0xAA][..]; //~ ERROR can't compare `&[u8; 1]` with `[{integer}; 1]` } </ins>

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 (while debugging): Where is the corresponding type from the crate (and everything else is my types). It has an associated function , which returns a 16-byte slice containing the UUID. Because the right-hand-side of the comparison is not a byte slice but an array, the two expressions can't be compared and I get error E0277, shown below. Of interest is the help message at the end, which has the correct solution, but proposes a fix with invalid syntax. It should suggest placing before . <!-- 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. --: I could not test on nightly, as I got a different compile error, apparently related to procedural macros: <details<summaryError</summary<p</p</details
For the error, see . Could you try to bump your version? Also, could you maybe provide either the full code or a smaller reproduction of the suggestion (if possible), I can't seem to reproduce the suggestion for your pattern on stable.
Thanks for the notice. I just bumped to and retried on nightly: Unfortunately the exact same misleading help message still appears. I managed to reproduce it here: The import or argument is actually necessary to cause the bug. If you remove both, the help message doesn't appear. Perhaps this is related to the crate, which I noticed uses a type alias called (), unrelated to .
Smaller repro but still requires dependency: Am investigating how to get rid of the dependency.
Repro without dependencies:
Change:
self.check_attributes(&expr.attrs); self.collect_bang(mac, expr.span, AstFragmentKind::Expr).make_expr().into_inner() } else { <del> noop_visit_expr(&mut expr, self); </del> <ins> ensure_sufficient_stack(|| noop_visit_expr(&mut expr, self)); </ins> expr } });

Discussion:
First reported to me at I believe the stack overflow is in rustc itself. when compiled yields: where nightly today is:
Assigning as and removing .
It would be nice to bisect this one if possible ... ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-05-05 to nightly-2020-07-22 regressed nightly: nightly-2020-05-08 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
cc for anyone wanting to fix this, these kind of bugs are very easy to fix. You run rustc in until you get a stack overflow, then you look at the backtrace and look for recursion in there. Then you break the recursion overflow by inserting a use of at the recursive call site.
That sounds a good first bug to me. I'll give it a shot.
Change:
<ins> // check-pass #![feature(or_patterns)] fn main() { let 0 | (1 | _) = 0; if let 0 | (1 | 2) = 0 {} if let x @ 0 | x @ (1 | 2) = 0 {} } </ins>

Discussion:
This code is reduced from issue--unused-parens- :
Another variation on this to include in a regression test:
cc
Ah yeah, I see the issue. There's an implicit invariant that there should be no or-patterns directly in the first column of the matrix, but this invariant is broken exactly when an or-pattern has a child that is itself an or-pattern. I should have documented that. Specifically this fails to preserve the invariant: I don't expect to have the bandwidth to work on rustc in the foreseeable future sadly. I anyone wants to try, I believe the fix could be as simple as replacing in the above function with a loop that calls (and not ). That will ensure that we recursively expand or-patterns as needed instead of just expanding the first one.
Yep, that did it. Thanks for the pointer. This issue is fixed by
Change:
} } <del> fn make_drop_glue<'blk, 'tcx>(bcx: Block<'blk, 'tcx>, v0: ValueRef, g: DropGlueKind<'tcx>) </del> <ins> fn make_drop_glue<'blk, 'tcx>(bcx: Block<'blk, 'tcx>, v0: ValueRef, g: DropGlueKind<'tcx>) </ins> -> Block<'blk, 'tcx> { let t = g.ty();

Discussion:
The following successfully typechecks on , but generates an LLVM assertion failure: Error: Note that replacing with (and making mutable) allows compilation to succeed.
First occurs in nightly-2016-08-03 which turns on mir by default, does not occur on nightly-2016-08-03 with -Z orbit=off.
Using this was introduced between and ().
Problem seems to be that we call the with a fat pointer as 2 arguments, but it expects a pointer to a tuple.
I have a fix for this, running the full locally now to see if I broke anything else on the way.
Change:
F: FnMut(&T, &T) -> bool, { let len = v.len(); <del> // SAFETY: The unsafe operations below involves indexing without a bound check (`get_unchecked` and `get_unchecked_mut`) // and copying memory (`ptr::copy_nonoverlapping`). </del> <ins> // SAFETY: The unsafe operations below involves indexing without a bound check (by offsetting a // pointer) and copying memory (`ptr::copy_nonoverlapping`). </ins> // // a. Indexing: //  1. We checked the size of the array to >= 2.

Discussion:
Similar to I tried this code: I expected to see this happen: Miri does not detect UB Instead, this happened: Miri detects UB (experimentally) <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
cc
FWIW, I have now detected this bug through the tests in and .
Looks like the problem is in this line: re-borrows an on the entire slice, thus invalidation previously created pointers. So this is yet another instance of
Actually, just to be sure, are we interested in patching out all such instances of this in std/alloc/core? I know I personally would like the standard library to be clean against Miri with so that I can check libraries for stacked borrows issues. I just did a quick skim now that I understand the rules and I think I can spot a few other issues, so I'm not sure if these were deliberately left in, or if I'm just the first person to be looking this carefully.
So far we fixed various issues of this sort that people noticed, but there was never a concerted effort to find all of them. So they were not deliberately left in, just not found yet. Whether we want to fix them all is up to who ultimately decide about the std library implementation.
So far the fixes have been localized enough that it's been easy to take them (eg ). If anything comes up that requires drastic changes to fix then there might be a conversation about it, but for simple ones that don't increase maintenance burden I think they'll be happily accepted.
Change:
|    ---- required by a bound in this LL | where T : Convert<U> |           ^^^^^^^^^^ required by this bound in `test` <del> help: consider specifying the generic arguments | LL |     test::<i32, U>(22, std::default::Default::default()); |         ++++++++++ </del> help: consider specifying the type arguments in the function call | LL |     test::<T, U>(22, std::default::Default::default());

Discussion:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
exprs.len() ); <ins> // The following check fixes #88097, where the compiler erroneously // attempted to coerce a closure type to itself via a function pointer. if prev_ty == new_ty { return Ok(prev_ty); } </ins> // Special-case that coercion alone cannot handle: // Function items or non-capturing closures of differing IDs or InternalSubsts. let (a_sig, b_sig) = {

Discussion:
Given : The current output is: Ideally the code would compile successfully, but if that is infeasible, it would be nice if the diagnostic contained a hint to remove the . (It's rather head-scratching that the closure is being converted to a fn pointer even though the return type has also been resolved to be the closure type.) The is entirely unnecessary here, but I imagine a beginner might include it unthinkingly (as I did) and not be able to even guess that the has anything to do with the type error. The results are the same on stable 1.54.0, beta, and nightly. If I modify the closure to not be coercible to a function pointer by capturing a variable, then the code compiles without error or relevant warning: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label: +A-closures +A-inference
Interestingly, this compiles (note the semicolon): claim
Change:
self.into_inner().into_handle().into_raw() as *mut _ } } <ins> /// Windows-specific extensions to `std::process::ExitStatus` #[unstable(feature = "exit_status_from", issue = "32713")] pub trait ExitStatusExt { /// Creates a new `ExitStatus` from the raw underlying `u32` return value of /// a process. fn from_raw(raw: u32) -> Self; } #[stable(feature = "rust1", since = "1.0.0")] impl ExitStatusExt for process::ExitStatus { fn from_raw(raw: u32) -> Self { process::ExitStatus::from_inner(From::from(raw)) } } </ins>

Discussion:
Because has a private field it is impossible to create one in user code, one must actually execute a process. This prevents testing/mocking. My use case is that I have some function which runs a process and generates data, however, for testing I want to mock the test run and just return a success exit status and some data. I can't do that because I can't create my own objects. At the least there should be a way to create a success . Preferably, there would be a way to create various fail statuses too.
Should the constructor just take an ?
I've also wanted a basically "raw constructor" in the past. I'd be fine adding some extensions which allow construction from a or ( and )
+1 I’d like to extend , but I cannot reuse for return value because I can’t construct . :(
I've opened a PR for this over at
Great, thanks! :+1:
This would help n00bs like me who start out by copying the example code and tweaking it: This example is a special case that only happens to work if the contains a or something else that immediately exits. Otherwise you need to create your own struct to return which is currently impossible.
This issue is now entering a cycle-long final comment period for stabilization
Discussed recently, the libs team decided to stabilize.
Change:
fn build_controller(&mut self, sess: &Session) -> CompileController<'a> { let mut control = CompileController::basic(); <del> if sess.opts.parse_only || sess.opts.show_span.is_some() || </del> <ins> if sess.opts.parse_only || sess.opts.debugging_opts.show_span.is_some() || </ins> sess.opts.debugging_opts.ast_json_noexpand { control.after_parse.stop = Compilation::Stop; }

Discussion:
Not a breaking change since it is an unstable option.
Is it already an unstable option?
this issue is saying that should be changed to . It is already an unstable option.
So can accept as arguments. How would those be specified if were changed to a ?
Hopefully exactly the same way, not sure how possible that is. If it is not possible right now, then this probably isn't an easy issue to fix. I can look into it next week.
We've got kinda our own syntax for the flags so where today you pass it could instead be
Change:
bb8 (cleanup): { StorageDead(_10);                // scope 2 at $DIR/generator-storage-dead-unwind.rs:27:15: 27:16 StorageDead(_9);                 // scope 2 at $DIR/generator-storage-dead-unwind.rs:27:16: 27:17 <del> goto -> bb10;                    // scope 2 at $DIR/generator-storage-dead-unwind.rs:1:1: 1:1 </del> <ins> goto -> bb10;                    // scope 2 at no-location </ins> } bb9 (cleanup): { StorageDead(_8);                 // scope 2 at $DIR/generator-storage-dead-unwind.rs:26:15: 26:16 StorageDead(_7);                 // scope 2 at $DIR/generator-storage-dead-unwind.rs:26:16: 26:17 <del> goto -> bb10;                    // scope 2 at $DIR/generator-storage-dead-unwind.rs:1:1: 1:1 </del> <ins> goto -> bb10;                    // scope 2 at no-location </ins> } bb10 (cleanup): {

Discussion:
Sysroot has been compiled using to get set. Otherwise it is hard to guess a defid with encoded mir, now it is just taking the first exported symbol from:
I used to read the mir.
I think these are and printed as . If so it would be less confusing if the debug impl of would say or something like that instead.
I'm unsure how to reproduce the environment to reproduce this bug. It's easy to adjust the debug printing for , but without a test for that I'm not sure how to test it
Change:
<ins> error: could not find defining uses --> $DIR/issue-68621.rs:14:5 | LL |     type Future = impl Trait; |     ^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
When running in the subdirectory, a call to with causes the following ICE: I'm not exactly sure what additional information to provide? I filed an issue with , and was forwarded here since it is an ICE.
I've minimized it a bit: It still uses external crates but the example itself is very small.
compile it with: Although is behind a feature gate it will ICE without the feature gate! modify labels: F-typealiasimpltrait ICE code:
Change:
<ins> error[E0277]: the trait bound `String: Copy` is not satisfied --> $DIR/issue-119530-sugg-from-fn.rs:4:23 | LL |     let string_arr = [foo(); 64]; |                       ^^^^^ the trait `Copy` is not implemented for `String` | = note: the `Copy` trait is required because this value will be copied for each element of the array = help: consider using `core::array::from_fn` to initialize the array = help: see https://doc.rust-lang.org/stable/std/array/fn.from_fn.html# for more information error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
For this snippet (): rustc gives: Since , for const-able values, rustc suggests the creation of a constant binding. Here this is not possible because is not const fn. However, we can suggest instead.
Personally, I prefer over a separate binding. Even in the case, the generated code will call the initialization function many times. Maybe in the case where bindings are possible, we can suggest both? Where they are not possible, we don't suggest anything right now, so at the least we should suggest there. what do you think?
Once is stable we can suggest that :3. But until then sounds reasonable.
Agreed, good point about . It seems to have a stabilization PR open with an FCP, which is blocked: . Maybe there might be progress on it this month: . Even if we stabilize inline const, it might make sense to wait with suggesting it for a while so that we don't make code depend on the latest MSRV immediately. So therefore, I think that it might still make sense to implement this in the meantime.
I think this should (in the future) suggest  instead, since the function would only be called once if were , whereas calls it for every element.
Change:
("armv7r-none-eabi", armv7r_none_eabi), ("armv7r-none-eabihf", armv7r_none_eabihf), <del> ("x86_64-sun-solaris", x86_64_sun_solaris), </del> <ins> // `x86_64-pc-solaris` is an alias for `x86_64_sun_solaris` for backwards compatibility reasons. // (See <https://github.com/rust-lang/rust/issues/40531>.) ("x86_64-sun-solaris", "x86_64-pc-solaris", x86_64_sun_solaris), </ins> ("sparcv9-sun-solaris", sparcv9_sun_solaris), ("x86_64-pc-windows-gnu", x86_64_pc_windows_gnu),

Discussion:
There are actually two different generally expected encodings of the host tuple and they're subtly different than what some might expect. For example, 'x8664-sun-solaris' should probably be x8664-pc-solaris. The reason for that is that the encoding schemes are actually: So while 'sparcv9-sun-solaris' is correct because Sun is the (historical) manufacturer of sparc CPUs, 'x8664-sun-solaris' is not, because the MANUFACTURER here is the manufacturer of the CPU not the operating system. There are special cases for this, for example 'x8664-apple-darwin', even though Apple doesn't make x8664 CPUs, but following gcc/clang conventions leads us to x8664-pc-solaris. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
/cc /cc
An interesting discrepancy here is that our target and the LLVM target currently don't match. I'm not sure whether we can/should change anything here for backwards compatibility reasons, though an alias seems fine.
Hi, can I take this issue up? Can someone give a hint on how to fix this? I am a rust beginner, interested in compilers. This would be my first contribution.
as far as I can tell, you should just be able to add a new line under: containing , and then add a new line under: containing: (Sorry for the delay: I only just saw your message.)
claim
I wonder how it's supposed to work? Only x86_64-sun-solaris continues work for me: This change make it harder for Mozilla Firefox to decide which target to use...
I think we may have to introduce some changes in to make rustc try to use the alias. I.e. should try to use the target . I haven't had time to look into what else needs to be changed.
Closing as a duplicate of