jiebi/CodeConvo huggingface dataset:
Change:
Since was merged, the std test fails with the following error on windows7: After some further instrumentation, I was able to find out the source of the problem: . This was likely caused by , which reworked the backtracing code on windows to be faster through the use of newer APIs. Unfortunately, not all of those APIs are available in Windows 7. modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc is going to land in 1.75 while drops windows <10 support from 1.76. Though to be clear windows 7 is not particularly well supported today, CI only tests windows 10.
While this manifests as a test error, I'm pretty sure there's an actual regression here that can be observed in code, and isn't just a unit test failure. I haven't taken the time to make an actual reproducer, but I think any attempt to print a through its implementation will fail. I'll try to make some code showing the regression tomorrow. Regarding windows7 being not well-supported, I'm well-aware of that. I'm trying to improve on this by running the library/std tests on windows7 every night on some (private) infrastructure, and eventually adding a new (tier3) windows7 target once support is officially dropped in 1.76 so we can continue targeting it.
I agree this is likely a regression, and pinged the author: it’s likely the fact that the PR will not work on windows 7 wasn’t known then, but at the same time it seems it could be accepted if it landed today. It’s likely the panic could be resolved though, or some of the old code brought back for the new tier3 target.
Just to be sure I understand: Do I read correctly that due to the absence of some APIs, the issue won't reproduce on Win10? WG-prioritization assigning priority (). label -I-prioritize +P-low
That is correct, the missing APIs were in version 6.2, which I believe comes built into Windows 8+. At least win10 has it for sure.
I just realized this actually affects the 1.75 beta branch as well, this is a regression from stable to beta.
Once the backtrace PR is merged another PR updating the crate can be merged here with the label.

Discussion:
<del> Subproject commit e9da96eb452aa65e79e2342be700544afe509440 </del> <ins> Subproject commit 6145fe6bac65c38375f1216a565a6cc7deb89a2d </ins>
Change:
This code, as expected, triggers the lint. This is the compiler output: Applying the suggested change, we then get a lifetime error. In this specific instance, must also be changed to . That'll then trigger the lint on , with no ensuing issues. I have not checked this, but I my suspicion is any place where a lifetime bound is also present in the return type (or possibly even a parameter) will result in a similar failure to compile the suggested code. Figuring out which lifetimes to suggest removal of in other parts of the function signature probably isn't straightforward. This example is not theoretical, unfortunately. I ran into this in real-world code and it caused me quite a bit of time to figure out. The example is the minimal reproduction of the bad suggestion.
Should the lint even trigger for ? It's only "used" once directly, but it's also linked to another lifetime through the bound .
cc label +F-lint-singleuselifetimes

Discussion:
debug!(?param.ident, ?param.ident.span, ?use_span); let elidable = matches!(use_ctxt, LifetimeCtxt::Ref); <ins> let deletion_span = if param.bounds.is_empty() { deletion_span() } else { None }; </ins> <del> let deletion_span = deletion_span(); </del> self.r.lint_buffer.buffer_lint_with_diagnostic( lint::builtin::SINGLE_USE_LIFETIMES, param.id,

<ins> #![deny(single_use_lifetimes)] pub enum Data<'a> { Borrowed(&'a str), Owned(String), } impl<'a> Data<'a> { pub fn get<'b: 'a>(&'b self) -> &'a str { //~^ ERROR lifetime parameter `'b` only used once match &self { Self::Borrowed(val) => val, Self::Owned(val) => &val, } } } fn main() {} </ins>

<ins> error: lifetime parameter `'b` only used once --> $DIR/issue-117965.rs:9:16 | LL |     pub fn get<'b: 'a>(&'b self) -> &'a str { |                ^^       -- ...is used only here |                | |                this lifetime... | note: the lint level is defined here --> $DIR/issue-117965.rs:1:9 | LL | #![deny(single_use_lifetimes)] |         ^^^^^^^^^^^^^^^^^^^^ error: aborting due to 1 previous error </ins>
Change:
Reduced from : Compilation should crash with this error: Because we are trying to generate an LLVM bitcast from to . The MIR dump looks like this: I haven't been able to figure out how to produce this MIR without DataflowConstProp.
Thes standard library also works as a reproducer. Simply building a hello world with this will assert:
You asked about this crash before when I had a messy reproducer. Pinging you now because it's a lot smaller. it is now

Discussion:
Abi::Scalar(s @ abi::Scalar::Initialized { .. }) => { let size = s.size(bx); assert_eq!(size, layout.size, "abi::Scalar size does not match layout size"); <del> let val = read_scalar(offset, size, s, bx.backend_type(layout)); </del> <ins> let val = read_scalar(offset, size, s, bx.immediate_backend_type(layout)); </ins> OperandRef { val: OperandValue::Immediate(val), layout } } Abi::ScalarPair(

<ins> // This is a regression test for https://github.com/rust-lang/rust/issues/118047 // build-pass // compile-flags: -Zmir-opt-level=0 -Zmir-enable-passes=+DataflowConstProp #![crate_type = "lib"] pub struct State { inner: bool } pub fn make() -> State { State { inner: true } } </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
Probably just worth ignoring placeholder suggestions if they are coming from a different span ctxt than the fn -- either that, or logic to detect reuses of the same or something. Anyways, I think this is minimal: But I can't test it since I'm on my laptop.
Yeah can confirm this also triggers the debug assertion ^

Discussion:
pub fn multipart_suggestion_with_style( &mut self, msg: impl Into<SubdiagnosticMessage>, <del> suggestion: Vec<(Span, String)>, </del> <ins> mut suggestion: Vec<(Span, String)>, </ins> applicability: Applicability, style: SuggestionStyle, ) -> &mut Self { <del> let mut parts = suggestion </del> <ins> suggestion.sort_unstable(); suggestion.dedup(); let parts = suggestion </ins> .into_iter() .map(|(span, snippet)| SubstitutionPart { snippet, span }) .collect::<Vec<_>>(); <del> parts.sort_unstable_by_key(|part| part.span); </del> assert!(!parts.is_empty()); debug_assert_eq!( parts.iter().find(|part| part.span.is_empty() && part.snippet.is_empty()),

<ins> macro_rules! foo { ($ty:ty) => { fn foo(_: $ty, _: $ty) {} } } foo!(_); //~^ ERROR the placeholder `_` is not allowed within types on item signatures for functions fn main() {} </ins>

<ins> error[E0121]: the placeholder `_` is not allowed within types on item signatures for functions --> $DIR/issue-118048.rs:7:6 | LL | foo!(_); |      ^ |      | |      not allowed in type signatures |      not allowed in type signatures | help: use type parameters instead | LL ~         fn foo<T>(_: $ty, _: $ty) {} LL |     } LL | } LL | LL ~ foo!(T); | error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0121`. </ins>
Change:
:warning: for understanding this issue, you can ignore my messages here. they may be seen as funny though :warning:
hm, this might be entangled with the cursed way i set up with my
hm, even directly fails, so mommy is probably innocent~
So, rustc checks whether is defined. The checked-in test results assume that is set. But somehow it's not set when I execute compiletest, since I get the generic flag suggestions.
actually it probably is related to my cargo-mommy shenanigans, I set in my alias to make cargo-mommy pick up x. This does work for builds, but something seems to confuse test execution.
while the compiletest diff tried to tell me that its not set while it should be, the "unexpected errors" bit tells me that the env var is set while it shouldn't be.
I tried running tests in a fresh checkout free of any shenanigans and that worked fine, so this is a me issue. and no, what seems to be happening is that the var ISN'T set for me, I manually checked the stderr dump from compiletest and it suggests . I also inserted a panic when it is set, and that panic is not triggering.
In both my not working run and the working run, is not set inside of compiletest.
and in both runs, is not set in the output of the rustc .. ???
Okay, I resolved most of my confusion, leaving sane behavior that can be debugged: turns out I blessed these tests into wrongness before seeing what's wrong, so all results were the wrong way around and confusing compiletest does caching slightly differently than I imagined it would do caching Now I'm left with the sane behavior of works and doesn't (so my in the alias is causing the problem) which I think I can figure out.
Or rather, there is nothing to debug anymore. is set, which changes the rustc diagnostic. It's as simple as that.

Discussion:
} } } <ins> // Some UI tests trigger behavior in rustc where it reads $CARGO and changes behavior if it exists. // To make the tests work that rely on it not being set, make sure it is not set. cmd.env_remove("CARGO"); </ins> cmd.env("RUSTC_BOOTSTRAP", "1"); // Override the rustc version used in symbol hashes to reduce the amount of normalization // needed when diffing test output.
Change:
says "Deprecating in a future Rust version" ! but it will not be deprecated in a future Rust version, it will be deprecated in a future crate version. An easy fix would be just always saying "version" instead of "Rust version", alternatively special casing the standard library.

Discussion:
format!("Deprecating in {version}") } } <del> DeprecatedSince::Future => String::from("Deprecating in a future Rust version"), </del> <ins> DeprecatedSince::Future => String::from("Deprecating in a future version"), </ins> DeprecatedSince::NonStandard(since) => { format!("Deprecated since {}", Escape(since.as_str())) }

// @has deprecated_future_staged_api/index.html '//*[@class="stab deprecated"]'  //      'Deprecation planned' // @has deprecated_future_staged_api/struct.S2.html '//*[@class="stab deprecated"]'  <del> //      'Deprecating in a future Rust version: literally never' </del> <ins> //      'Deprecating in a future version: literally never' </ins> #[deprecated(since = "TBD", note = "literally never")] #[stable(feature = "deprecated_future_staged_api", since = "1.0.0")] pub struct S2;
Change:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: the following error was constructed but not emitted', 'error: internal compiler error: the following error was constructed but not emitted' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
Regression in nightly-2023-11-21 ping
I found that the code snippet does not cause ICE anymore. Meta: Output:

Discussion:
&& let [segment] = &attr_kind.item.path.segments[..] && segment.ident.name == sym::cfg && let Some(args_span) = attr_kind.item.args.span() <del> && let Ok(next_attr) = snapshot.parse_attribute(InnerAttrPolicy::Forbidden(None)) </del> <ins> && let next_attr = match snapshot.parse_attribute(InnerAttrPolicy::Forbidden(None)) { Ok(next_attr) => next_attr, Err(inner_err) => { err.cancel(); inner_err.cancel(); return; } } </ins> && let ast::AttrKind::Normal(next_attr_kind) = next_attr.kind && let Some(next_attr_args_span) = next_attr_kind.item.args.span() && let [next_segment] = &next_attr_kind.item.path.segments[..] && segment.ident.name == sym::cfg <del> && let Ok(next_expr) = snapshot.parse_expr() </del> { <ins> let next_expr = match snapshot.parse_expr() { Ok(next_expr) => next_expr, Err(inner_err) => { err.cancel(); inner_err.cancel(); return; } }; </ins> // We have for sure // #[cfg(..)] // expr

<ins> // Issue #118164: recovery path leaving unemitted error behind fn bar() -> String { #[cfg(feature = )] [1, 2, 3].iter().map().collect::<String>() //~ ERROR expected `;`, found `#` #[attr] //~ ERROR expected statement after outer attribute } fn main() { let _ = bar(); } </ins>

<ins> error: expected `;`, found `#` --> $DIR/properly-recover-from-trailing-outer-attribute-in-body.rs:4:47 | LL |     #[cfg(feature = )] |     ------------------ only `;` terminated statements or tail expressions are allowed after this attribute LL |     [1, 2, 3].iter().map().collect::<String>() |                                               ^ expected `;` here LL |     #[attr] |     - unexpected token | help: add `;` here | LL |     [1, 2, 3].iter().map().collect::<String>(); |                                               + help: alternatively, consider surrounding the expression with a block | LL |     { [1, 2, 3].iter().map().collect::<String>() } |     +                                            + error: expected statement after outer attribute --> $DIR/properly-recover-from-trailing-outer-attribute-in-body.rs:5:5 | LL |     #[attr] |     ^^^^^^^ error: aborting due to 2 previous errors </ins>
Change:
While working on , I noticed that struct variants with no (visible) fields look kinda awkward. ! The Fields heading takes a lot of space without adding particularly much to the content. The easiest solution would be to just remove the heading, but that would show no indication that there exist private fields. The same issue exists in top-level structs as well, but there it is mitigated by having the definition in the code block just above, while for enums there can be a sizeable distance between the two. Any thoughts? Am I just overthinking the whole thing?
No this is a very good point. If there are no fields, we shouldn't add the "Fields" heading. Sending a fix.

Discussion:
w.write_str("</h3></section>"); let heading_and_fields = match &variant_data.kind { <del> clean::VariantKind::Struct(s) => Some(("Fields", &s.fields)), </del> <ins> clean::VariantKind::Struct(s) => { // If there is no field to display, no need to add the heading. if s.fields.iter().any(|f| !f.is_doc_hidden()) { Some(("Fields", &s.fields)) } else { None } } </ins> clean::VariantKind::Tuple(fields) => { // Documentation on tuple variant fields is rare, so to reduce noise we only emit // the section if at least one field is documented.

<ins> // This is a regression test for <https://github.com/rust-lang/rust/issues/118195>. // It ensures that the "Fields" heading is not generated if no field is displayed. #![crate_name = "foo"] // @has 'foo/enum.Foo.html' // @has - '//*[@id="variant.A"]' 'A' // @count - '//*[@id="variant.A.fields"]' 0 // @has - '//*[@id="variant.B"]' 'B' // @count - '//*[@id="variant.B.fields"]' 0 // @snapshot variants - '//*[@id="main-content"]/*[@class="variants"]' pub enum Foo { /// A variant with no fields A {}, /// A variant with hidden fields B { #[doc(hidden)] a: u8 }, } </ins>

<ins> <div class="variants"><section id="variant.A" class="variant"><a href="#variant.A" class="anchor">&#167;</a><h3 class="code-header">A</h3></section><div class="docblock"><p>A variant with no fields</p> </div><section id="variant.B" class="variant"><a href="#variant.B" class="anchor">&#167;</a><h3 class="code-header">B</h3></section><div class="docblock"><p>A variant with hidden fields</p> </div></div> </ins>  No newline at end of file
Change:
Fuzzer generated MIR, reduced, and UB-free under Miri (for real this time :sweatsmile:) Segfaults with enabled: , which is a valid pointer, somehow got propagated as 0: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That seems undesirable. Is there a surface Rust program that can produce this MIR? Asking primarily for prioritization purposes.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Minimized test case:
Here's an example using stable surface syntax (). Seems to have been introduced in 1.70, with in particular.
Nevermind seems like I was wrong. <details</details
It's not an LLVM miscompilation, the code is already by the time it goes to LLVM. With So it's defiantly happening in MIR ConstProp
The problem seems to be that when running on the statement , the frames arn't updated, so when it runs on , it thinks is their for local . , on to add logging and test. ()
claim
Cc

Discussion:
// FIXME we need to revisit this for #67176 if rvalue.has_param() { <ins> trace!("skipping, has param"); </ins> return None; } if !rvalue

fn visit_assign(&mut self, place: &Place<'tcx>, rvalue: &Rvalue<'tcx>, location: Location) { self.super_assign(place, rvalue, location); <del> let Some(()) = self.check_rvalue(rvalue) else { return }; </del> <ins> let Some(()) = self.check_rvalue(rvalue) else { trace!("rvalue check failed, removing const"); Self::remove_const(&mut self.ecx, place.local); return; }; </ins> match self.ecx.machine.can_const_prop[place.local] { // Do nothing if the place is indirect.

<ins> // unit-test: ConstProp // compile-flags: -O // Regression test for https://github.com/rust-lang/rust/issues/118328 #![allow(unused_assignments)] struct SizeOfConst<T>(std::marker::PhantomData<T>); impl<T> SizeOfConst<T> { const SIZE: usize = std::mem::size_of::<T>(); } // EMIT_MIR overwrite_with_const_with_params.size_of.ConstProp.diff fn size_of<T>() -> usize { // CHECK-LABEL: fn size_of( // CHECK: _1 = const 0_usize; // CHECK-NEXT: _1 = const _; // CHECK-NEXT: _0 = _1; let mut a = 0; a = SizeOfConst::<T>::SIZE; a } fn main() { assert_eq!(size_of::<u32>(), std::mem::size_of::<u32>()); } </ins>

<ins> - // MIR for `size_of` before ConstProp + // MIR for `size_of` after ConstProp fn size_of() -> usize { let mut _0: usize; let mut _1: usize; scope 1 { debug a => _1; } bb0: { StorageLive(_1); _1 = const 0_usize; _1 = const _; _0 = _1; StorageDead(_1); return; } } </ins>

<ins> // compile-flags: -O // run-pass // Regression test for https://github.com/rust-lang/rust/issues/118328 #![allow(unused_assignments)] struct SizeOfConst<T>(std::marker::PhantomData<T>); impl<T> SizeOfConst<T> { const SIZE: usize = std::mem::size_of::<T>(); } fn size_of<T>() -> usize { let mut a = 0; a = SizeOfConst::<T>::SIZE; a } fn main() { assert_eq!(size_of::<u32>(), std::mem::size_of::<u32>()); } </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. -- <!-- --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
minimal repro of the error reported above <details<summaryBacktrace</summary</details
Same ICE with in  () cc searched nightlies: from nightly-2023-12-03 to nightly-2023-12-06 regressed nightly: nightly-2023-12-06 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details

Discussion:
use rustc_middle::infer::unify_key::{ConstVariableOrigin, ConstVariableOriginKind}; use rustc_middle::ty::error::{ExpectedFound, TypeError}; use rustc_middle::ty::relate::{RelateResult, TypeRelation}; <ins> use rustc_middle::ty::TyVar; </ins> use rustc_middle::ty::{self, InferConst, ToPredicate, Ty, TyCtxt, TypeVisitableExt}; use rustc_middle::ty::{IntType, UintType}; use rustc_span::DUMMY_SP;

ambient_variance, )?; <del> self.infcx.inner.borrow_mut().type_variables().instantiate(b_vid, b_ty); </del> <ins> // Constrain `b_vid` to the generalized type `b_ty`. if let &ty::Infer(TyVar(b_ty_vid)) = b_ty.kind() { self.infcx.inner.borrow_mut().type_variables().equate(b_vid, b_ty_vid); } else { self.infcx.inner.borrow_mut().type_variables().instantiate(b_vid, b_ty); } </ins> if needs_wf { self.obligations.push(Obligation::new(

/// Precondition: `vid` must not have been previously instantiated. pub fn instantiate(&mut self, vid: ty::TyVid, ty: Ty<'tcx>) { let vid = self.root_var(vid); <ins> debug_assert!(!ty.is_ty_var(), "instantiating ty var with var: {vid:?} {ty:?}"); </ins> debug_assert!(self.probe(vid).is_unknown()); debug_assert!( self.eq_relations().probe_value(vid).is_unknown(), <del> "instantiating type variable `{:?}` twice: new-value = {:?}, old-value={:?}", vid, ty, </del> <ins> "instantiating type variable `{vid:?}` twice: new-value = {ty:?}, old-value={:?}", </ins> self.eq_relations().probe_value(vid) ); self.eq_relations().union_value(vid, TypeVariableValue::Known { value: ty });
Change:
No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Short code to reproduce the issue.

Discussion:
/// Helper for pushing to `self.suggestions`, if available (not disable). fn push_suggestion(&mut self, suggestion: CodeSuggestion) { <ins> for subst in &suggestion.substitutions { for part in &subst.parts { let span = part.span; let call_site = span.ctxt().outer_expn_data().call_site; if span.in_derive_expansion() && span.overlaps_or_adjacent(call_site) { // Ignore if spans is from derive macro. return; } } } </ins> if let Ok(suggestions) = &mut self.suggestions { suggestions.push(suggestion); }

span.lo < other.hi && other.lo < span.hi } <ins> /// Returns `true` if `self` touches or adjoins `other`. pub fn overlaps_or_adjacent(self, other: Span) -> bool { let span = self.data(); let other = other.data(); span.lo <= other.hi && other.lo <= span.hi } </ins> /// Returns `true` if the spans are equal with regards to the source text. /// /// Use this instead of `==` when either span could be generated code,

<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_derive(Deserialize)] pub fn deserialize_derive(input: TokenStream) -> TokenStream { "impl Build { fn deserialize() -> Option<u64> { let x: Option<u32> = Some(0); Some(x? + 1) } } " .parse() .unwrap() } </ins>

<ins> // aux-build: issue-118809.rs #[macro_use] extern crate issue_118809; #[derive(Deserialize)] //~ ERROR mismatched types [E0308] pub struct Build { } fn main() {} </ins>

<ins> error[E0308]: mismatched types --> $DIR/issue-118809.rs:6:10 | LL | #[derive(Deserialize)] |          ^^^^^^^^^^^ |          | |          expected `u64`, found `u32` |          arguments to this enum variant are incorrect | help: the type constructed contains `u32` due to the type of the argument passed --> $DIR/issue-118809.rs:6:10 | LL | #[derive(Deserialize)] |          ^^^^^^^^^^^ this argument influences the type of `Some` note: tuple variant defined here --> $SRC_DIR/core/src/option.rs:LL:COL = note: this error originates in the derive macro `Deserialize` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0308`. </ins>
Change:
While building latest Rust it fails like this: is the first bad commit commit Author: David Tolnay Date: Wed Nov 29 23:02:05 2023 -0800 Add ifletguard and let_chains pretty printer tests | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)
do you have any idea about this? Thank you!
I am skeptical about that bisect. That commit is only adding tests. I do not see any way that it could cause bootstrap to fail to build.

Discussion:
//! parent directory, and otherwise documentation can be found throughout the `build` //! directory in each respective module. <del> #[cfg(all(any(unix, windows), not(target_os = "solaris")))] </del> use std::io::Write; #[cfg(all(any(unix, windows), not(target_os = "solaris")))] use std::process;