jiebi/CodeConvo huggingface dataset:
Change:
This code has differing behavior in debug and release (): When compiled in debug mode (without optimizations), the program produces no output. When compiled in release mode (with optimizations), the assertion fails: (This output doesn't make sense to me: how can they be unequal, but both negative infinity?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Here's another program with similar behavior, failing only in release. Not sure if it's the same issue.
This function, based on the first code example, is misoptimized to unconditionally return false (): This was not misoptimized before rustc 1.25, which upgraded LLVM to version 6.0. This appears to be a misoptimization by LLVM (Unless there's some allowed variability to do with the signs of zeroes that I'm not aware of?) label A-LLVM A-floating-point I-unsound T-compiler regression-from-stable-to-stable
This C code miscompiled under Clang as well: Confirmed to be a LLVM bug.
The second example does actually appear to be different - it doesn't miscompile until rustc 1.30 () (which upgraded to LLVM 8).
Upstream issue:
possibly related:
WG-prioritization assigning priority (). label -I-prioritize +P-high
T-compiler P-high review assign (also, notes that since upstream is fixed now, this issue should eventually get resolved by either an LLVM upgrade or by cherry-picking the fix to Rust's LLVM fork.)
Does that fix take care of the ?
To answer my own question: both examples are fixed for me after updating rustc nightly from ( 2022-09-29) to ( 2022-09-30)
Should we add a test for this?

Discussion:
<del> Subproject commit 670e5f673acb736acbfce65e0ffe2c8cd115b93f </del> <ins> Subproject commit 9567f08afc94332d59025744f3a8198104949d3c </ins>
Change:
Example: This fails in LLVM:
label +C-bug +A-LLVM +requires-nightly

Discussion:
use rustc_middle::ty::layout::{HasTyCtxt, LayoutOf}; use rustc_middle::ty::{self, adjustment::PointerCast, Instance, Ty, TyCtxt}; use rustc_span::source_map::{Span, DUMMY_SP}; <ins> use rustc_target::abi::Size; </ins> impl<'a, 'tcx, Bx: BuilderMethods<'a, 'tcx>> FunctionCx<'a, 'tcx, Bx> { #[instrument(level = "trace", skip(self, bx))]

bug!("Only valid to do a DynStar cast into a DynStar type") }; let vtable = get_vtable(bx.cx(), source.ty(self.mir, bx.tcx()), trait_ref); <ins> let vtable = bx.pointercast(vtable, bx.cx().type_ptr_to(bx.cx().type_isize())); // FIXME(dyn-star): this is probably not the best way to check if this is // a pointer, and really we should ensure that the value is a suitable // pointer earlier in the compilation process. let data = match operand.layout.pointee_info_at(bx.cx(), Size::ZERO) { Some(_) => bx.ptrtoint(data, bx.cx().type_isize()), None => data, }; </ins> OperandValue::Pair(data, vtable) } mir::CastKind::Pointer(

<ins> // run-pass // compile-flags: -C opt-level=0 #![feature(dyn_star)] #![allow(incomplete_features)] use std::fmt::Display; fn make_dyn_star() -> dyn* Display { Box::new(42) as dyn* Display } fn main() { let x = make_dyn_star(); println!("{x}"); } </ins>
Change:
Test case (: This gives the following error message:
label +C-bug +T-compiler +I-ICE +F-dyn_star +requires-nightly
A smaller sample that ICE's with the same message:
The sample provided by DutchGhost compiles now, and the one that provided compiles with some slight modification (adding some lifetimes so borrowck is happy):

Discussion:
<ins> // check-pass #![feature(dyn_star)] #![allow(incomplete_features)] trait AddOne { fn add1(&mut self) -> usize; } impl AddOne for usize { fn add1(&mut self) -> usize { *self += 1; *self } } impl AddOne for &mut usize { fn add1(&mut self) -> usize { (*self).add1() } } fn add_one(mut i: dyn* AddOne + '_) -> usize { i.add1() } fn main() { let mut x = 42usize; let y = &mut x as (dyn* AddOne + '_); println!("{}", add_one(y)); } </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. --./src/test/ui/associated-consts/issue-- <!-- 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. --: rustdoc ./src/test/ui/associated-consts/issue-- <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
For an unknown reason, it doesn't fail before we're way into the part of rustdoc when calling .
I tried this: <details</detailsBut unfortunately the result still looks bad: Not sure what's going on and why this error appears this late.
Hm, is it worth committing that? :slightlysmilingface: In other examples like we don't get any information at all on what the underlying error is and rustdoc just says I know that there are perhaps 5-10 ices that all have this message and its hard for me to tell if they all have the same cause or are actually due to different underlying issues. :/
I can provide a PR with this change if you want, but I'm not sure it's much of an improvement... Oh well. Pushing a PR and then you'll decide if you want it or not.
This errors correctly on rustdoc now, needs test
I'll add it tomorrow then. Thanks for the heads up!

Discussion:
<ins> // Regression test for <https://github.com/rust-lang/rust/issues/102467>. // It ensures that the expected error is displayed. #![feature(associated_const_equality)] trait T { type A: S<C<X = 0i32> = 34>; //~^ ERROR associated type bindings are not allowed here } trait S { const C: i32; } fn main() {} </ins>

<ins> error[E0229]: associated type bindings are not allowed here --> $DIR/issue-102467.rs:7:17 | LL |     type A: S<C<X = 0i32> = 34>; |                 ^^^^^^^^ associated type not allowed here error: aborting due to previous error For more information about this error, try `rustc --explain E0229`. </ins>
Change:
I have created which reliably reproduces the internal compiler error on my system. The readme in that crate includes version as well as from inside and outside the repo which has a . This is recreated with: with the dependencies from my original crate into : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note, changing to enables to succeed with version: -and:
claim
I'm also getting a similar error but mine doesn't resolve by changing in . More info:
This issue here is caused by nom as well. The fix is pretty simple, I should be able to open up the PR today.

Discussion:
impl Emitter for BufferEmitter { fn emit_diagnostic(&mut self, diag: &Diagnostic) { let mut buffer = self.buffer.borrow_mut(); <del> // FIXME(davidtwco): need to support translation here eventually buffer.messages.push(format!("error from rustc: {}", diag.message[0].0.expect_str())); </del> <ins> let fluent_args = self.to_fluent_args(diag.args()); let translated_main_message = self.translate_message(&diag.message[0].0, &fluent_args); buffer.messages.push(format!("error from rustc: {}", translated_main_message)); </ins> if diag.is_error() { buffer.has_errors = true; }

/// ``` pub fn invalid() {} //~^^^^ WARNING could not parse code block as Rust code <ins> /// ``` /// fn wook_at_my_beautifuw_bwaces_plz() {); /// ``` pub fn uwu() {} //~^^^^ WARNING could not parse code block as Rust code </ins>

LL | /// ```text |        ++++ <del> warning: 12 warnings emitted </del> <ins> warning: could not parse code block as Rust code --> $DIR/invalid-syntax.rs:103:5 | LL |   /// ``` |  _____^ LL | | /// fn wook_at_my_beautifuw_bwaces_plz() {); LL | | /// ``` | |_______^ | = note: error from rustc: mismatched closing delimiter: `)` help: mark blocks that do not contain Rust code as text | LL | /// ```text |        ++++ warning: 13 warnings emitted </ins>
Change:
Hashbrown crate starts fail when running with: Full log file can be found in . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryLog</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 --
That's probably introduced by , but I haven't looked further yet.
Quick repro: and then edit: this repro is incorrect (I'm investigating)
I can reproduce with a simple hello-world when running in an older container. I think it's related to the user having binutils < 2.32, which would be fixed by Our new i586-gnu cross toolchain appears to be compressing by default, like the option, but I don't know why it's happening on this one and not any of our other crosstool-ng builds.
I found this commit in binutils: ;a=commit;h= That is, gas (the assembler) enables compression by default only on Linux/x86, which is why we haven't had this problem with other crosstool-ng toolchains. I'll explicitly turn that off.
great detective work thanks! :)

Discussion:
- Operating System > Target OS = linux - Operating System > Linux kernel version = 3.2.101 - Binary utilities > Version of binutils = 2.32 <ins> - Binary utilities > binutils extra config = --enable-compressed-debug-sections=none -- (*) </ins> - C-library > glibc version = 2.17.0 - C compiler > gcc version = 8.3.0 - C compiler > C++ = ENABLE <ins> (*) Compressed debug is enabled by default for gas (assembly) on Linux/x86 targets, but that makes our `compiler_builtins` incompatible with binutils < 2.32. </ins> ### `powerpc-linux-gnu.config` For targets: `powerpc-unknown-linux-gnu`

CT_BINUTILS_LINKER_DEFAULT="bfd" # CT_BINUTILS_PLUGINS is not set CT_BINUTILS_RELRO=m <del> CT_BINUTILS_EXTRA_CONFIG_ARRAY="" </del> <ins> CT_BINUTILS_EXTRA_CONFIG_ARRAY="--enable-compressed-debug-sections=none" </ins> # CT_BINUTILS_FOR_TARGET is not set CT_ALL_BINUTILS_CHOICES="BINUTILS"
Change:
Note: Switching back to 1.65 compiles fine : </p</details
label +E-needs-mcve
Sorry for the noise on this issue, but I just realized what I had done which apparently got around this issue. I fixed a new warning in my web server library by turning this.. into this
I caused this. Let me put up a fix.

Discussion:
lint_opaque_hidden_inferred_bound = opaque type `{$ty}` does not satisfy its associated type bounds .specifically = this associated type bound is unsatisfied for `{$proj_ty}` <del> .suggestion = add this bound </del> <ins> lint_opaque_hidden_inferred_bound_sugg = add this bound </ins>

use rustc_hir as hir; use rustc_infer::infer::TyCtxtInferExt; <del> use rustc_macros::LintDiagnostic; use rustc_middle::ty::{self, fold::BottomUpFolder, Ty, TypeFoldable}; </del> <ins> use rustc_macros::{LintDiagnostic, Subdiagnostic}; use rustc_middle::ty::{ self, fold::BottomUpFolder, print::TraitPredPrintModifiersAndPath, Ty, TypeFoldable, }; </ins> use rustc_span::Span; use rustc_trait_selection::traits; use rustc_trait_selection::traits::query::evaluate_obligation::InferCtxtExt;

)) { // If it's a trait bound and an opaque that doesn't satisfy it, // then we can emit a suggestion to add the bound. <del> let (suggestion, suggest_span) = </del> <ins> let add_bound = </ins> match (proj_term.kind(), assoc_pred.kind().skip_binder()) { <del> (ty::Opaque(def_id, _), ty::PredicateKind::Trait(trait_pred)) => ( format!(" + {}", trait_pred.print_modifiers_and_trait_path()), Some(cx.tcx.def_span(def_id).shrink_to_hi()), ), _ => (String::new(), None), </del> <ins> (ty::Opaque(def_id, _), ty::PredicateKind::Trait(trait_pred)) => Some(AddBound { suggest_span: cx.tcx.def_span(*def_id).shrink_to_hi(), trait_ref: trait_pred.print_modifiers_and_trait_path(), }), _ => None, </ins> }; cx.emit_spanned_lint( OPAQUE_HIDDEN_INFERRED_BOUND,

ty: cx.tcx.mk_opaque(def_id, ty::InternalSubsts::identity_for_item(cx.tcx, def_id)), proj_ty: proj_term, assoc_pred_span, <del> suggestion, suggest_span, </del> <ins> add_bound, </ins> }, ); }

proj_ty: Ty<'tcx>, #[label(lint::specifically)] assoc_pred_span: Span, <del> #[suggestion_verbose(applicability = "machine-applicable", code = "{suggestion}")] suggest_span: Option<Span>, suggestion: String, </del> <ins> #[subdiagnostic] add_bound: Option<AddBound<'tcx>>, } #[derive(Subdiagnostic)] #[suggestion_verbose( lint::opaque_hidden_inferred_bound_sugg, applicability = "machine-applicable", code = " + {trait_ref}" )] struct AddBound<'tcx> { #[primary_span] suggest_span: Span, #[skip_arg] trait_ref: TraitPredPrintModifiersAndPath<'tcx>, </ins> }

<ins> // check-pass #![allow(opaque_hidden_inferred_bound)] #![allow(dead_code)] trait Duh {} impl Duh for i32 {} trait Trait { type Assoc: Duh; } impl<R: Duh, F: FnMut() -> R> Trait for F { type Assoc = R; } fn foo() -> impl Trait<Assoc = impl Send> { || 42 } fn main() {} </ins>
Change:
My project uses arm neon intrinsics. The arm test starts failing after 2022-10-04. Reproduce: works (incremental compilation enabled) fails (incremental compilation disabled) I'm not sure how to find a MCVE for this issue, so I put the original context here. <!-- 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. --:
Looks like stdarch hardcodes LLVM intrinsic mangling in a few places. These should be changed from p0i8 to just p0 in LLVM 15: Usually this gets gracefully handled through intrinsic remangling, I don't know why that doesn't occur for your particular case. Updating stdarch to directly use the right names should avoid any problems though. cc
Does this apply to all extensions or just ? For example .
It applies to all extensions.
Minimal reproduction on godbolt: Any idea why LLVM auto-upgrade isn't working in this case?
Thanks for the minimal reproducer. This turned out to be a simple typo, fixed in This was hidden when doing simple tests with opt because the IR parser was doing another redundant remangle (fixed in and ). Backport request:

Discussion:
<del> Subproject commit 4b85255772114ca4946d95fe591933dae7d61991 </del> <ins> Subproject commit 2a2ea6b49e79325e0d10d33fac2b10ea3bebcc7c </ins>
Change:
Consider compilefail/regions-nested- When you run this, in addition to various error output, you will also see messages prefixed by . In those messages, when a lifetime is printed, it is printed with a leading in addition to the that is part of its name. For example: . In my opinion, this is confusing. is a lifetime, while are the first three characters of some (incomplete) type expression that is missing the pointed-to type (along with a potential qualifier). I suspect the leading is arising probably some artifact of how the code is implementing the trait; it might also involve the use of as the implementation of how lifetimes are printed (even though the former says it is for printing ptrs, not lifetimes). Also, there is an extra space between and above.
that's a holdover from the days before existed as a notation for lifetimes, definitely should be fixed
If no one else is working on this, I'll take it.
Apologies for how long this is taking, I'm still kind of learning the internals. I have a question, though. I have fixed this issue, but I'm now getting output like: The second is an int scoped to an anonymous lifetime, but the way I've implemented it there's no indication of this in the output. Is there a decided-upon notation for this case? Perhaps ?
I think those types should be written .
Or perhaps, better yet, or something like that. It'd be nice to indicate to the user that there are in fact two distinct lifetimes there, otherwise the message looks silly ("expected but found " -- wat??)
Given that work on this issue seems to have stagnated somewhat, would it be OK if I could take this issue? I was thinking that perhaps would be better than as it’s more descriptive, and matches with . Also, should all references be annotated thus? It seems slightly unnecessary to state the lifetime in an error like &'<anonintuinttype has no method `. This would probably complicate the implementation rather a lot, however.
On 5/19/2014 10:56 PM, P1start wrote:

Discussion:
} pub fn bound_region_ptr_to_str(cx: &ctxt, br: BoundRegion) -> StrBuf { <del> bound_region_to_str(cx, "&", true, br) </del> <ins> bound_region_to_str(cx, "", false, br) </ins> } pub fn bound_region_to_str(cx: &ctxt,

<ins> // Copyright 2014 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. fn test<'x>(x: &'x int) { //~ NOTE the lifetime 'x as defined drop::< <'z>|&'z int| -> &'z int>(|z| { //~^ ERROR mismatched types //~^^ ERROR cannot infer an appropriate lifetime x }); } fn main() {} </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
searched toolchains through Regression in hmm
what's your system? do you have debug builds on? I can't seem to repro this on master. edit: oops, first question i guess is
no this is not with debug build on, its just the normal master toolchain installed via on x86
Literally can't repro this locally. I'm pretty sure that I know the reason why (the function, which is called from isn't actually returning a sorted list of elaborated predicates). This must be because we're calculating def path hash or something differently between the CI master build and a local build of master.
so you can't even repro with the official master artifacts? :| or just not with a local build?
Sorry, I can repro with the master artifacts. But not with a local build of master, which makes testing the change that I want to make to fix this issue difficult.
Actually, repro on ~stable~ whoops I mean nightly: This should be a UI test that is resilient to def path hashing changes.

Discussion:
}); debug!(?trait_predicate); <del> let elaborated_predicates = elaborate_trait_ref(tcx, trait_ref).filter_map(|obligation| { debug!(?obligation); let pred = obligation.predicate.to_opt_poly_projection_pred()?; Some(pred.map_bound(|p| { ty::ExistentialPredicate::Projection(ty::ExistentialProjection { item_def_id: p.projection_ty.item_def_id, substs: p.projection_ty.substs, term: p.term, }) })) }); </del> <ins> let mut elaborated_predicates: Vec<_> = elaborate_trait_ref(tcx, trait_ref) .filter_map(|obligation| { debug!(?obligation); let pred = obligation.predicate.to_opt_poly_projection_pred()?; Some(pred.map_bound(|p| { ty::ExistentialPredicate::Projection(ty::ExistentialProjection { item_def_id: p.projection_ty.item_def_id, substs: p.projection_ty.substs, term: p.term, }) })) }) .collect(); // NOTE: Since #37965, the existential predicates list has depended on the // list of predicates to be sorted. This is mostly to enforce that the primary // predicate comes first. elaborated_predicates.sort_by(|a, b| a.skip_binder().stable_cmp(tcx, &b.skip_binder())); elaborated_predicates.dedup(); </ins> let existential_predicates = tcx .mk_poly_existential_predicates(iter::once(trait_predicate).chain(elaborated_predicates));

<ins> // check-pass use std::future::Future; pub trait Service { type Response; type Future: Future<Output = Self::Response>; } pub trait A1: Service<Response = i32> {} pub trait A2: Service<Future = Box<dyn Future<Output = i32>>> + A1 { fn foo(&self) {} } pub trait B1: Service<Future = Box<dyn Future<Output = i32>>> {} pub trait B2: Service<Response = i32> + B1 { fn foo(&self) {} } fn main() { let x: &dyn A2 = todo!(); let x: &dyn B2 = todo!(); } </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
I think this is related to

Discussion:
None } }) <del> .map(|res| res.expect_full_res()) </del> <ins> .and_then(|res| res.full_res()) </ins> .filter(|res| { // Permit the types that unambiguously always // result in the same type constructor being used

<ins> impl Error for str::Utf8Error { //~^ ERROR cannot find trait `Error` in this scope //~| ERROR ambiguous associated type fn description(&self)  {} } fn main() {} </ins>

<ins> error[E0405]: cannot find trait `Error` in this scope --> $DIR/issue-102946.rs:1:6 | LL | impl Error for str::Utf8Error { |      ^^^^^ not found in this scope | help: consider importing this trait | LL | use std::error::Error; | error[E0223]: ambiguous associated type --> $DIR/issue-102946.rs:1:16 | LL | impl Error for str::Utf8Error { |                ^^^^^^^^^^^^^^ | help: you are looking for the module in `std`, not the primitive type | LL | impl Error for std::str::Utf8Error { |                +++++ error: aborting due to 2 previous errors Some errors have detailed explanations: E0223, E0405. For more information about an error, try `rustc --explain E0223`. </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It seems that the ICE does not occur on latest nightly.
Yes indeed. I was told to still submit bugs even when they only occur on newest Beta.
label +E-needs-test
claim To add the test
If someone finds out which nightly pr fixed it I guess we could consider a backport to beta?
I fixed this in . I'll beta nominate it.

Discussion:
<ins> use std::rc::Rc; type Foo<'a, T> = &'a dyn Fn(&T); type RcFoo<'a, T> = Rc<Foo<'a, T>>; fn bar_function<T>(function: Foo<T>) -> RcFoo<T> { //~^ ERROR mismatched types let rc = Rc::new(function); } fn main() {} </ins>

<ins> error[E0308]: mismatched types --> $DIR/issue-102964.rs:5:41 | LL | fn bar_function<T>(function: Foo<T>) -> RcFoo<T> { |    ------------                         ^^^^^^^^ expected struct `Rc`, found `()` |    | |    implicitly returns `()` as its body has no tail or `return` expression | = note: expected struct `Rc<&dyn for<'a> Fn(&'a T)>` found unit type `()` help: consider returning the local binding `rc` | LL ~     let rc = Rc::new(function); LL +     rc | error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>