jiebi/CodeConvo huggingface dataset:
Change:
Using a built from commit with debug assertions enabled ( in ), I'm seeing an internal compiler error on the following input (found by ):
: The second error should probably not be emitted as I believe it is caused by a placeholder lifetime used during recovery. We should introduce (or use if it is already there) a lifetime equivalent to .
This only happens in builds with debug assertions. It's not fixed in master.
Assigning as and removing .

Discussion:
} if let ty::Ref(region, t_type, mutability) = trait_ref.skip_binder().self_ty().kind { <ins> if region.is_late_bound() || t_type.has_escaping_bound_vars() { // Avoid debug assertion in `mk_obligation_for_def_id`. // // If the self type has escaping bound vars then it's not // going to be the type of an expression, so the suggestion // probably won't apply anyway. return; } </ins> let trait_type = match mutability { hir::Mutability::Mut => self.tcx.mk_imm_ref(region, t_type), hir::Mutability::Not => self.tcx.mk_mut_ref(region, t_type),

<ins> // Regression test for #70813 (this used to trigger a debug assertion) trait Trait {} struct S; impl<'a> Trait for &'a mut S {} fn foo<X>(_: X) where for<'b> &'b X: Trait, { } fn main() { let s = S; foo::<S>(s); //~ ERROR the trait bound `for<'b> &'b S: Trait` is not satisfied } </ins>

<ins> error[E0277]: the trait bound `for<'b> &'b S: Trait` is not satisfied --> $DIR/imm-ref-trait-object-literal-bound-regions.rs:17:5 | LL | fn foo<X>(_: X) |    --- required by a bound in this LL | where LL |     for<'b> &'b X: Trait, |                    ----- required by this bound in `foo` ... LL |     foo::<S>(s); |     ^^^^^^^^ the trait `for<'b> Trait` is not implemented for `&'b S` | = help: the following implementations were found: <&'a mut S as Trait> error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>
Change:
This seems to contain all the flags in . If I'm guessing right, the flags that used to not be in here, all turned into queries? So they're now cached as queries, instead of by mutating itself? cc
If it contains all the flags, then it seems to have no purpose. I'm honestly not sure what the name "nominal" is even meant to refer to here exactly -- I'm sure I gave it that name, but it's not very clear. I guess the point is "flags that should be inherited by containing types; ie., if the type has some flag , and is "nominal", then should also have ". Are there any flags that don't meet that definition anymore?
I think there were "nominal flags" and "cached properties" (using interior mutability), but now the latter is completely gone.
that sounds right. I'd be in favor of removing then.
I would love to help with this one. A quick search shows that is only used once in the entire code base, here: Looks like this could just be changed to Is that all it will take?
Sounds correct, yeah.
Cool great
Oops, I'm still learning git. Sorry for the spam there. Only is relevant.

Discussion:
} fn add_flags(&mut self, flags: TypeFlags) { <del> self.flags = self.flags | (flags & TypeFlags::NOMINAL_FLAGS); </del> <ins> self.flags = self.flags | flags; </ins> } /// indicates that `self` refers to something at binding level `binder`

/// Does this value have parameters/placeholders/inference variables which could be /// replaced later, in a way that would change the results of `impl` specialization? const STILL_FURTHER_SPECIALIZABLE = 1 << 18; <del> /// Flags representing the nominal content of a type, /// computed by FlagsComputation. If you add a new nominal /// flag, it should be added here too. const NOMINAL_FLAGS               = TypeFlags::HAS_TY_PARAM.bits | TypeFlags::HAS_RE_PARAM.bits | TypeFlags::HAS_CT_PARAM.bits | TypeFlags::HAS_TY_INFER.bits | TypeFlags::HAS_RE_INFER.bits | TypeFlags::HAS_CT_INFER.bits | TypeFlags::HAS_TY_".bits | TypeFlags::HAS_RE_".bits | TypeFlags::HAS_CT_".bits | TypeFlags::HAS_FREE_LOCAL_REGIONS.bits | TypeFlags::HAS_TY_PROJECTION.bits | TypeFlags::HAS_TY_OPAQUE.bits | TypeFlags::HAS_CT_PROJECTION.bits | TypeFlags::KEEP_IN_LOCAL_TCX.bits | TypeFlags::HAS_TY_ERR.bits | TypeFlags::HAS_FREE_REGIONS.bits | TypeFlags::HAS_RE_LATE_BOUND.bits | TypeFlags::HAS_RE_ERASED.bits | TypeFlags::STILL_FURTHER_SPECIALIZABLE.bits; </del> } }
Change:
The following code: produces: which reads as: any , which isn't realy true. It realy implements . Perhaps the error message should add a in front of the impl to make it more obvious, like this:
Hi , I'd like to take up this issue if it has not been assigned yet. However this would be my first contribution so I just want to confirm it's a good first task. Thanks!
Yeah, for sure! It should be as simple as updating () to account for the polarity. You can query/obtain the impl polarity with . Feel free to reach out here or on Zulip if you have any questions.

Discussion:
write!( w, <del> " {} for {}", </del> <ins> " {}{} for {}", tcx.impl_polarity(impl_def_id).as_str(), </ins> trait_ref.print_only_trait_path(), tcx.type_of(impl_def_id).instantiate_identity() )

} } <ins> impl ImplPolarity { /// The polarity marker in front of the impl trait ref if applicable. pub fn as_str(self) -> &'static str { match self { Self::Positive => "", Self::Negative => "!", Self::Reservation => "", } } } </ins> /// Polarity for a trait predicate. May either be negative or positive. /// Distinguished from [`ImplPolarity`] since we never compute goals with /// "reservation" level.

<ins> #![feature(negative_impls)] //@ edition: 2021 // Test to ensure we are printing the polarity of the impl trait ref // when printing out conflicting trait impls struct MyType; impl !Clone for &mut MyType {} //~^ ERROR conflicting implementations of trait `Clone` for type `&mut MyType` fn main() {} </ins>

<ins> error[E0119]: conflicting implementations of trait `Clone` for type `&mut MyType` --> $DIR/coherence-conflicting-repeated-negative-trait-impl-70849.rs:8:1 | LL | impl !Clone for &mut MyType {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: conflicting implementation in crate `core`: - impl<T> !Clone for &mut T where T: ?Sized; error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0119`. </ins>
Change:
If I run cargo doc on the below code, it never finishes. I expected to see it finish. Problem does not exist on stable
cc
Fixed upstream in , but not released yet.
Let's hope next version will be released soon then! :)
Unfortunately this also affects 1.43 beta.
Hm so this will hit stable in less than a week then. Do we consider it high priority enough to try to push through a release ourselves? (e.g. we can temporarily fork or whatever, perhaps only on the beta branch). I personally lean towards no but wouldn't be opposed to doing so if t-rustdoc wanted to.
This issue halted development at our company for a day until we bisected the issue down to the particular line of code (a comment) that was causing to hang indefinitely. Thank you for all of your hard work on Rust. It is my most favourite language. I've been waiting for a suitable replacement for C++, and it has arrived!
Looks like there's movement on a point release, I would be in favor of backporting this to beta, since it's a really painful bug to hit...
0.7.1 has been released.
Yea, PR to update is up at .

Discussion:
"if_chain", "itertools 0.9.0", "lazy_static 1.4.0", <del> "pulldown-cmark 0.7.0", </del> <ins> "pulldown-cmark 0.7.1", </ins> "quine-mc_cluskey", "regex-syntax", "semver",

[[package]] name = "pulldown-cmark" <del> version = "0.7.0" </del> <ins> version = "0.7.1" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "2c2d7fd131800e0d63df52aff46201acaab70b431a4a1ec6f0343fe8e64f35a4" </del> <ins> checksum = "3e142c3b8f49d2200605ee6ba0b1d757310e9e7a72afe78c36ee2ef67300ee00" </ins> dependencies = [ "bitflags", "memchr",

dependencies = [ "itertools 0.8.0", "minifier", <del> "pulldown-cmark 0.7.0", </del> <ins> "pulldown-cmark 0.7.1", </ins> "rustc-rayon", "serde", "serde_json",
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.

Discussion:
<del> Subproject commit 7907abea272bbf97812683ce03a1ab9c22f0557b </del> <ins> Subproject commit d342cee78703c46d9df09088f9fb99ba85d021ae </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.

Discussion:
<del> Subproject commit 147ea8f400de3ca529abcb5eb7b65f84a4896ae9 </del> <ins> Subproject commit 325682ad56d23369059ea93d5a8d44e5782e41cf </ins>
Change:
I was playing with while I encountered a The simplest example I have producing the bug is Here is . It works if I remove the struct and put the directly in . The complete backtrace is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimised ()
claim

Discussion:
.unwrap_or(false); let is_from = format!("{}", trait_ref.print_only_trait_path()) .starts_with("std::convert::From<"); <ins> let is_unsize = { Some(trait_ref.def_id()) == self.tcx.lang_items().unsize_trait() }; </ins> let (message, note) = if is_try && is_from { ( Some(format!(

return; } <ins> if is_unsize { // If the obligation failed due to a missing implementation of the // `Unsize` trait, give a pointer to why that might be the case err.note( "all implementations of `Unsize` are provided  automatically by the compiler, see  <https://doc.rust-lang.org/stable/std/marker/trait.Unsize.html>  for more information", ); } </ins> // Try to report a help message if !trait_ref.has_infer_types_or_consts() && self.predicate_can_apply(obligation.param_env, trait_ref)

let impl_candidates = self.find_similar_impl_candidates(trait_ref); self.report_similar_impl_candidates(impl_candidates, &mut err); } <del> self.suggest_change_mut( &obligation, &mut err, &trait_ref, points_at_arg, ); </del> <ins> // Changing mutability doesn't make a difference to whether we have // an `Unsize` impl (Fixes ICE in #71036) if !is_unsize { self.suggest_change_mut( &obligation, &mut err, &trait_ref, points_at_arg, ); } </ins> } // If this error is due to `!: Trait` not implemented but `(): Trait` is

<ins> #![feature(unsize, dispatch_from_dyn)] use std::marker::Unsize; use std::ops::DispatchFromDyn; #[allow(unused)] struct Foo<'a, T: ?Sized> { _inner: &'a &'a T, } impl<'a, T: ?Sized + Unsize<U>, U: ?Sized> DispatchFromDyn<Foo<'a, U>> for Foo<'a, T> {} //~^ ERROR the trait bound `&'a T: std::marker::Unsize<&'a U>` is not satisfied //~| NOTE the trait `std::marker::Unsize<&'a U>` is not implemented for `&'a T` //~| NOTE all implementations of `Unsize` are provided automatically by the compiler //~| NOTE required because of the requirements on the impl fn main() {} </ins>

<ins> error[E0277]: the trait bound `&'a T: std::marker::Unsize<&'a U>` is not satisfied --> $DIR/issue-71036.rs:11:1 | LL | impl<'a, T: ?Sized + Unsize<U>, U: ?Sized> DispatchFromDyn<Foo<'a, U>> for Foo<'a, T> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::marker::Unsize<&'a U>` is not implemented for `&'a T` | = note: all implementations of `Unsize` are provided automatically by the compiler, see <https://doc.rust-lang.org/stable/std/marker/trait.Unsize.html> for more information = note: required because of the requirements on the impl of `std::ops::DispatchFromDyn<&'a &'a U>` for `&'a &'a T` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>
Change:
ICE message: <details<summaryBacktrace</summary</summary
This should be erroring in exhaustiveness checking; shouldn't be allowed there. cc
It should be erroring earlier, when trying to create a pattern out of the constant. And it should also not be considered structural-match type-wise.
Triage: This is no longer ICE, seems that it's fixed by , marking as E-needs-test.

Discussion:
<ins> // Regression test for https://github.com/rust-lang/rust/issues/56445#issuecomment-629426939 // check-pass #![crate_type = "lib"] use std::marker::PhantomData; pub struct S<'a> { pub m1: PhantomData<&'a u8>, pub m2: [u8; S::size()], } impl<'a> S<'a> { pub const fn size() -> usize { 1 } pub fn new() -> Self { Self { m1: PhantomData, m2: [0; Self::size()], } } } </ins>

<ins> // check-pass pub struct A<'a>(&'a ()); impl<'a> A<'a> { const N: usize = 68; pub fn foo(&self) { let _b = [0; Self::N]; } } fn main() {} </ins>

<ins> #![feature(impl_trait_in_bindings)] #![allow(incomplete_features)] fn main() { const C: impl Copy = 0; match C { C | _ => {} //~ ERROR: opaque types cannot be used in patterns } } </ins>

<ins> error: opaque types cannot be used in patterns --> $DIR/issue-71042-opaquely-typed-constant-used-in-pattern.rs:7:9 | LL |         C | _ => {} |         ^ error: aborting due to previous error </ins>

<ins> // check-pass #![feature(type_alias_impl_trait)] pub type Successors<'a> = impl Iterator<Item = &'a ()>; pub fn f<'a>() -> Successors<'a> { None.into_iter() } pub trait Tr { type Item; } impl<'a> Tr for &'a () { type Item = Successors<'a>; } pub fn kazusa<'a>() -> <&'a () as Tr>::Item { None.into_iter() } fn main() {} </ins>
Change:
Note to self (or whoever wants to help out); the following should be as a test case in : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hi, I would like to work on this.
assign

Discussion:
<ins> // check-pass #![feature(type_alias_impl_trait)] type A = impl Sized; fn f1() -> A { 0 } type B = impl ?Sized; fn f2() -> &'static B { &[0] } type C = impl ?Sized + 'static; fn f3() -> &'static C { &[0] } type D = impl ?Sized; fn f4() -> &'static D { &1 } fn main() {} </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.

Discussion:
"cargo_metadata 0.9.1", "clippy-mini-macro-test", "clippy_lints", <del> "compiletest_rs", </del> <ins> "compiletest_rs 0.5.0", </ins> "derive-new", "lazy_static 1.4.0", "regex",

] [[package]] <ins> name = "compiletest_rs" version = "0.5.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "9f737835bfbbe29ed1ff82d5137520338d7ed5bf1a1d4b9c1c7c58bb45b8fa29" dependencies = [ "diff", "filetime", "getopts", "libc", "log", "miow 0.3.3", "regex", "rustfix 0.5.0", "serde", "serde_derive", "serde_json", "tempfile", "tester", "winapi 0.3.8", ] [[package]] </ins> name = "constant_time_eq" version = "0.1.3" source = "registry+https://github.com/rust-lang/crates.io-index"

"byteorder", "cargo_metadata 0.9.1", "colored", <del> "compiletest_rs", </del> <ins> "compiletest_rs 0.4.0", </ins> "directories", "env_logger 0.7.1", "getrandom",

<del> Subproject commit af5940b73153b2a4ea2922aa803abac45d029982 </del> <ins> Subproject commit 6651c1b9b2a1b3e995565467218ff7eca7479c5e </ins>
Change:
Running results in all tools built, even though I asked for one, using the following : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hm, so this was originally only for the use case (it's even somewhat explicitly specified as such in the docs above in ). If chosen tool failed to build the installation fails. If , this option is ignored. Did you actually want this to work? (Or just pointing out an inconsistency?) Generally speaking x.py build without arguments is essentially never what you really want IMO, it's too broad -- I would recommend always passing a specific thing to build, in this case it looks like you want src/tools/rustfmt as the flag.
I expected only the specified to get built, but I guess I also glossed over the word. Needs an update perhaps... it's not so clear. Maybe following would be better: Replacing
My confusion could also be coming from this snippet, which talks about building
claim

Discussion:
fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; <del> run.path($path).default_condition(builder.config.extended) </del> <ins> run.path($path).default_condition( builder.config.extended && builder.config.tools.as_ref().map_or(true, |tools| { tools.iter().any(|tool| match tool.as_ref() { "clippy" => $tool_name == "clippy-driver", x => $tool_name == x, }) }), ) </ins> } fn make_run(run: RunConfig<'_>) {
Change:
According to my CI this started 2020-04-16 (https://travis-) - : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reports a regression in (PR ), cc
Assigning as and removing .
assign
Oh dear, I was hoping crater will find all such issues (this is ). I guess nobody in the wild is pattern-matching tuples with non-literal-length arrays. I can repro by adding this line () to the test (and the PR fixing this should IMO add the line to ): The fix is likely trivial: add another normalization, like in Presumably, for field accesses, this time (weird that doesn't trigger the bug). <hr/I've brought it up before w/ (but I don't know if I've seen a response), that the lack of normalization for array lengths in typeck is pushing complexity to the rest of the compiler and maybe we should do it in typeck. But then again, Lazy Normalization Is Coming, so maybe there's no point.
I believe I responded in the PR where you already asked me about that. I'm fine reintroducing a normalization phase

Discussion:
let fty = self.sanitize_type(place, fty); match self.field_ty(place, base, field, location) { Ok(ty) => { <ins> let ty = self.cx.normalize(ty, location); </ins> if let Err(terr) = self.cx.eq_types( ty, fty,

fn foo<'a>() -> &'a () { Hash([0; HASH_LEN]); init_hash(&mut [0; HASH_LEN]); <ins> let (_array,) = ([0; HASH_LEN],); </ins> &() }
Change:
I'm running macOS 10.15.3. Starting in the 3/26 nightly, running applications and tests that panic with RUST_BACKTRACE=1 frequently results in a segfault: The backtrace from this shows libbacktrace: Since merged as part of which merged on March 25, there's a pretty clear candidate for the regression.
I found this as part of Servo's unit test suite, which now has intermittent segfaults in #[should_panic] tests on CI with nightlies since 3/26. I've also reproduced this by adding a panic!() in , but I haven't yet been able to create a standalone unit test that demonstrates the issue.
It looks like the code that is crashing was introduced as part of , which was brought in as part of the submodule update in
Here's a standalone testcase that reproduces the problem for me:
I have a suspicion that my testcase only works because of right now.
Can you open an issue on ?
Filed
reports that pulling in an updated backtrace-rs to rustc should fix this.
I think I am getting this on a stable rustc 1.44.0 ( 2020-06-01) on macOS 10.15.5. Initially, I caught a segfault for a test code that panics. when I tried to launch the same code under lldd it panicked properly (I tried a dozen of times). Then, another test run has led to a stall. /usr/bin/sample for the process showed this: which led me to this issue.
I think the fix for this isn't in 1.44, it should be in 1.45, though. Can you test to see if the issue is fixed on beta?
I tried to rebuild and re-run the test and I couldn't reproduce this issue again with beta!

Discussion:
[[package]] name = "backtrace-sys" <del> version = "0.1.35" </del> <ins> version = "0.1.36" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "7de8aba10a69c8e8d7622c5710229485ec32e9d55fdad160ea559c086fdcd118" </del> <ins> checksum = "78848718ee1255a2485d1309ad9cdecfc2e7d0362dd11c6829364c6b35ae1bc7" </ins> dependencies = [ "cc", "compiler_builtins",
Change:
This (very contrived) example emits a warning: Playground: This is a false positive because removing results in a compilation error: Same for and .
It seems this regressed somewhere between 1.34.0 and 1.35.0
More accurately, it looks like the false positive has been present since the introduction of the warning in
I was actually a little surprised that did not cause a compilation error due to two imports of the same name at the same level.
I got something similar while implementing ops::Div when removed, it errors
This issue no longer reproduces and can be closed when a corresponding test is .

Discussion:
<ins> //@ check-pass #![warn(unused_imports)] mod foo { use std::fmt; pub struct String; impl String { pub fn new() -> String { String{} } } impl fmt::Display for String { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "String") } } } fn main() { { use std::string::String; //~ WARNING the item `String` is imported redundantly // 'String' from 'std::string::String'. let s = String::new(); println!("{}", s); } { // 'String' from 'std::string::String'. let s = String::new(); println!("{}", s); } { use foo::*; // 'String' from 'foo::String'. let s = String::new(); println!("{}", s); } } </ins>

<ins> warning: the item `String` is imported redundantly --> $DIR/use-redundant-issue-71450.rs:26:13 | LL |         use std::string::String; |             ^^^^^^^^^^^^^^^^^^^ --> $SRC_DIR/std/src/prelude/mod.rs:LL:COL | = note: the item `String` is already defined here | note: the lint level is defined here --> $DIR/use-redundant-issue-71450.rs:3:9 | LL | #![warn(unused_imports)] |         ^^^^^^^^^^^^^^ warning: 1 warning emitted </ins>

<ins> //@ check-pass //@ edition:2018 #![warn(unused_imports)] mod foo { macro_rules! foo1 { () => (); } pub(crate) use foo1; } fn main () { bar!(); macro_rules! bar { () => (); } use bar; mod m { bar1!(); macro_rules! bar1 { () => (); } use bar1; } { foo::foo1!(); } { use foo::foo1; foo1!(); } { use foo::foo1; //~ WARNING unused import: `foo::foo1` foo::foo1!(); } } </ins>

<ins> warning: unused import: `foo::foo1` --> $DIR/use-redundant-issue-78894.rs:44:13 | LL |         use foo::foo1; |             ^^^^^^^^^ | note: the lint level is defined here --> $DIR/use-redundant-issue-78894.rs:4:9 | LL | #![warn(unused_imports)] |         ^^^^^^^^^^^^^^ warning: 1 warning emitted </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.

Discussion:
<del> Subproject commit 891e1a859b52486936e021235fdc36fbdd9b4100 </del> <ins> Subproject commit b7c802b5e33f5a402de3780bc5a8b05e7ebad409 </ins>