jiebi/CodeConvo huggingface dataset:
Change:
<!-- 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 --
Regression in nightly-2022-08-16 commit[0] 2022-08-14: Auto merge of - GuillaumeGomez:merge-html-elements-together, r=notriddle commit[1] 2022-08-14: Auto merge of - matthiaskrgr:rollup-734hkpt, r=matthiaskrgr commit[2] 2022-08-15: Auto merge of - compiler-errors:as-a-treat, r=jackh726 commit[3] 2022-08-15: Auto merge of - austinabell:skip_optimization, r=Mark-Simulacrum commit[4] 2022-08-15: Auto merge of - ehuss:even-more-attribute-validation, r=cjgillot commit[5] 2022-08-15: Auto merge of - michaelwoerister:new-cpp-like-enum-debuginfo, r=wesleywiser commit[6] 2022-08-15: Auto merge of - matthiaskrgr:rollup-9450lzs, r=matthiaskrgr commit[7] 2022-08-15: Auto merge of - matthiaskrgr:rollup-f1zur58, r=matthiaskrgr
WG-prioritization assigning priority (). label -I-prioritize +P-medium
claim
Originates in PR . We are returning for although it does have an ident: The fix would be to start returning the ident. suffers from the same problem and may need the same treatment.

Discussion:
Node::Lifetime(lt) => Some(lt.ident), Node::GenericParam(p) => Some(p.name.ident()), Node::TypeBinding(b) => Some(b.ident), <ins> Node::PatField(f) => Some(f.ident), Node::ExprField(f) => Some(f.ident), </ins> Node::Param(..) | Node::AnonConst(..) | Node::ConstBlock(..)

| Node::Block(..) | Node::Ctor(..) | Node::Pat(..) <del> | Node::PatField(..) | Node::ExprField(..) </del> | Node::Arm(..) | Node::Local(..) | Node::Crate(..)

<ins> // Regression test for issue 115264 // Tests that retrieving the ident of the X::foo field // in main() does not cause an ICE // check-pass #[allow(dead_code)] struct X { foo: i32, } fn main() { let _ = X { #[doc(alias = "StructItem")] foo: 123, }; } </ins>

<ins> // Regression test for issue 115264 // Tests that retrieving the ident of 'foo' variable in // the pattern inside main() does not cause an ICE // check-pass struct X { foo: i32, } #[allow(unused_variables)] fn main() { let X { #[doc(alias = "StructItem")] foo } = X { foo: 123 }; } </ins>
Change:
<!-- 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 panic to be reported at line 2 Instead, it still was reported at line 7. I also tried. but this reported as an error in core I was able to work around the issue with code like this: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The core problem here is that is effectively part of the ABI, so when you have a function like , you'd have to somehow know whether it is trackcaller or not -- this would have to be to the type explicitly. Currently it is just never made track_caller. There's no easy fix here that I can see, this requires a language extension.
Oh looks like that language design work was already done: So on nightly, this works: The only piece missing is adding to , which is a trivial PR.
claim

Discussion:
/// assert_eq!(None.unwrap_or_else(|| 2 * k), 20); /// ``` #[inline] <ins> #[track_caller] </ins> #[stable(feature = "rust1", since = "1.0.0")] pub fn unwrap_or_else<F>(self, f: F) -> T where
Change:
Each of the above keywords gets marked with an "unnecessary" warning until the missing match arms are at which point the warnings disappear. This is confusing since many will see those warnings and remove the blocks only to need to re-add them when they finish writing their match. Originally reported on RA here: No response Any scenario where you have a match statement with necessary blocks in any of the arms, and the match statement is incomplete. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized: label -needs-triage +D-incorrect
No "unnecessary block" warning is emitted on 1.70 and before. label regression-from-stable-to-stable
Bisect: FYI
WG-prioritization assigning priority (). label -I-prioritize +P-medium
claim

Discussion:
// `mir_built` force this. let body = &tcx.mir_built(def).borrow(); <del> if body.is_custom_mir() { </del> <ins> if body.is_custom_mir() || body.tainted_by_errors.is_some() { </ins> return tcx.arena.alloc(UnsafetyCheckResult { violations: Vec::new(), used_unsafe_blocks: Default::default(),

<ins> // Regression test for #115348. unsafe fn uwu() {} // Tests that the false-positive warning "unnecessary `unsafe` block" // should not be reported, when the error "non-exhaustive patterns" // appears. fn foo(x: Option<u32>) { match x { //~^ ERROR non-exhaustive patterns: `None` not covered Some(_) => unsafe { uwu() }, } } fn main() {} </ins>

<ins> error[E0004]: non-exhaustive patterns: `None` not covered --> $DIR/issue-115348-false-positive-warning-of-unnecessary-unsafe.rs:10:11 | LL |     match x { |           ^ pattern `None` not covered | note: `Option<u32>` defined here --> $SRC_DIR/core/src/option.rs:LL:COL ::: $SRC_DIR/core/src/option.rs:LL:COL | = note: not covered = note: the matched value is of type `Option<u32>` help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown | LL ~         Some(_) => unsafe { uwu() }, LL ~         None => todo!(), | error: aborting due to previous error For more information about this error, try `rustc --explain E0004`. </ins>
Change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2023-08-29 Regression in cc

Discussion:
fn get_label_res(&self, id: NodeId) -> Option<NodeId>; fn get_lifetime_res(&self, id: NodeId) -> Option<LifetimeRes>; fn take_extra_lifetime_params(&mut self, id: NodeId) -> Vec<(Ident, NodeId, LifetimeRes)>; <ins> fn remap_extra_lifetime_params(&mut self, from: NodeId, to: NodeId); </ins> fn decl_macro_kind(&self, def_id: LocalDefId) -> MacroKind; }

self.extra_lifetime_params_map.remove(&id).unwrap_or_default() } <ins> fn remap_extra_lifetime_params(&mut self, from: NodeId, to: NodeId) { let lifetimes = self.extra_lifetime_params_map.remove(&from).unwrap_or_default(); self.extra_lifetime_params_map.insert(to, lifetimes); } </ins> fn decl_macro_kind(&self, def_id: LocalDefId) -> MacroKind { self.builtin_macro_kinds.get(&def_id).copied().unwrap_or(MacroKind::Bang) }

// constructing the HIR for `impl bounds...` and then lowering that. let impl_trait_node_id = self.next_node_id(); <ins> // Shift `impl Trait` lifetime captures from the associated type bound's // node id to the opaque node id, so that the opaque can actually use // these lifetime bounds. self.resolver .remap_extra_lifetime_params(constraint.id, impl_trait_node_id); </ins> self.with_dyn_type_scope(false, |this| { let node_id = this.next_node_id();

} }, AssocConstraintKind::Bound { ref bounds } => { <ins> self.record_lifetime_params_for_impl_trait(constraint.id); </ins> walk_list!(self, visit_param_bound, bounds, BoundKind::Bound); } }

<ins> // check-pass #![feature(associated_type_bounds, return_position_impl_trait_in_trait)] trait Trait { type Type; fn method(&self) -> impl Trait<Type: '_>; } impl Trait for () { type Type = (); fn method(&self) -> impl Trait<Type: '_> { () } } fn main() {} </ins>
Change:
I was checking if exposed  and found these seemingly non existent methods
It looks like the search results are present on (and after), but not on (or before)
Seems that's when std's hashbrown was upgraded to that the trait -

Discussion:
_ => self.cache.stripped_mod, }; <ins> #[inline] fn is_from_private_dep(tcx: TyCtxt<'_>, cache: &Cache, def_id: DefId) -> bool { let krate = def_id.krate; cache.masked_crates.contains(&krate) || tcx.is_private_dep(krate) } </ins> // If the impl is from a masked crate or references something from a // masked crate then remove it completely. if let clean::ImplItem(ref i) = *item.kind && (self.cache.masked_crates.contains(&item.item_id.krate()) || i.trait_ .as_ref() <del> .map_or(false, |t| self.cache.masked_crates.contains(&t.def_id().krate)) </del> <ins> .map_or(false, |t| is_from_private_dep(self.tcx, self.cache, t.def_id())) </ins> || i.for_ .def_id(self.cache) <del> .map_or(false, |d| self.cache.masked_crates.contains(&d.krate))) </del> <ins> .map_or(false, |d| is_from_private_dep(self.tcx, self.cache, d))) </ins> { return None; }

<ins> use std::borrow::Borrow; pub trait Equivalent<K: ?Sized> { fn equivalent(&self, key: &K) -> bool; } impl<Q: ?Sized, K: ?Sized> Equivalent<K> for Q where Q: Eq, K: Borrow<Q>, { fn equivalent(&self, key: &K) -> bool { PartialEq::eq(self, key.borrow()) } } </ins>

<ins> // exact-check // This test ensures that methods from blanket impls of not available foreign traits // don't show up in the search results. const EXPECTED = { 'query': 'equivalent', 'others': [], }; </ins>

<ins> // aux-crate:priv:equivalent=equivalent.rs // compile-flags: -Zunstable-options --extern equivalent // edition:2018 extern crate equivalent; #[derive(Clone, PartialEq, Eq, Debug)] pub struct LayoutError; </ins>
Change:
<!-- 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

Discussion:
// Finally we construct the actual value of the associated type. let term = match assoc_def.item.kind { ty::AssocKind::Type => tcx.type_of(assoc_def.item.def_id).map_bound(|ty| ty.into()), <del> ty::AssocKind::Const => bug!("associated const projection is not supported yet"), </del> <ins> ty::AssocKind::Const => { if tcx.features().associated_const_equality { bug!("associated const projection is not supported yet") } else { ty::EarlyBinder::bind( ty::Const::new_error_with_message( tcx, tcx.type_of(assoc_def.item.def_id).instantiate_identity(), DUMMY_SP, "associated const projection is not supported yet", ) .into(), ) } } </ins> ty::AssocKind::Fn => unreachable!("we should never project to a fn"), };

<ins> // compile-flags: -Ztrait-solver=next-coherence // Makes sure we don't ICE on associated const projection when the feature gate // is not enabled, since we should avoid encountering ICEs on stable if possible. trait Bar { const ASSOC: usize; } impl Bar for () { const ASSOC: usize = 1; } trait Foo {} impl Foo for () {} impl<T> Foo for T where T: Bar<ASSOC = 0> {} //~^ ERROR associated const equality is incomplete //~| ERROR conflicting implementations of trait `Foo` for type `()` fn main() {} </ins>

<ins> error[E0658]: associated const equality is incomplete --> $DIR/dont-ice-on-assoc-projection.rs:15:32 | LL | impl<T> Foo for T where T: Bar<ASSOC = 0> {} |                                ^^^^^^^^^ | = note: see issue #92827 <https://github.com/rust-lang/rust/issues/92827> for more information = help: add `#![feature(associated_const_equality)]` to the crate attributes to enable error[E0119]: conflicting implementations of trait `Foo` for type `()` --> $DIR/dont-ice-on-assoc-projection.rs:15:1 | LL | impl Foo for () {} | --------------- first implementation here LL | impl<T> Foo for T where T: Bar<ASSOC = 0> {} | ^^^^^^^^^^^^^^^^^ conflicting implementation for `()` error: aborting due to 2 previous errors Some errors have detailed explanations: E0119, E0658. For more information about an error, try `rustc --explain E0119`. </ins>
Change:
I was sent here from the . Please advise if I am posting in the wrong area. format! macro documentation could be improved by changing one of the examples to be more obvious to new users. Change the example to Additionally, assert! could be used to demonstrate final string values: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Something like ? claim
I think the use of "val" certainly makes it more obvious than my suggestion to use "z". Your suggestion would also do it in one line... I guess the question is whether you would prefer to make it more obvious (readable) by splitting it into two lines. This is my first contribution to Rust in any form, so I'm happy to go with your suggestion.
Thanks all!

Discussion:
/// /// A common use for `format!` is concatenation and interpolation of strings. /// The same convention is used with [`print!`] and [`write!`] macros, <del> /// depending on the intended destination of the string. </del> <ins> /// depending on the intended destination of the string; all these macros internally use [`format_args!`]. </ins> /// /// To convert a single value to a string, use the [`to_string`] method. This /// will use the [`Display`] formatting trait. /// <ins> /// To concatenate literals into a `&'static str`, use the [`concat!`] macro. /// </ins> /// [`print!`]: ../std/macro.print.html /// [`write!`]: core::write <ins> /// [`format_args!`]: core::format_args </ins> /// [`to_string`]: crate::string::ToString /// [`Display`]: core::fmt::Display <ins> /// [`concat!`]: core::concat </ins> /// /// # Panics ///

/// # Examples /// /// ``` <del> /// format!("test"); /// format!("hello {}", "world!"); /// format!("x = {}, y = {y}", 10, y = 30); </del> <ins> /// format!("test");                             // => "test" /// format!("hello {}", "world!");               // => "hello world!" /// format!("x = {}, y = {val}", 10, val = 30);  // => "x = 10, y = 30" </ins> /// let (x, y) = (1, 2); <del> /// format!("{x} + {y} = 3"); </del> <ins> /// format!("{x} + {y} = 3");                    // => "1 + 2 = 3" </ins> /// ``` #[macro_export] #[stable(feature = "rust1", since = "1.0.0")]

/// expression of type `&'static str` which represents all of the literals /// concatenated left-to-right. /// <del> /// Integer and floating point literals are stringified in order to be </del> <ins> /// Integer and floating point literals are [stringified](core::stringify) in order to be </ins> /// concatenated. /// /// # Examples
Change:
<!-- 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. --: This bug was also reproduced in the stable version(1.72) <!-- 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 --
claim
Hmm this was caused by cc
claim

Discussion:
// We errored. Signal that in the pattern, so that follow up errors can be silenced. let kind = PatKind::Error(e); return Box::new(Pat { span: self.span, ty: cv.ty(), kind }); <ins> } else if let ty::Adt(..) = cv.ty().kind() && matches!(cv, mir::Const::Val(..)) { // This branch is only entered when the current `cv` is `mir::Const::Val`. // This is because `mir::Const::ty` has already been handled by `Self::recur` // and the invalid types may be ignored. let err = TypeNotStructural { span: self.span, non_sm_ty }; let e = self.tcx().sess.emit_err(err); let kind = PatKind::Error(e); return Box::new(Pat { span: self.span, ty: cv.ty(), kind }); </ins> } else if !self.saw_const_match_lint.get() { if let Some(mir_structural_match_violation) = mir_structural_match_violation { match non_sm_ty.kind() {

<ins> const CONST_STRING: String = String::new(); fn main() { let empty_str = String::from(""); if let CONST_STRING = empty_str {} //~^ ERROR to use a constant of type `Vec<u8>` in a pattern, `Vec<u8>` must be annotated with `#[derive(PartialEq, Eq)]` } </ins>

<ins> error: to use a constant of type `Vec<u8>` in a pattern, `Vec<u8>` must be annotated with `#[derive(PartialEq, Eq)]` --> $DIR/issue-115599.rs:5:12 | LL |     if let CONST_STRING = empty_str {} |            ^^^^^^^^^^^^ | = note: the traits must be derived, manual `impl`s are not sufficient = note: see https://doc.rust-lang.org/stable/std/marker/trait.StructuralEq.html for details error: aborting due to previous error </ins>
Change:
On Apple Silicon (unlike x8664) is 16-bytes aligned. So it takes extra space with little or no benefit. I looked at generated code, it is the same: (Note just using won't work because it will pass by reference not by value) Additionally the issue with current is that is has different alignment on different platforms. Rust does not provide guarantees about the alignment, but if this was the same everywhere, it'd make life easier. (Practically we encountered this issue when our CI worked fine on Apple x8664 macs, but the program didn't work on Apple Silicon.) rustc 1.74.0-nightly ( 2023-09-05) macOS, Apple Silicon
Note that doesn't have the same alignment on all platforms either. It will be 4-aligned on (some) 32bit platforms.
I might be wrong here, but seems to work, so I believe is . So can't said problem be eliminated by implementing on as well?
already implements . Also does not affect alignment.
If that's the case, how about
That would make hashing and probably equality slower.
on 32 bit system would not be slower

Discussion:
#[derive(Clone, Copy, Debug, Eq, PartialOrd, Ord)] #[stable(feature = "rust1", since = "1.0.0")] pub struct TypeId { <del> t: u128, </del> <ins> // We avoid using `u128` because that imposes higher alignment requirements on many platforms. // See issue #115620 for more information. t: (u64, u64), </ins> } #[stable(feature = "rust1", since = "1.0.0")]

#[rustc_const_unstable(feature = "const_type_id", issue = "77125")] pub const fn of<T: ?Sized + 'static>() -> TypeId { let t: u128 = intrinsics::type_id::<T>(); <del> TypeId { t } </del> <ins> let t1 = (t >> 64) as u64; let t2 = t as u64; TypeId { t: (t1, t2) } </ins> } }

// - It is correct to do so -- only hashing a subset of `self` is still //   with an `Eq` implementation that considers the entire value, as //   ours does. <del> (self.t as u64).hash(state); </del> <ins> self.t.1.hash(state); </ins> } }
Change:
Minimized from : This issue was introduced in the build, and so it is likely to be a result of the upgrade to LLVM 17 ().
I have bisected the LLVM pass to the pass on main. I'm trying to get a diff of before/after so I can start tracking down the exact location of the incorrect optimization.
The optimization transforms this switch lookup which appears to correspond to the : with only the calculation of and changing from: to: with the rest of the IR remaining unchanged. The transform of appears to be okay ( by 64 -by 6). The transform of introduces the issue because although the instruction is marked as , is equal to which is negative in the signed representation and so subtracting 128 does cause signed underflow.
The IR output from rustc without any optimization passes outputs is: Which appears correct to me. This suggests that the is being introduced in a later optimization pass. I'll continue bisecting when I get a chance.
Looks like this instruction is being generated by a pass that's run before the pass. Before : Which is correct. So the real errant pass is , it just doesn't cause incorrect x86 to be emitted until a later pass.
Looks like this issue is known and a fix is in progress upstream at

Discussion:
[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/17.0-2023-07-29 </del> <ins> branch = rustc/17.0-2023-09-19 </ins> shallow = true [submodule "src/doc/embedded-book"] path = src/doc/embedded-book

<del> Subproject commit 0537f6354cffe546cbf47f6dc9c7f82e49e86cfb </del> <ins> Subproject commit 42263494d29febc26d3c1ebdaa7b63677573ec47 </ins>

<ins> // run-pass // compile-flags: -C opt-level=1 // Make sure LLVM does not miscompile this match. fn main() { enum Bits { None = 0x00, Low = 0x40, High = 0x80, Both = 0xC0, } let value = Box::new(0x40u8); let mut out = Box::new(0u8); let bits = match *value { 0x00 => Bits::None, 0x40 => Bits::Low, 0x80 => Bits::High, 0xC0 => Bits::Both, _ => return, }; match bits { Bits::None | Bits::Low => { *out = 1; } _ => (), } assert_eq!(*out, 1); } </ins>