jiebi/CodeConvo huggingface dataset:
Change:
impl<R: io::Read> io::Read for Maybe<R> { fn read(&mut self, buf: &mut [u8]) -> io::Result<usize> { match *self { <del> Maybe::Real(ref mut r) => handle_ebadf(r.read(buf), buf.len()), </del> <ins> Maybe::Real(ref mut r) => handle_ebadf(r.read(buf), 0), </ins> Maybe::Fake => Ok(0) } }

Discussion:
As , if one of the stdio handles for a Windows process is unset (e.g. isn't present) then you won't actually be able to spawn a process by default. All handles are set, by default, to "inherit", but duplicate the existing handle, which in turn means that if the stdio handle isn't present this operation will fail. Rust currently by always opening up handles even if is specified (just pointing them to a blank stream), but Rust should also defend against this situation when it was spawned from elsewhere.
cc
Change:
} /// Parses an optional `move` prefix to a closure-like construct. <del> fn parse_capture_clause(&mut self) -> CaptureBy { if self.eat_keyword(kw::Move) { CaptureBy::Value } else { CaptureBy::Ref } </del> <ins> fn parse_capture_clause(&mut self) -> PResult<'a, CaptureBy> { if self.eat_keyword(kw::Move) { // Check for `move async` and recover if self.check_keyword(kw::Async) { let move_async_span = self.token.span.with_lo(self.prev_token.span.data().lo); Err(self.incorrect_move_async_order_found(move_async_span)) } else { Ok(CaptureBy::Value) } } else { Ok(CaptureBy::Ref) } </ins> } /// Parses the `|arg, arg|` header of a closure.

Discussion:
I tried this code: This should give a suggestion to reorder the keywords to , something like: Right now it gives this error, which is not very helpful: Tested on 1.48.0 and 1.50.0-nightly (2020-12-03 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Releasing assignment as I'm not really sure how to fix this at the moment. release-assignment
This could be handled directly in the parser code which generates the above diagnostic.
claim
Change:
///     assert_eq!(rebuilt, [4, 5, 6]); /// } /// ``` <ins> /// /// Using memory that was allocated elsewhere: /// /// ```rust /// use std::alloc::{alloc, Layout}; /// /// fn main() { ///     let layout = Layout::array::<u32>(16).expect("overflow cannot happen"); ///     let vec = unsafe { ///         let mem = alloc(layout).cast::<u32>(); ///         if mem.is_null() { ///             return; ///         } /// ///         mem.write(1_000_000); /// ///         Vec::from_raw_parts(mem, 1, 16) ///     }; /// ///     assert_eq!(vec, &[1_000_000]); ///     assert_eq!(vec.capacity(), 16); /// } /// ``` </ins> #[inline] #[unstable(feature = "allocator_api", issue = "32838")] pub unsafe fn from_raw_parts_in(ptr: *mut T, length: usize, capacity: usize, alloc: A) -> Self {

Discussion:
has this to say about a better way to turn a into a : A strict reading, if I understand correctly, says that these two statements are contradictory. The documentation says that it is safe to create a and then use to create a out of its pointer. But the documentation says that, when creating a , must have previously been allocated via precisely and only , not for some other type —not even if happens to be transmutable from , not even if and are ABI-compatible, not only if is a wrapper around , but only itself. I suspect it was meant to say it must have previously been allocated by , not ; after all, if it could only have been allocated by in the first place, the next bullet point would be redundant (because obviously has the same alignment as ).
label A-docs
Relevant: looks like it will fix this if approved, by explicitly allowing allocation using something other than Vec<T(which can be a Vec<Uor even manual allocation)
Hm, that PR does remove the text I pointed out, but it also adds this text: Isn’t that equally problematic (albeit a slightly different but related problem, since it’s talking about the contents of the memory rather than its ), since it is actually fine for them to be properly initialized values of some other type that is suitably bytewise-compatible (for a proper choice of wording for “suitably compatible”) with but is not actually itself? Or does “properly initialized values of type ” actually also cover that (i.e. does it mean “bytes containing valid representations of ” and not “memory regions which have been constructed as s”?).
Rust doesn't have typed memory, types only have effect on accesses, so if some memory can be interpreted as some type T and it's valid at that type, it's a properly initialized value of type T. Nothing remembers the "original type" of some data. Just like how you can cast a to a and use them interchangeably. This is a safe operation if you use , too.
Change:
<ins> // Tests that `as` casts from enums to numeric types succeed // only if the enum type is "unit-only" or "fieldless" as // described here: https://doc.rust-lang.org/reference/items/enumerations.html#casting pub enum UnitOnly { Foo, Bar, Baz, } pub enum Fieldless { Tuple(), Struct{}, Unit, } pub enum NotUnitOnlyOrFieldless { Foo, Bar(u8), Baz } fn main() { let unit_only = UnitOnly::Foo; let _ = unit_only as isize; let _ = unit_only as i32; let _ = unit_only as usize; let _ = unit_only as u32; let fieldless = Fieldless::Struct{}; let _ = fieldless as isize; let _ = fieldless as i32; let _ = fieldless as usize; let _ = fieldless as u32; let not_unit_only_or_fieldless = NotUnitOnlyOrFieldless::Foo; let _ = not_unit_only_or_fieldless as isize; //~ ERROR non-primitive cast: `NotUnitOnlyOrFieldless` as `isize` let _ = not_unit_only_or_fieldless as i32; //~ ERROR non-primitive cast: `NotUnitOnlyOrFieldless` as `i32` let _ = not_unit_only_or_fieldless as usize; //~ ERROR non-primitive cast: `NotUnitOnlyOrFieldless` as `usize` let _ = not_unit_only_or_fieldless as u32; //~ ERROR non-primitive cast: `NotUnitOnlyOrFieldless` as `u32` } </ins>

Discussion:
Possibly link to the Rust Reference where this is explained in detail. Casting an enum to an int is common for C developers. When I searched the internet for guides on how to do this in Rust, they all essentially said it just works like . E.g. , . These guides don't explicitly say that this only works if all of the enum variants are unit-like. The compiler message in this situation did not help me to understand what had gone wrong, and googling for it and "enum" returned the same sort of results as mentioned above. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label D-newcomer-roadblock D-confusing
claim
Change:
basic_coverage_blocks, ); <ins> if coverage_spans.is_empty() { return None; } </ins> // Group the coverage spans by BCB, with the BCBs in sorted order. let mut bcb_to_spans = IndexVec::from_elem_n(Vec::new(), basic_coverage_blocks.num_nodes()); for CoverageSpan { bcb, span, .. } in coverage_spans { bcb_to_spans[bcb].push(span); } <del> Self { bcb_to_spans } </del> <ins> Some(Self { bcb_to_spans }) </ins> } pub(super) fn bcb_has_coverage_spans(&self, bcb: BasicCoverageBlock) -> bool {

Discussion:
The immediate symptoms of were fixed by , but some users reported that their builds now encounter another coverage-related ICE:
label +T-compiler +A-code-coverage
This ICE does not occur on current stable/beta, but does occur on nightly. label +regression-from-stable-to-nightly
(This will be fixed by , which is awaiting review.)
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
<del> Subproject commit b3e2a6e6c8a3aae5b5d950c63046f23bae07096d </del> <ins> Subproject commit 7352353ae91c48b136d2ca7d03822e1448165e1e </ins>

Discussion:
Compile the above (faulty) code with gives me this:
Probably related to .
Thanks for the information! Close this one.
Change:
<ins> // check-pass // #81395: Fix ICE when recursing into Deref target only differing in type args pub struct Generic<T>(T); impl<'a> std::ops::Deref for Generic<&'a mut ()> { type Target = Generic<&'a ()>; fn deref(&self) -> &Self::Target { unimplemented!() } } impl<'a> Generic<&'a ()> { pub fn some_method(&self) {} } </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. --Original: Minimized: <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
When running with , the last few lines before the panic are: seems relevant since it has a impl:
Minimized: rust pub struct Generic<T(T); impl<'astd::ops::Deref for Generic<&'a mut (){ type Target = Generic<&'a (); fn deref(&self) -&Self::Target { unimplemented!() } } impl<'aGeneric<&'a (){ pub fn some_method(&self) {} }
searched nightlies: from nightly-2020-11-12 to nightly-2021-01-17 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed in . label regression-from-stable-to-nightly
cc - do you have time to figure out what's going wrong here?
Yes, I believe so, I'll see what I can do here. claim
Please ping me once you open the PR ( is taking a break :) )
The core issue is the recursion cycle handling... It focuses only on s and wasn't anticipating targets that differ only in generic type args. I believe I see the tweak we'll need here, so I should have a PR in the next day or so.
Change:
// run-fail <del> // error-pattern:assertion failed: `(left matches right)` // error-pattern: left: `2` // error-pattern:right: `3`: 1 + 1 definitely should be 3 </del> <ins> // error-pattern:assertion `left matches right` failed: 1 + 1 definitely should be 3 // error-pattern:  left: 2 // error-pattern: right: 3 </ins> // ignore-emscripten no processes #![feature(assert_matches)]

Discussion:
The custom message in macro is shown right after the . This is hard to read because the value strings could be very long. I think it is better to print the custom message (if available) on a separate line. The above (playground) prints this: Note that custom message and the location in source are still on the same line <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I will try it. claim
Note that the linked PR, , has a lot of review comments. I think rebasing that PR and addressing the comments would already be very close to landing this change.
(taking over due to inactivity) claim
:tada: Horray! It only took 548 days (1.5+ years) since I created on Feb 14th, 2022. Numerous commits. Tens of people. 4 PRs... 100s of files. All to change a few lines of output :) Special thanks to for all the support!
Change:
when returning from a function. This is also known as “Stack Protector” or “Stack Smashing Protector (SSP)”. <del> The Rust compiler does not support stack smashing protection. However, more comprehensive alternatives to stack smashing protection exist, such as shadow and safe stack (see backward-edge control flow protection). </del> <ins> The Rust compiler supports stack smashing protection on nightly builds[42]. </ins> ![Screenshot of IDA Pro listing cross references to __stack_chk_fail in hello-rust.](images/image3.png "Cross references to __stack_chk_fail in hello-rust.") Fig. 14. IDA Pro listing cross references to `__stack_chk_fail` in hello-rust. To check if stack smashing protection is enabled for a given binary, search <del> for cross references to `__stack_chk_fail`. The only cross references to `__stack_chk_fail` in hello-rust are from the statically-linked libbacktrace library (see Fig. 14). </del> <ins> for cross references to `__stack_chk_fail`. The presence of these cross-references in Rust-compiled code (e.g., `hello_rust::main`) indicates that the stack smashing protection is enabled (see Fig. 14). </ins> ### Forward-edge control flow protection

Discussion:
Stack smashing protection was in , but  was never updated. label A-docs
Have you started on this already? I'm available to take this on. I came across the docs before the PR, and was misled about the current state of this feature.
Not yet. Sorry about the confusion caused by it. If you'd have time to and would like to contribute, it'd be much appreciated. Feel free to CC me in the PR and I'd be happy to help reviewing it.
Change:
} #[inline] <del> pub fn mk_lang_item(self, ty: Ty<'tcx>, item: lang_items::LangItem)  -> Ty<'tcx> { let def_id = self.require_lang_item(item, None); self.mk_generic_adt(def_id, ty) </del> <ins> pub fn mk_lang_item(self, ty: Ty<'tcx>, item: lang_items::LangItem)  -> Option<Ty<'tcx>> { let def_id = self.lang_items().require(item).ok()?; Some(self.mk_generic_adt(def_id, ty)) </ins> } #[inline]

Discussion:
Test Program: Error message on nightly [ 2019-09-02] and before: Error message since nightly [ 2019-09-03]: Diff Between the Nightlies: Reported by and in
I'm testing this with regression in Maybe cause it
cc -- I think we need to be more graceful by checking if liballoc exists or not or not requiring the language items.
PR show more suggestions on method take ,, or when method not found However, , and don't exist in , but in . Error message of this code:
Mentoring instructions: Change to return and use instead of .Make take in and call instead and return early . Also be sure to not use .Include tests like above and make sure to check for Box, Rc, and Arc.Use to update the tests.
Change:
(c, b | d) } <ins> /// Computes the absolute difference between `self` and `other`. /// /// # Examples /// /// Basic usage: /// /// ``` /// #![feature(int_abs_diff)] #[doc = concat!("assert_eq!(100", stringify!($SelfT), ".abs_diff(80), 20", stringify!($SelfT), ");")] #[doc = concat!("assert_eq!(100", stringify!($SelfT), ".abs_diff(110), 10", stringify!($SelfT), ");")] /// ``` #[unstable(feature = "int_abs_diff", issue = "89492")] #[inline] pub const fn abs_diff(self, other: Self) -> Self { if mem::size_of::<Self>() == 1 { // Trick LLVM into generating the psadbw instruction when SSE2 // is available and this function is autovectorized for u8's. (self as i32).wrapping_sub(other as i32).abs() as Self } else { if self < other { other - self } else { self - other } } } </ins> /// Calculates the multiplication of `self` and `rhs`. /// /// Returns a tuple of the multiplication along with a boolean

Discussion:
See discussion in
I suggest not calling it due to the confusion created by the (terribly misnamed) , whose tortured legacy continues to this day in .
perhaps?
abs_difference ?
What do you think about adding: instead of doing it on just the unsigned integer types?
is a good name, I think, as it is the mathematical term for . I dislike above generalization, as what it does is unrelated with the name of the function in most cases (the first thing that comes to mind is that something called an « absolute difference » should be a non-negative real number).
The term seems too generic from the standpoint of a mathematical motivation, it is also used in the context of very different metric spaces than the normed space induced by the L1-norm. I think 'absolute difference' hits the nail on the head and with the given prior art of abbreviations that would make my clear favorite. Similar to , and other functions it doesn't seem necessary to add it in another way than as a method.
Until that happens, I've found the easiest way to do this is:
If no one has any objections I can make a pull request implementing the following functions: where for unsigned types the implementation would be and for signed types Especially the latter is a useful contribution as it is somewhat non-trivial and tricky to write correctly as a user, if you are not intimately familiar with two's complement.
Just sharing some experience from the wild: I have code of the form where I check before I call , because I need a different code path for that case versus the case. However, that check is repeated within the impl, so I was wondering whether I should write out the manually. But, it when the compiler decides to inline , it is smart enough to collapse the statements into one. So I think using vanilla is fine for my case. Thanks for adding it!
Change:
let substituted = self.erase_regions(&substituted); AssociatedTypeNormalizer::new(self).fold(&substituted) } <ins> pub fn trans_apply_param_substs_env<T>( self, param_substs: &Substs<'tcx>, param_env: ty::ParamEnv<'tcx>, value: &T, ) -> T where T: TransNormalize<'tcx>, { debug!( "apply_param_substs_env(param_substs={:?}, value={:?}, param_env={:?})", param_substs, value, param_env, ); let substituted = value.subst(self, param_substs); let substituted = self.erase_regions(&substituted); AssociatedTypeNormalizerEnv::new(self, param_env).fold(&substituted) } </ins> } struct AssociatedTypeNormalizer<'a, 'gcx: 'a> {

Discussion:
Compiling v0.2.10 and v0.4.4 with , I get the following ICEs:
reproduction:
Change:
<ins> // check-pass fn any<T>() -> T { loop {} } trait Foo { type V; } trait Callback<T: Foo>: Fn(&T, &T::V) {} impl<T: Foo, F: Fn(&T, &T::V)> Callback<T> for F {} struct Bar<T: Foo> { callback: Box<dyn Callback<T>>, } impl<T: Foo> Bar<T> { fn event(&self) { (self.callback)(any(), any()); } } struct A; struct B; impl Foo for A { type V = B; } fn main() { let foo = Bar::<A> { callback: Box::new(|_: &A, _: &B| ()) }; foo.event(); } </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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pthe backtrace itself is all </p</details
It's strange, I tried these code in main and it complains about (Compile Error but not ICE) I think the trait is depends on and dyn could resolve this.
Assigning and removing nomination. This was . This one also sounds a bit similar to and which is very old. Would be nice to find if there are duplicates too.
Pinging cleanup to find duplicates ... 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
Triage: It's no longer ICE with the latest nightly, I think it's fixed by .

Discovered a compiler panic, thought it might relate to , but was told to post a new issue. In minimizing, it seems the generic types are required to trigger the panic, I was unable to reproduce when inlining t7p or t8n. This code panics on 1.33 - 1.35, but does not panic on 1.32 (): On 1.32: On 1.35 nightly: --Bryan
triage: P-high. Removing nominated tag since there's little to discuss beyond its P-highness. (The fact its unassigned will be discussed regardless of nomination state.)
Bisection points to i.e. as the culprit. The backtrace in that commit looks very similar to the one reported here, and the parent commit () gives the same compiler error.
I spent some time looking at this a few weeks ago but did not manage to find anything conclusive. At this point I'm going to be taking a break for a few months, so I am unassigning myself from this issue.
triage: assigning self.
triage: downgrading to P-medium; this does not warrant revisiting every week.
I was able to minify it a bit further:
Triage: It's no longer ICE with the latest nightly.

The following example ICEs yields (Same is true on stable.)
That's because the ObjectCandidate code is not normalizing the upcast trait refs. Should we wait for Chalk for the fix?
Hitting this error, any updates?
Triage: no longer ICEs.
It's still an ICE, note that we should build/run the snippet to check it ().
Triage: It's no longer ICE with the latest nightly, I think it's fixed by .
Change:
<del> Subproject commit 9168e236c548d1d0e9938ee6dd4cdbd308fdfd72 </del> <ins> Subproject commit fd336816c3a6d228dcef22171c43140f6fa7656f </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. --Haven't minimized it yet, so I won't upload for now <!-- 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. --: Coredump info <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
ping llvm
Hey LLVM ICE-breakers! This bug has been identified as a good "LLVM 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
Did that coredump link expire? I get 404...
It must have, I'll reupload it: (I think this one's once use? I can't find very good sites) If Rust recommends a specific site for temporary file uploads, I'm happy to upload it to that too Edit: uploaded to too (30 days)
Hmm, I downloaded it, but my local GDB doesn't make any sense of it without all of the mapped modules, it seems. It's not even enough to have just the matching toolchain at the right path. But I did manage to line up the offsets myself to find it in the disassembly -- it's this : and that value is zero, at least in the current state of the coredump. That came from the entry , which I think is the parameter, but it may have been modified: I'm not sure whether that is build-conditional. This LLVM library is also the product of LTO itself, so we could be looking at a meta-miscompilation here... <details<summaryFull assembly of that function</summary<p</p</details
It is, our non-alt builds don't enable assertions. For this kind of issue, a particularly minimal reproducer is not needed, just anything that is publicly sharable will do.

Here's the reproducer (I minimized it a bit by removing some modules/deps, but it's otherwise as is, new coredump is attached inside zip for debugging purposes)
Thanks, I can reproduce the crash with on with current LLVM HEAD.
Reduction for :
Change:
version = "1.39.0" dependencies = [ "cargo", <del> "cargo_metadata", </del> <ins> "cargo_metadata 0.8.0", </ins> "clippy_lints", "crossbeam-channel", "difference",

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: