jiebi/CodeConvo huggingface dataset:
Change:
unsafe { let insn = llvm::LLVMBuildStore(self.llbuilder, val, ptr); llvm::LLVMSetVolatile(insn, llvm::True); <ins> insn </ins> } }

Discussion:
The attached source produces code that misbehaves on some platforms that are picky about memory access alignment. The code should exit with code 2, but on both Emscripten-generated JavaScript and ARMv5, it finishes with exit code 1 to indicate that the field is incorrectly tested as equal to . Changing the field to a type results in proper execution on these platforms. All optimization levels seem to cause it. Libraries that make use of structs with fields followed by enums seem particularly prone to this problem. It all works fine on platforms that allow unaligned memory access like x86, ARMv6, etc. Expected output: (x86, ARMv6) Actual output: (ARMv5, Emscripten) Note that the same ARM binary runs on both ARMv5 and ARMv6 platforms, producing the different results. See also: ( and removed)
To quote myself:
Change:
<del> FROM ubuntu:16.04 RUN apt-get update && apt-get install -y --no-install-recommends  g++  make  file  curl  ca-certificates  python3  git  cmake  sudo  gdb  libssl-dev  pkg-config  xz-utils COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh ENV RUST_CONFIGURE_ARGS  --build=x86_64-unknown-linux-gnu  --enable-full-bootstrap ENV SCRIPT python3 ../x.py --stage 2 build # In general this just slows down the build and we're just a smoke test that # a full bootstrap works in general, so there's not much need to take this # penalty in build times. ENV NO_LLVM_ASSERTIONS 1 ENV NO_DEBUG_ASSERTIONS 1 </del>

Discussion:
It's clocking in at 20 minutes and seems to be doing nothing -- I suspect that this might be a result of changes to x.py defaults but have not confirmed. We should fix this.
(link to the PR: )
We discussed this during the and agreed to remove the builder. The builder doesn't provide much value for the stability of the project, as it rarely fails and we'd catch any failure it would prevent as soon as we promote nightly to beta.
To fix this issue, the builders needs to be removed from and .
Change:
self.suggest_no_capture_closure(err, expected, expr_ty); self.suggest_boxing_when_appropriate(err, expr, expected, expr_ty); self.suggest_missing_parentheses(err, expr); <ins> self.suggest_block_to_brackets_peeling_refs(err, expr, expr_ty, expected); </ins> self.note_need_for_fn_pointer(err, expected, expr_ty); self.note_internal_mutation_in_method(err, expr, expected, expr_ty); self.report_closure_inferred_return_type(err, expected);

Discussion:
, we should provide a structured suggestion as we already do when . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems easy enough, claim
Change:
// examined } } <del> })); </del> <ins> })? </ins> } if needs_to_be_read {

Discussion:
<details</summary</details<!-- 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. --:
I will try to reduce this to an MCVE.
Changing to appears to avoid the ICE, so that may be a useful place to focus.
Minimized it down to 60 lines without any dependencies. Maybe it can be minimized further but it's getting really hard. I've also left a few comments to say what's going on. <details<summary"Minimized" </summary</details
This appears to have regressed in Rust 1.64
This continues to ICE on beta and nightly
I bisected the regression, here is the output of : searched nightlies: from nightly-2022-06-24 to nightly-2022-08-05 regressed nightly: nightly-2022-07-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
Out of these seems the most likely, cc
Zooming onto changeset.
Found MVCE: <details<summaryOutput from Rust Playground</summary</details
Change:
<ins> // edition:2021 mod m { pub struct S { foo: i32 } impl S { pub fn foo(&self) -> i32 { 42 } } } fn bar(s: &m::S) { || s.foo() + s.foo; //~ ERROR E0616 } fn main() {} </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. --: Also checked beta and nightly at : <!-- 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 --
This does not panic on 1.55. Also, it panics on 1.56 regardless of which edition is used. label regression-from-stable-to-stable
searched nightlies: from nightly-2021-07-23 to nightly-2021-11-02 regressed nightly: nightly-2021-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsFrom this rollup, looks relevant, and it landed in 1.56 via backport.
claim
Assigning priority as in the prioritization working group.
Change:
///     if let Ok(time) = metadata.created() { ///         println!("{:?}", time); ///     } else { <del> ///         println!("Not supported on this platform"); </del> <ins> ///         println!("Not supported on this platform or filesystem"); </ins> ///     } ///     Ok(()) /// }

Discussion:
First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?
Change:
for elem in $list { $visitor.$method(elem) } <ins> }; ($visitor: expr, $method: ident, $list: expr, $($extra_args: expr),*) => { for elem in $list { $visitor.$method(elem, $($extra_args,)*) } </ins> } }

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[E0282]: type annotations needed --> $DIR/issue-98299.rs:4:5 | LL |     SmallCString::try_from(p).map(|cstr| cstr); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type for enum `Result<SmallCString<{_: usize}>, ()>` error: aborting due to previous error For more information about this error, try `rustc --explain E0282`. </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. --
Removing seems to fix it.
Reduced, with no nightly features (): Output on stable and beta: label regression-from-stable-to-nightly
bisection cc: searched nightlies: from nightly-2022-01-01 to nightly-2022-06-20 regressed nightly: nightly-2022-06-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Another snippet from
Change:
use {uint, u8, u16, u32, u64}; use {f32, f64}; use clone::Clone; <del> use cmp::{PartialEq, PartialOrd}; </del> <ins> use cmp::{Ord, PartialEq, PartialOrd}; </ins> use kinds::Copy; use mem::size_of; use ops::{Add, Sub, Mul, Div, Rem, Neg};

Discussion:
Right now the Int and Integer traits imply PartialOrd but not Ord. Is there a reason for this? It seems like integers do have a total order, not just partial. I asked on IRC and people seemed to think Int should imply Ord. If this is correct I can send a pull request?
Yup :)
I have two questions: May I ask what is the trait? Couldn't find any in the std doc: Did you mean  () when you wrote "the trait"? But it doesn't even inherit . Am I missing something?
The trait is in .
Ah, it was the big int code separated from the std lib! Thanks. I also overlooked implemented , implying . Sorry for the noise!
Change:
<ins> // Regression test for #113610 where we ICEd when trying to print // inference variables created by instantiating the self type parameter. fn main() { let _ = (Default::default(),); //~^ ERROR cannot call associated function on trait } </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<p</p</details
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:
Change:
<ins> #![feature(min_type_alias_impl_trait)] #![feature(type_alias_impl_trait)] #![allow(incomplete_features)] pub trait Foo {} pub trait Bar { type Foo: Foo; fn foo() -> Self::Foo; } pub trait Baz { type Foo: Foo; type Bar: Bar<Foo = Self::Foo>; fn foo() -> Self::Foo; fn bar() -> Self::Bar; } impl Foo for () {} impl Bar for () { type Foo = FooImpl; fn foo() -> Self::Foo { () } } // FIXME(#86731): The below is illegal use of `min_type_alias_impl_trait` // but the compiler doesn't report it, we should fix it. pub type FooImpl = impl Foo; pub type BarImpl = impl Bar<Foo = FooImpl>; //~^ ERROR: type mismatch resolving `<() as Bar>::Foo == ()` impl Baz for () { type Foo = FooImpl; type Bar = BarImpl; fn foo() -> Self::Foo { () } fn bar() -> Self::Bar { () } } fn main() {} </ins>

Discussion:
() changing into inside will successfully compile
modify labels: A-impl-trait, F-typealiasimpl_trait, C-bug, I-ICE, T-compiler, requires-nightly
Source: <details<summaryStack trace</summary<p</p</detailsregression in nightly-2019-08-04 Auto merge of - Centril:sound-bind-by-move, r=matthewjasper Auto merge of - pietroalbini:move-azure-pipelines, r=Mark-Simulacrum Auto merge of - Centril:rollup-h9t731z, r=Centril Auto merge of - RalfJung:miritypedispatch_first, r=oli-obk Auto merge of - varkor:trait-alias-impl-trait, r=Centril Auto merge of - Centril:rollup-x39p5ga, r=Centril
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.
Though the error seems incorrect, in I don't see where it is getting the obligation from, nowhere does the code assert that is true.
This example should be disallowed with but is not. I filed to cover that.
I agree with that the behavior here is a bug, I don't think we handle appearing in these sorts of contexts very well, at least within the defining module.
Thanks for triaging, we still should add a regression test to prevent ICE at least, right?
Yep, that's good
Change:
impl_span: Span, err: &mut Diagnostic, ) { <ins> if (overlap.trait_ref, overlap.self_ty).references_error() { err.downgrade_to_delayed_bug(); } </ins> match tcx.span_of_impl(overlap.with_impl) { Ok(span) => { err.span_label(span, "first implementation here");

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
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<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. // Test what happens when a HR obligation is applied to an impl with // "outlives" bounds. Currently we're pretty conservative here; this // will probably improve in time. trait Foo<X> { fn foo(&self, x: X) { } } fn want_foo<T>() where T : for<'a> Foo<&'a isize> { } /////////////////////////////////////////////////////////////////////////// // Expressed as a where clause struct SomeStruct<X> { x: X } impl<'a,X> Foo<&'a isize> for SomeStruct<X> where X : 'a { } fn one() { want_foo::<SomeStruct<usize>>(); } /////////////////////////////////////////////////////////////////////////// // Expressed as shorthand struct AnotherStruct<X> { x: X } impl<'a,X:'a> Foo<&'a isize> for AnotherStruct<X> { } fn two() { want_foo::<AnotherStruct<usize>>(); } fn main() { } </ins>

Discussion:
The following code fails to compile despite : The exact error is: Per comment , it seems that could imply .
contains the following comment:
I'd be interested in digging into this if you can give me some advice on how to get started.
hmm, probably best would be to privmsg me on IRC, if that's possible (). It should be fairly easy to write a targeted patch covering cases like , where the bound region only appears on the RHS; doing a more general fix (e.g., one that handles ) would be somewhat harder, though some of the recent refactoring I've been doing would help there.
Change:
#[unstable(feature = "fused", issue = "35602")] impl<'a> FusedIterator for Bytes<'a> {} <ins> #[unstable(feature = "trusted_len", issue = "37572")] unsafe impl<'a> TrustedLen for Bytes<'a> {} #[doc(hidden)] unsafe impl<'a> TrustedRandomAccess for Bytes<'a> { unsafe fn get_unchecked(&mut self, i: usize) -> u8 { self.0.get_unchecked(i) } fn may_have_side_effect() -> bool { false } } </ins> /// This macro generates a Clone impl for string pattern API /// wrapper types of the form X<'a, P> macro_rules! derive_pattern_clone {

Discussion:
I compared the performance of three equivalent functions: This is results (release mode):
IIRC zip is specialized for slices which is why the last case is so much faster.
Try also to compile with
A question could be: is it possible for to return something similar to ?
It makes the two times faster, the speed of the and the has stayed the same as before.
You've discovered the "untweaked speed" of zip :frowning_face:, which is what has. can implement the same way slice iterators do, in fact is just a newtype around an iterator that already implements that trait.
Change:
<ins> macro_rules! statement { () => {;}; //~ ERROR expected expression } fn main() { let _ = statement!(); } </ins>

Discussion:
or perhaps The bad help isn't related to the choice of or (even though the former needs to be followed by to be a statement and the latter doesn't, which could explain the source of the hint); also generates the help to add . %20%3D%3E%20%7B%3B%7D%3B%0A%7D%0A%0Afn%20main()%20%7B%0A%20%20%20%20let%20%20%3D%20statement!()%3B%0A%7D%0A) No response modify labels +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<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. // error-pattern: expected `bool`, found `_` (expected bool, found integral variable) fn main(){assert!(1,1);} </ins>

Discussion:
When trying to build with I'm getting
Is there a temporary workaround? Thanks!
Most likely change the occurrences of (or ) to . Like .
I just tripped over this ICE in serde. I love c-reduce. It came up with the following code that reproduces the bug by reducing 203K down to this in 15 minutes: Here's the error:
Change:
<ins> // Copyright 2017 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. #![feature(unboxed_closures, fn_traits, rustc_attrs)] struct Foo; impl<A> FnOnce<(A,)> for Foo { type Output = (); extern "rust-call" fn call_once(self, (_,): (A,)) { } } #[rustc_error] fn main() { //~ ERROR compilation successful println!("{:?}", Foo("bar")); } </ins>

Discussion:
I was trying to compile the following code: And got the following compiler error: Version info:
Still ICEs.
Minimal:
Triage: tracked by glacier
No longer ICEs today. E-needstest. I'm somewhat concerned though because this is the second glacier-tracked ICE that I've seen "fixed."
This was only broken because of the old code.
Change:
} } <ins> if self.token.kind == TokenKind::EqEq && self.prev_token.is_ident() && expected.iter().any(|tok| matches!(tok, TokenType::Token(TokenKind::Eq))) { // Likely typo: `=` → `==` in let expr or enum item return Err(self.sess.create_err(UseEqInstead { span: self.token.span })); } </ins> let expect = tokens_to_string(&expected); let actual = super::token_descr(&self.token); let (msg_exp, (label_sp, label_exp)) = if expected.len() > 1 {

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest replacing the with where appropriate as the suggestion for incorrect usage of in place of already exist. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
} } <ins> unsafe impl Send for Inner {} unsafe impl Sync for Inner {} </ins> unsafe fn pipe(name: *const u16, init: bool) -> libc::HANDLE { libc::CreateNamedPipeW( name,

Discussion:
There are quite few os-specific types definitions whose traits implementations are not consistent. With the work happening in OIBIT, I've tried to keep the implementations of built-in traits consistent for both and . Unfortunately, the test suite for these implementations is not unified, therefore there's a high chance that some types for 's implementation may have some traits implemented, whereas the 's implementation doesn't. In theory, we can assume that common types for these implementations should implement the same built-in types, therefore there should be tests that enforce this guarantee in a common place. Some examples may be found in This bug is to track the work there which impacts the of our standard library.
I can mentor on this bug, tagging with
seems interesting. Can i take this bug? :)
it's all yours, lemme know if you need help/reviews
This should be closed now right?
correct. Thanks!
Change:
= note: see issue #37854 <https://github.com/rust-lang/rust/issues/37854> for more information = help: add `#![feature(exclusive_range_pattern)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date <ins> = help: use an inclusive range pattern, like N..=M </ins> error: aborting due to 1 previous error

Discussion:
Came across this when a beginner was very confused about what was wrong with their ; the words "is experimental" and the link to the issue was not sufficient for their discovering what the problem/solution was. The suggested inclusive range pattern doesn't need to contain the actual matching value if producing it is hard or impossible, printing something like is still better than nothing. This issue may of course be ignored/closed if this nightly feature is just about ready to be stabilized or something. No response label +D-terse +C-enhancement +F-exclusiverangepattern <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
// casts to scalars other than `char` and `bare fn` are trivial let t_1_is_trivial = t_1_is_scalar && !t_1_is_char && !t_1_is_bare_fn; if ty::type_is_c_like_enum(fcx.tcx(), t_e) && t_1_is_trivial { <del> if t_1_is_float { </del> <ins> if t_1_is_float || ty::type_is_unsafe_ptr(t_1) { </ins> fcx.type_error_message(span, |actual| { format!("illegal cast; cast through an  integer first: `{}` as `{}`",

Discussion:
The following program causes rustc to crash: Obviously it's badly typed (converting void to a pointer type), but the compiler shouldn't crash here right? :) output of rustc -v: rustc 0.12.0-pre-nightly ( 2014-09-11 00:05:41 +0000) backtrace from trying to compile; Let me know if you need more information.
Yes, any ICE is bad. Thanks!
Simpler: Works with every C-like enum.
I'll try to fix this one together with
Fixed in
Change:
let ptr_vtable = |inner_source: Ty<'tcx>, inner_target: Ty<'tcx>| { let type_has_metadata = |ty: Ty<'tcx>| -> bool { use syntax_pos::DUMMY_SP; <del> if ty.is_sized(tcx, ty::ParamEnv::empty(traits::Reveal::All), DUMMY_SP) { </del> <ins> if ty.is_sized(tcx.at(DUMMY_SP), ty::ParamEnv::empty(traits::Reveal::All)) { </ins> return false; } let tail = tcx.struct_tail(ty);

Discussion:
One example is the method on . Internally it creates a , when it could simply be taking exactly that as an argument. In miri I had to write which just feels a little riddiculous (taking apart the , just to have the method construct it back). There's probably many other similar methods and functions that should be taking a
Can I take this one if no one is working on that ?
it's all yours!