jiebi/CodeConvo huggingface dataset:
Change:
&& self.inner.sin6_scope_id == other.inner.sin6_scope_id } } <del> #[stable(feature = "socketaddr_ordering", since = "1.45.0")] impl PartialEq<SocketAddrV4> for SocketAddr { fn eq(&self, other: &SocketAddrV4) -> bool { match self { SocketAddr::V4(v4) => v4 == other, SocketAddr::V6(_) => false, } } } #[stable(feature = "socketaddr_ordering", since = "1.45.0")] impl PartialEq<SocketAddrV6> for SocketAddr { fn eq(&self, other: &SocketAddrV6) -> bool { match self { SocketAddr::V4(_) => false, SocketAddr::V6(v6) => v6 == other, } } } #[stable(feature = "socketaddr_ordering", since = "1.45.0")] impl PartialEq<SocketAddr> for SocketAddrV4 { fn eq(&self, other: &SocketAddr) -> bool { match other { SocketAddr::V4(v4) => self == v4, SocketAddr::V6(_) => false, } } } #[stable(feature = "socketaddr_ordering", since = "1.45.0")] impl PartialEq<SocketAddr> for SocketAddrV6 { fn eq(&self, other: &SocketAddr) -> bool { match other { SocketAddr::V4(_) => false, SocketAddr::V6(v6) => self == v6, } } } </del> #[stable(feature = "rust1", since = "1.0.0")] impl Eq for SocketAddrV4 {} #[stable(feature = "rust1", since = "1.0.0")]

Discussion:
as a minimal example. Unclear whether this is a new trait impl or some regression elsewhere.
has been in 1.45 which would explain this:
There were roughly ~15-20 crates that failed in the crater run due to this, mostly in tests. I'm not sure whether we think that's sufficient reasoning to drop the impl, I get that it can be useful... cc (and relabeling as this is not an inference regression)
Can we add to the types? That would provide a path to patch the regression. Being able to easily compare a socketaddr to a string seems pretty valuable for testing, I'd rather see we make it easier than require the turbofish. for the PR that these impls
I’m not in favor since this would blur the difference between "this string does not parse as a valid socket address" v.s. "it does, but one not equal to that one". Code that doesn’t care about that difference can already use and compare strings.
mostly cared about PartialOrd and Ord impls (as you can tell from the PR title). Unlike PartialEq, none existed before on SocketAddr so they won't be problematic. I think the PR included new PartialEq impls only in support of heterogeneous PartialOrd (see ) which was ultimately removed from the PR anyway. I opened to revert the new PartialEq impls, leaving the PartialOrd and Ord impls from .
Change:
<ins> extern "C" { static X: i32; } static Y: i32 = 42; static mut BAR: *const &'static i32 = [&Y].as_ptr(); static mut FOO: *const &'static i32 = [unsafe { &X }].as_ptr(); fn main() {} // END RUST SOURCE // START rustc.FOO.PromoteTemps.before.mir // bb0: { // ... //     _5 = const Scalar(AllocId(1).0x0) : &i32; //     _4 = &(*_5); //     _3 = [move _4]; //     _2 = &_3; //     _1 = move _2 as &[&'static i32] (Pointer(Unsize)); //     _0 = const core::slice::<impl [&'static i32]>::as_ptr(move _1) -> [return: bb2, unwind: bb1]; // } // ... // bb2: { //     StorageDead(_5); //     StorageDead(_3); //     return; // } // END rustc.FOO.PromoteTemps.before.mir // START rustc.BAR.PromoteTemps.before.mir // bb0: { // ... //     _5 = const Scalar(AllocId(0).0x0) : &i32; //     _4 = &(*_5); //     _3 = [move _4]; //     _2 = &_3; //     _1 = move _2 as &[&'static i32] (Pointer(Unsize)); //     _0 = const core::slice::<impl [&'static i32]>::as_ptr(move _1) -> [return: bb2, unwind: bb1]; // } // ... // bb2: { //     StorageDead(_5); //     StorageDead(_3); //     return; // } // END rustc.BAR.PromoteTemps.before.mir // START rustc.BAR.PromoteTemps.after.mir // bb0: { // ... //     _2 = &(promoted[0]: [&'static i32; 1]); //     _1 = move _2 as &[&'static i32] (Pointer(Unsize)); //     _0 = const core::slice::<impl [&'static i32]>::as_ptr(move _1) -> [return: bb2, unwind: bb1]; // } // ... // bb2: { //     return; // } // END rustc.BAR.PromoteTemps.after.mir // START rustc.FOO.PromoteTemps.after.mir // bb0: { // ... //     _2 = &(promoted[0]: [&'static i32; 1]); //     _1 = move _2 as &[&'static i32] (Pointer(Unsize)); //     _0 = const core::slice::<impl [&'static i32]>::as_ptr(move _1) -> [return: bb2, unwind: bb1]; // } // ... // bb2: { //     return; // } // END rustc.FOO.PromoteTemps.after.mir </ins>

Discussion:
root: window - 2 (0 gh, 2 ) detected crates which regressed due to this <detailsbarg-0.2.0: v. window-0.3.0: v. </detailscc
:( is being used . The regression is caused by
Minimal repro: the MIR is The deallocates the array that the call gets a raw pointer to. That's where the dangling pointer error comes from. I guess we used to promote this array but due to the deref (since statics are now ) don't do this anymore
triage: P-high. (Has PR, yay.)
Change:
<ins> error[E0133]: pointer operation is unsafe and requires unsafe function or block --> $DIR/unsafe-unstable-const-fn.rs:9:5 | LL |     a == b |     ^^^^^^ pointer operation | = note: operations on pointers in constants error: aborting due to previous error For more information about this error, try `rustc --explain E0133`. </ins>

Discussion:
Some operations, such as raw pointer comparisons, require when inside a const context. To my knowledge, none of these operations have been const-stabilized. Accordingly, the fails to compile due to a missing unsafe block. However, the check does not run for functions. The following : This is an easy problem to fix, but the root cause here is poor naming. Specifically, should be renamed and should be . We have had other issues due to this in the past. cc to weigh in on the renaming.
Yeah I recall being confused by those names in the past, too. Definite :+1: for changing them. As for concrete proposals, I don't actually remember what these queries are doing, but your suggestions sound reasonable. :)
Oh, the names are different than in the email I got because you edited.^^ So does take the context (feature flags etc) into account? The name sounds like it would. What about , to make it a bit shorter?
Damn. I was hoping no one would catch me :smile:. would indeed take feature flags into account to mirror the current behavior of . I originally had , but that's not really correct, since it would also return if the function was unstable but the requisite feature flags were set.
Change:
<ins> // Copyright 2015 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. // // ignore-pretty mod issue_26873_multifile; fn main() {} </ins>

Discussion:
This code compiles: However, splitting the code into files causes compilation to fail: I am not sure whether or use is correct; regardless, replacing the latter with the former in produces a similar error:
cc
This appears to work now.
Change:
_ => unreachable!(), }; let asm_ty = match *ty.kind() { <del> ty::Never | ty::Error(_) => return None, </del> <ins> // `!` is allowed for input but not for output (issue #87802) ty::Never if is_input => return None, ty::Error(_) => return None, </ins> ty::Int(IntTy::I8) | ty::Uint(UintTy::U8) => Some(InlineAsmType::I8), ty::Int(IntTy::I16) | ty::Uint(UintTy::U16) => Some(InlineAsmType::I16), ty::Int(IntTy::I32) | ty::Uint(UintTy::U32) => Some(InlineAsmType::I32),

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Somewhere during compilation of this code, LLVM's ). Because of that, rustccodegenllvm::asm::inlineasmcall , and the parent function then .
I a statement to log the function type and constraints string passed to LLVM:
claim
Change:
} /// Returns whether any of the given keywords are `dist` tokens ahead of the current one. <del> fn is_keyword_ahead(&self, dist: usize, kws: &[Symbol]) -> bool { </del> <ins> pub(crate) fn is_keyword_ahead(&self, dist: usize, kws: &[Symbol]) -> bool { </ins> self.look_ahead(dist, |t| kws.iter().any(|&kw| t.is_keyword(kw))) }

Discussion:
Unmatched delimiters are hard to deal with by taking consideration of surrounding code because they actually occur during lexing. Still, it'd be nice if we detected some common sources of issues like this one. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
LL | use std::hash::Hasher; | <del> error: aborting due to previous error </del> <ins> error[E0599]: the method `as_ref` exists for reference `&dyn Bar`, but its trait bounds were not satisfied --> $DIR/import-trait-for-method-call.rs:15:7 | LL | trait Bar {} | --------- doesn't satisfy `dyn Bar: AsRef<_>` ... LL |     x.as_ref(); |       ^^^^^^ method cannot be called on `&dyn Bar` due to unsatisfied trait bounds | = note: the following trait bounds were not satisfied: `dyn Bar: AsRef<_>` which is required by `&dyn Bar: AsRef<_>` = help: items from traits can only be used if the trait is implemented and in scope = note: the following trait defines an item `as_ref`, perhaps you need to implement it: candidate #1: `AsRef` error: aborting due to 2 previous errors </ins> For more information about this error, try `rustc --explain E0599`.

Discussion:
Given the following code (): The output on is: <details<summaryLong diagnostic</summary</details, , , and are suggested three times each: once for , once for , and once for . I'm not sure if this is a problem, but this seems incredibly verbose to me. Note that the output on stable 1.51 and beta 1.52 is different:
My mistake, each repetition is actually different in that two suggest taking a reference to : This still seems like a fairly massive diagnostic, though. I've updated the original post in light of this. Feel free to close if a diagnostic of this size is fine here.
cc
Might be a duplicate of , or at least fixed by the same PR that fixed it
Even if it was considered reasonable to suggest each and every possible type combination, there is no pressing reason for it to generate the intervening lines as well: rustc is a compiler, not a can of spam. This remains unpatched on nightly, and is thus a stable-to-beta diagnostic regression.
AFAICT, this is not present on beta, and is only present on nightly, so it's a stable-to-nightly regression. Please correct me if I misunderstood!
searched nightlies: from nightly-2021-01-01 to nightly-2021-04-24 regressed nightly: nightly-2021-04-09 searched commits: from to regressed commit: That is: so it’s . I guess has already been mentioned. label D-verbose
Yes, yes, I introduced this regression. Mea culpa, everybody. In my defense I keep flip-flopping between being too restrictive and too permissive for new suggestions and someone always ends up getting the short end of the stick. This week, I'm leaning towards "too permissive" and if the suggestion triggers too often, then detect the cases and make it more constrained, because the alternative is that the suggestion isn't shown when it could, and we'll never find out. This is IMO better, as long as regressions are caught in nightly, like it was in this case.&lt;/rantAnyways, fixes this.
Assigning and removing .
This now affects 1.53.0 beta. Updating the labels accordingly.
Still needs to be backported.
the beta backport for patch was approved, can this now be closed?

I think we should wait until it actually lands onto beta
This was merged in beta already, right?
Ah, so it was.
Change:
walk_struct_field(self, s) } fn visit_enum_def(&mut self, enum_definition: &'v EnumDef, <del> generics: &'v Generics, item_id: NodeId) { </del> <ins> generics: &'v Generics, item_id: NodeId, _: Span) { </ins> walk_enum_def(self, enum_definition, generics, item_id) } fn visit_variant(&mut self, v: &'v Variant, g: &'v Generics, item_id: NodeId) {

Discussion:
Namely: + maybe So, if I want to visit, for example, a and report an error, I can't do it and have to visit all its parents instead.
Change:
<ins> error[E0277]: can't compare `Comparable` with `Comparable` --> $DIR/issue-34229.rs:2:46 | LL | #[derive(PartialEq, PartialOrd)] struct Nope(Comparable); |                                              ^^^^^^^^^^ no implementation for `Comparable < Comparable` and `Comparable > Comparable` | = help: the trait `std::cmp::PartialOrd` is not implemented for `Comparable` = note: required by `std::cmp::PartialOrd::partial_cmp` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
attempts to derive in an invalid situation, and is rewarded with a barrage of duplicate errors: The error only appears once. However, the error (along with note ... gee, really?) appears eight times, four for and four for . I assume this is because an error is generated at several points within the (invisible) generated implementation. But since they are all assigned the same span, maybe we can deduplicate.
Would the following be possible?: bound failure error true for the further compilation It doesn't address all cases, but it would significantly improve this one.
Should this be a UI or compile-fail test? I think cfail is out of favor these days, but a UI test will have to include a bug:
It should be a UI test, I'd say and we should fix that bug
Change:
if stage >= 1 { cargo.rustflag("-Cembed-bitcode=yes"); } <ins> if builder.config.rust_lto == RustcLto::Off { cargo.rustflag("-Clto=off"); } </ins> // By default, rustc does not include unwind tables unless they are required // for a particular target. They are not required by RISC-V targets, but

Discussion:
Currently bootstrap supports LTO flavors thin-local (default), thin and fat. Adding the option to completely disable it can speed up develop cycles, especially with incremental compilation. See for benchmarks. When LTO is disabled the standard library still has to be built with so that it can be used by other crates which enable LTO. Disabling should become the default for the library and compiler profile templates. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim to not loose it to time, but feel free to claim it if you want, I might not start work on this until February.
Error: Parsing assign command in failed: ...' claim' ' to not lo'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim Shouldn't this bot be able to detect end of command and silently ignore the rest of the line ?
Change:
<ins> error: argument 3 is required to be a constant --> $DIR/const_arg_promotable.rs:9:5 | LL |     _mm_clmulepi64_si128(a, b, *&mut 42) |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to
Change:
<ins> // check-pass // compile-flags: -Zextra-const-ub-checks #[derive(PartialEq, Eq, Copy, Clone)] #[repr(packed)] struct Foo { field: (i64, u32, u32, u32), } const FOO: Foo = Foo { field: (5, 6, 7, 8), }; fn main() { match FOO { Foo { field: (5, 6, 7, 8) } => {}, FOO => unreachable!(), _ => unreachable!(), } } </ins>

Discussion:
code from rustc this causes a new panic when executed via miri:
Ah, there was a reason why we disabled alignment checks in CTFE... This can probably be reproduced without Miri by passing -Zextra-const-ub-checks to rustc.
Yeah this just need "cargo miri run", no additional flags required. Edit: oops, misread :sweat_smile:
Right, this does also reproduce with . Do you want to move the issue?
Yeah let's move this to the rustc repo.
Change:
&& !imp.for_.is_assoc_ty() && !self.should_keep_impl(&i, did) { <del> debug!("ImplStripper: impl item for stripped type; removing"); </del> <ins> debug!("ImplStripper: impl item for stripped type; removing {imp:?}"); </ins> return None; } if let Some(did) = imp.trait_.as_ref().map(|t| t.def_id()) && !self.should_keep_impl(&i, did) { <del> debug!("ImplStripper: impl item for stripped trait; removing"); </del> <ins> debug!("ImplStripper: impl item for stripped trait; removing {imp:?}"); </ins> return None; } if let Some(generics) = imp.trait_.as_ref().and_then(|t| t.generics()) {

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 the documentation for the type alias to show the method and the implementation of . Instead, the type alias does not show the method . It does however show the implementation of . ! By publicly exposing through , the documentation of on the alias is documented as I expected, but then is publicly reachable, which in my case is unwanted due to being an internal implementation detail. This also works when making the statement , which gets the docs to look like I expected them to. ! <!-- 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. --: Thanks for helping me figure out why what I was expecting wasn't happening though it looked like it should.
I think it's ok to document an impl on a reexported if the reexported item is not doc hidden. I'll send a fix in the next weeks.
Change:
#[stable(feature = "rust1", since = "1.0.0")] #[inline] pub fn chunks_mut(&mut self, chunk_size: usize) -> ChunksMut<'_, T> { <del> assert!(chunk_size != 0); </del> <ins> assert_ne!(chunk_size, 0); </ins> ChunksMut { v: self, chunk_size } }

Discussion:
In the stdlib I'd like an iterator like chunksexact that yields fixed-sized arrays, using a const usize argument (mostly useful for short arrays). .chunksexactct::<3() .map( a + b + c) Those arrays could allow better optimizations and also better pattern matching. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This also applies to the method on slices.
We should actually be able to implement this and test it out unstably now.
Im willing to give this a shot in the weekend and next week!
assign
So, a simple PoC fails to compile horribly <details<summary<strongBacktrace</strong</summary<p</p</details
Notice that a freestanding function does work:
The more I go into this, the more obstacles I stumble upon. Below a list of all ICE's I encountered:
Keep going on, those bugs/limitations are worth fixing anyway :)
to_array() could be a new function related to take(), it collects the first N items of an iterator into an array of length given as const generic argument (it panics if the iterator isn't long enough). Usable like this (using iterate() from itertools):
EDIT: This is already PR'd:
We need a good built-in static_assert that works with constant generics too :)
Change:
cfg_doctest, cfg_eval, cfg_hide, <ins> cfg_overflow_checks, </ins> cfg_panic, cfg_sanitize, cfg_target_abi,

Discussion:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:
Change:
/// Returns a HashMap with the number of occurrences of every element in the /// sequence that the iterator exposes. <ins> #[cfg(not(stage0))] </ins> pub fn freq_count<T, U>(iter: T) -> hash_map::HashMap<U, uint> where T: Iterator<Item=U>, U: Eq + Clone + Hash {

Discussion:
Example: I left a FIXME at the relevant part of the code.
Nominating for something.
I can mentor...
I'm willing to have a look if the mentor offer stands
I already have a proposed fix, I just need to clean it up and add a test.
thanks for volunteering. The offer is still up but has been working on it. I'm happy to help with other bugs too.