jiebi/CodeConvo huggingface dataset:
Change:
Missing a trait bound for the trait that defines below: Results in the following suggestion with an extra colon after the plus.
you can look at and for inspiration on how to deal with this.
I came up with a different solution, but there may be a subtlety I'm missing:

Discussion:
// Get the `hir::Param` to verify whether it already has any bounds. // We do this to avoid suggesting code that ends up as `T: FooBar`, // instead we suggest `T: Foo + Bar` in that case. <del> let mut has_bounds = false; </del> <ins> let mut has_bounds = None; </ins> let mut impl_trait = false; if let Node::GenericParam(ref param) = hir.get(id) { <del> match param.kind { hir::GenericParamKind::Type { synthetic: Some(_), .. } => { // We've found `fn foo(x: impl Trait)` instead of // `fn foo<T>(x: T)`. We want to suggest the correct // `fn foo(x: impl Trait + TraitBound)` instead of // `fn foo<T: TraitBound>(x: T)`. (#63706) impl_trait = true; has_bounds = param.bounds.len() > 1; } _ => { has_bounds = !param.bounds.is_empty(); } </del> <ins> let kind = &param.kind; if let hir::GenericParamKind::Type { synthetic: Some(_), .. } = kind { // We've found `fn foo(x: impl Trait)` instead of // `fn foo<T>(x: T)`. We want to suggest the correct // `fn foo(x: impl Trait + TraitBound)` instead of // `fn foo<T: TraitBound>(x: T)`. (See #63706.) impl_trait = true; has_bounds = param.bounds.get(1); } else { has_bounds = param.bounds.get(0); </ins> } } let sp = hir.span(id); <del> // `sp` only covers `T`, change it so that it covers // `T:` when appropriate let sp = if has_bounds { sp.to(self.tcx .sess .source_map() .next_point(self.tcx.sess.source_map().next_point(sp))) </del> <ins> // `sp` only covers `T`, change it so that it covers `T:` when appropriate. let sp = if let Some(first_bound) = has_bounds { sp.until(first_bound.span()) </ins> } else { sp };

param, if impl_trait { " +" } else { ":" }, self.tcx.def_path_str(t.def_id), <del> if has_bounds { " +"} else { "" }, </del> <ins> if has_bounds.is_some() { " + " } else { "" }, </ins> )), Applicability::MaybeIncorrect, );

<ins> trait Foo { fn foo(&self); } trait Bar {} fn do_stuff<T : Bar>(t : T) { t.foo() //~ ERROR no method named `foo` found for type `T` in the current scope } fn main() {} </ins>

<ins> error[E0599]: no method named `foo` found for type `T` in the current scope --> $DIR/issue-65284-suggest-generic-trait-bound.rs:8:7 | LL |     t.foo() |       ^^^ method not found in `T` | = help: items from traits can only be used if the type parameter is bounded by the trait help: the following trait defines an item `foo`, perhaps you need to restrict type parameter `T` with it: | LL | fn do_stuff<T: Foo + Bar>(t : T) { |             ^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>
Change:
The following ICE's on nightly only: <details<summaryBacktrace:</summary</detailsThis ICE is the same as reported in , however the example given there currently runs fine without any errors.
cc
As the OP notes, this is closely related to . To fix that problem, zero-length arrays were special-cased so that they are never marked as indirectly mutable. However, this did not extend to projections of zero-length arrays. When compiling this code, the analysis sees a reference being taken to a place of type , which it cannot assume is . I should be able to make the validation passes agree in this particular case by checking the type of the target of each projection along the borrowed place, suppressing the indirectly mutable annotation for the base local if any of those types are a zero-sized array. It's unfortunate that we have to treat and differently here, but obviously backwards compatibility must be preserved. I wonder if there's a different way to handle this. It seems like should return for an empty array?

Discussion:
ty::UnnormalizedProjection(..) => bug!("only used with chalk-engine"), <ins> // Zero-length arrays never contain anything to drop. ty::Array(_, len) if len.try_eval_usize(tcx, param_env) == Some(0) => false, </ins> // Structural recursion. ty::Array(ty, _) | ty::Slice(ty) => needs_drop(ty),

kind: mir::BorrowKind, borrowed_place: &mir::Place<'tcx>, ) -> bool { <del> let borrowed_ty = borrowed_place.ty(self.body, self.tcx).ty; // Zero-sized types cannot be mutated, since there is nothing inside to mutate. // // FIXME: For now, we only exempt arrays of length zero. We need to carefully // consider the effects before extending this to all ZSTs. if let ty::Array(_, len) = borrowed_ty.kind { if len.try_eval_usize(self.tcx, self.param_env) == Some(0) { return false; } } </del> match kind { mir::BorrowKind::Mut { .. } => true, | mir::BorrowKind::Shared | mir::BorrowKind::Shallow | mir::BorrowKind::Unique <del> => !borrowed_ty.is_freeze(self.tcx, self.param_env, DUMMY_SP), </del> <ins> => !borrowed_place .ty(self.body, self.tcx) .ty .is_freeze(self.tcx, self.param_env, DUMMY_SP), </ins> } } }

<ins> // check-pass struct Generic<T>(T); impl<T> Generic<T> { const ARRAY: [T; 0] = []; const NEWTYPE_ARRAY: Generic<[T; 0]> = Generic([]); const ARRAY_FIELD: Generic<(i32, [T; 0])> = Generic((0, [])); } pub const fn array<T>() ->  &'static T { &Generic::<T>::ARRAY[0] } pub const fn newtype_array<T>() ->  &'static T { &Generic::<T>::NEWTYPE_ARRAY.0[0] } pub const fn array_field<T>() ->  &'static T { &(Generic::<T>::ARRAY_FIELD.0).1[0] } fn main() {} </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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! cc the PR reviewer, and nominating for compiler team prioritization.
Yeah, I will try to figure out how to fix .
Sorry, saw this issue after the fact - If Miri is failing because of the renamed testopt, I have a PR for compiletest-rs open with a potential fix:
Sure, no problem.
We had avoided the "nightly" feature of compiletest-rs in Miri exactly because of this... But recently enabled it again due to other failures. Should we rather try to use the stable variant again?
Both variants are currently not working: should fix the nightly variant fixes the stable variant

Discussion:
[[package]] name = "compiletest_rs" <del> version = "0.3.23" </del> <ins> version = "0.3.24" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "eb783fe7afb90ec3d3e49ccaf9196d29ab63c6ed61d4b0695839daa580ae3a3d" </del> <ins> checksum = "676a74b493d50ac33cacd83fd536597e6b52c0b46b9856f7b9c809d82fef4ac0" </ins> dependencies = [ "diff", "filetime",

<del> Subproject commit 07ac10277ea5ad42efbb914da5844e0ab08efbf4 </del> <ins> Subproject commit 2adc39f27b7fd2d06b3d1d470827928766731a1d </ins>
Change:
As requested in , here's a follow up. The following code below implements the trait for an alias , which is an alias to . It doesnt really make sense to implement a that same trait. doesn't mention anything about this, however the previous notes: Im not sure this should be allowed. cc
This is fixed on master.

Discussion:
<ins> #![feature(min_type_alias_impl_trait)] #![feature(type_alias_impl_trait)] #![allow(incomplete_features)] trait MyTrait {} impl MyTrait for () {} type Bar = impl MyTrait; impl MyTrait for Bar {} //~^ ERROR: cannot implement trait on type alias impl trait fn bazr() -> Bar { } fn main() {} </ins>

<ins> error: cannot implement trait on type alias impl trait --> $DIR/issue-65384.rs:11:1 | LL | impl MyTrait for Bar {} | ^^^^^^^^^^^^^^^^^^^^ | note: type alias impl trait defined here --> $DIR/issue-65384.rs:9:12 | LL | type Bar = impl MyTrait; |            ^^^^^^^^^^^^ error: aborting due to previous error </ins>
Change:
While compiling rayon:
cc
triage: P-high, assigning to . Removing nomination label.
The fact that this bug was unknown until now strikes me as a sign that we have never attempted to run on the rustc test suite (i.e. compiletest). is this true? Would it be worthwhile to attempt that experiment?
I'm not sure if this is the correct approach, but I just executed the with the following patch applied: and the test suite did crash/ended up all green. It might be a good idea to always run the tests along with save-analysis passed. Should that be optionally enabled? Should we run it, e.g. in the container?

Discussion:
} } } <del> self.visit_ty(&typ); if let &Some(ref trait_ref) = trait_ref { self.process_path(trait_ref.ref_id, &trait_ref.path); } self.process_generic_params(generics, "", item.id); for impl_item in impl_items { let map = &self.tcx.hir(); self.process_impl_item(impl_item, map.local_def_id_from_node_id(item.id)); } </del> <ins> let map = &self.tcx.hir(); self.nest_tables(item.id, |v| { v.visit_ty(&typ); if let &Some(ref trait_ref) = trait_ref { v.process_path(trait_ref.ref_id, &trait_ref.path); } v.process_generic_params(generics, "", item.id); for impl_item in impl_items { v.process_impl_item(impl_item, map.local_def_id_from_node_id(item.id)); } }); </ins> } fn process_trait(

<ins> // check-pass // compile-flags: -Zsave-analysis trait Trait { type Assoc; } trait GenericTrait<T> {} struct Wrapper<B> { b: B } fn func() { // Processing associated path in impl block definition inside a function // body does not ICE impl<B: Trait> GenericTrait<B::Assoc> for Wrapper<B> {} } fn main() {} </ins>
Change:
I get the following internal compiler error with rustc nightly: To reproduce, just checkout the repo at the following commit: Run:
Can you please provide a minimized example that would fit in the playground without any dependencies? We would also appreciate a backtrace.
Sorry for forgetting the backtrace, here we go: Regarding a minimized example, I would really like to provide you one, but I did not change any code. I just updated the nightly compiler. The latest stable compiles this code without any problems.
Sure; it's just substantially more difficult to fix a bug when the input is large as compared to just a few lines of code you can put in a file (and in the playground!). :) Reports with a minimal snippet tend to get fixed much faster and we sorta need a regression test as well.
cc
Did you try the beta compiler? Does it work there?
Okay, I tried to find the problem and to reproduce it. I failed at reproducing :( However, I found the line If I remove this call to it does not crash. This call is implemented in the following monstrous impl block: I somehow suspect that the where clause could be the reason for it. Sorry for not being able to reduce it anymore! I'm currently testing the beta channel and will report back when I know more.
Beta works for me.
I downgraded to "rustc 1.40.0-nightly ( 2019-10-13)" and that compiles the crate without any problems.
triage: P-high. self-assigning. removing nomination tag.
Minimal example: . It works on stable and on beta; it ICEs on nightly.
Curiously this does not reproduce with instead of . cc
I believe this is an assert at my request - it already existed in miri, but was missing from the original implementation in .
can we remove the assertion for now?
Oops, this slipped into beta ( was on vacation and I forgot about it completely).
(to be fair, it was assigned to me, and I just kept letting it slip on my own priority list as well...)
reassigning to based on feedback from compiler team
This regressed

Discussion:
pub fn offset(&self, i: usize) -> Size { match *self { <del> FieldPlacement::Union(count) => { assert!(i < count, "Tried to access field {} of union with {} fields", i, count); Size::ZERO }, </del> <ins> FieldPlacement::Union(_) => Size::ZERO, </ins> FieldPlacement::Array { stride, count } => { let i = i as u64; assert!(i < count);

<ins> // build-pass enum Empty {} enum Enum { Empty( Empty ) } fn foobar() -> Option< Enum > { let value: Option< Empty > = None; Some( Enum::Empty( value? ) ) } fn main() { foobar(); } </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! cc the PR reviewer, and nominating for compiler team prioritization.

Discussion:
// (We do this separately from the above so that when the setup actually // happens we get some output.) // We re-use the `cargo` from above. <del> cargo.arg("--env"); </del> <ins> cargo.arg("--print-sysroot"); </ins> // FIXME: Is there a way in which we can re-use the usual `run` helpers? let miri_sysroot = if builder.config.dry_run {

let out = cargo.output() .expect("We already ran `cargo miri setup` before and that worked"); assert!(out.status.success(), "`cargo miri setup` returned with non-0 exit code"); <del> // Output is "MIRI_SYSROOT=<str>n". </del> <ins> // Output is "<sysroot>n". </ins> let stdout = String::from_utf8(out.stdout) .expect("`cargo miri setup` stdout is not valid UTF-8"); <del> let stdout = stdout.trim(); builder.verbose(&format!("`cargo miri setup --env` returned: {:?}", stdout)); let sysroot = stdout.splitn(2, '=') .nth(1).expect("`cargo miri setup` stdout did not contain '='"); </del> <ins> let sysroot = stdout.trim_end(); builder.verbose(&format!("`cargo miri setup --print-sysroot` said: {:?}", sysroot)); </ins> sysroot.to_owned() };

<del> Subproject commit 2adc39f27b7fd2d06b3d1d470827928766731a1d </del> <ins> Subproject commit fccb2398248802a268fcda544ff3945247ef2119 </ins>
Change:
The following code () panics the compiler in stable 1.38.0, beta 1.39.0-beta.6, and nightly 2019-10-17: Removing the bound or filling it with makes it compile just fine. Error + backtrace:
cc
Hmm, I didn't know that adding a "syntactically trivial bound" could cause something like this. Is there some implicit bound that gets in cases like this?
minimized test case ():
The minimized test worked in previous stable Rust versions (at least in 1.33 under 2015 edition; though 2018 edition breaks there, which indicates this is with 99.999% certainty injected by MIR-borrowck...)
triage: P-high. Adding self to assignee list; removing I-nominated.

Discussion:
a: ty::Region<'tcx>, b: ty::Region<'tcx>, ) { <ins> if let ty::ReEmpty = a { return; } </ins> let b = self.to_region_vid(b); let a = self.to_region_vid(a); self.add_outlives(b, a);

a: ty::Region<'tcx>, bound: VerifyBound<'tcx>, ) { <ins> if let ty::ReEmpty = a { return; } </ins> let type_test = self.verify_to_type_test(kind, a, bound); self.add_type_test(type_test); }

<ins> // Regression test for #65553 // // `D::Error:` is lowered to `D::Error: ReEmpty` - check that we don't ICE in // NLL for the unexpected region. // check-pass trait Deserializer { type Error; } fn d1<D: Deserializer>() where D::Error: {} fn d2<D: Deserializer>() { d1::<D>(); } fn main() {} </ins>

// `dyn T:` is lowered to `dyn T: ReEmpty` - check that we don't ICE in NLL for // the unexpected region. <del> // build-pass (FIXME(62277): could be check-pass?) </del> <ins> // check-pass </ins> trait T {} fn f() where dyn T: {} <del> fn main() {} </del> <ins> fn main() { f(); } </ins>
Change:
In some documentation that I recently wrote, I had an inline code block that has a leading space. This is rendered as — notice the lack of a leading space. Given that the documentation in question is literally to show how a leading space is , and given that code blocks otherwise display content as-is, this seems like a bug to me. Reference for full source code in case this behavior isn't consistent:
Thanks for opening this issue I moved this issue from to as this is a rustdoc bug ( just calls rustdoc to build the documentation).
Thanks! Wasn't sure if rustdoc had its own repo.
Fix is in
Thanks
As discussed in , better keep it as is and let users decide what they want on their own.

Discussion:
text-overflow: ellipsis; margin: 0; } <del> .docblock-short code { </del> <ins> .docblock code, .docblock-short code { </ins> white-space: pre-wrap; }
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! cc the PR reviewer, and nominating for compiler team prioritization.

Discussion:
<del> Subproject commit e979eb4cc55ffd357158c7d30133cbf894e93fe9 </del> <ins> Subproject commit cbedd97b3a58023eff365a2fa74700d06115144a </ins>
Change:
Missing external modules don't report a build error when a crate is built from stdin. Expected: When parsing an external submodule from stdin, a compiler error (or warning) is emitted noting that external submodules are not supported for stdio crates. Actual: No diagnostics are emitted and an empty submodule is implicitly inserted. Generally if a statement references a file which does not exist, an E0583 compile error will be emitted. However, when building a crate from stdin, no relative filesystem is present, yet no compile errors are emitted, even with explicit attributes. Instead they are implicitly substituted with empty inline modules. I'm not super familiar with rustc, so this might not be handy, but I'm guessing this is caused by the flag being unset when parsing from a string rather than a file ( - rather than trying to access the filesystem or emit an error during the parse.
This was fixed in nightly-2020-03-20, probably by I don't think this is worth adding a regression test for this TBH, so I think we should simply close this issue. It remains fixed in current stable (1.71).
On a second thought the right way to close this issue is probably by writing a regression test after all. Otherwise the bug can re-appear. I was being too lazy. Edit: Fix: label E-needs-test

Discussion:
<ins> # ignore-windows include ../tools.mk all: echo 'mod unknown;' | $(RUSTC) --crate-type rlib - >$(TMPDIR)/unknown-mod.stdout 2>$(TMPDIR)/unknown-mod.stderr || echo "failed successfully" # Bless like this: RUSTC_BLESS_TEST=1 ./x.py test tests/run-make/unknown-mod-stdin ifdef RUSTC_BLESS_TEST cp "$(TMPDIR)"/unknown-mod.stdout unknown-mod.stdout cp "$(TMPDIR)"/unknown-mod.stderr unknown-mod.stderr else $(DIFF) unknown-mod.stdout "$(TMPDIR)"/unknown-mod.stdout $(DIFF) unknown-mod.stderr "$(TMPDIR)"/unknown-mod.stderr endif </ins>

<ins> error[E0583]: file not found for module `unknown` --> <anon>:1:1 | 1 | mod unknown; | ^^^^^^^^^^^^ | = help: to create the module `unknown`, create file "unknown.rs" or "unknown/mod.rs" error: aborting due to previous error For more information about this error, try `rustc --explain E0583`. </ins>
Change:
The compiler correctly errors about the ambiguous types, but also panics on this code:
Also reproduces on nightly. Panic happens here:
triage: P-medium. removing nomination label. reasoning: has a PR. tagging as P-medium (since it does produce useful error message before ICE'ing), and removing nomination label.

Discussion:
/////////////////////////////////////////////////////////////////////////// // ADJUSTMENTS <del> fn adjust_self_ty(&mut self, unadjusted_self_ty: Ty<'tcx>, pick: &probe::Pick<'tcx>) -> Ty<'tcx> { </del> <ins> fn adjust_self_ty( &mut self, unadjusted_self_ty: Ty<'tcx>, pick: &probe::Pick<'tcx>, ) -> Ty<'tcx> { </ins> // Commit the autoderefs by calling `autoderef` again, but this // time writing the results into the various tables. let mut autoderef = self.autoderef(self.span, unadjusted_self_ty); <del> let (_, n) = autoderef.nth(pick.autoderefs).unwrap(); </del> <ins> let (_, n) = match autoderef.nth(pick.autoderefs) { Some(n) => n, None => { self.tcx.sess.delay_span_bug( syntax_pos::DUMMY_SP, &format!("failed autoderef {}", pick.autoderefs), ); return self.tcx.types.err; } }; </ins> assert_eq!(n, pick.autoderefs); let mut adjustments = autoderef.adjust_steps(self, Needs::None);

<ins> use std::mem::MaybeUninit; use std::ops::Deref; pub unsafe trait Array { /// The array’s element type type Item; #[doc(hidden)] /// The smallest index type that indexes the array. type Index: Index; #[doc(hidden)] fn as_ptr(&self) -> *const Self::Item; #[doc(hidden)] fn as_mut_ptr(&mut self) -> *mut Self::Item; #[doc(hidden)] fn capacity() -> usize; } pub trait Index : PartialEq + Copy { fn to_usize(self) -> usize; fn from(usize) -> Self; } impl Index for usize { fn to_usize(self) -> usize { self } fn from(val: usize) -> Self { val } } unsafe impl<T> Array for [T; 1] { type Item = T; type Index = usize; fn as_ptr(&self) -> *const T { self as *const _ as *const _ } fn as_mut_ptr(&mut self) -> *mut T { self as *mut _ as *mut _} fn capacity() -> usize { 1 } } impl<A: Array> Deref for ArrayVec<A> { type Target = [A::Item]; #[inline] fn deref(&self) -> &[A::Item] { panic!() } } pub struct ArrayVec<A: Array> { xs: MaybeUninit<A>, len: usize, } impl<A: Array> ArrayVec<A> { pub fn new() -> ArrayVec<A> { panic!() } } fn main() { let mut buffer = ArrayVec::new(); let x = buffer.last().unwrap().0.clone(); //~^ ERROR type annotations needed //~| ERROR no field `0` on type `&_` buffer.reverse(); } </ins>

<ins> error[E0282]: type annotations needed --> $DIR/issue-65611.rs:59:20 | LL |     let x = buffer.last().unwrap().0.clone(); |                    ^^^^ cannot infer type for `T` | = note: type must be known at this point error[E0609]: no field `0` on type `&_` --> $DIR/issue-65611.rs:59:36 | LL |     let x = buffer.last().unwrap().0.clone(); |                                    ^ error: aborting due to 2 previous errors Some errors have detailed explanations: E0282, E0609. For more information about an error, try `rustc --explain E0282`. </ins>
Change:
Consider the following code samples: (1) (2) Code example number (2) looks much prettier than code example (1) but is incorrect, as it returns a dynamically sized array. The code returns a dynamically sized array because the objects array is coerced to a dynamically sized array, and then the map method is called on the dynamic array. Can some method of making code sample number (2) happen be implemented? Right now, the behaviour is unintuitive, and annoying.
I'm not sure this is practical without some sort of dependent types, but in any case, nominating for milestone 1 (well-defined) so we can decide.
Maybe some kind of kind could be ? For example,
The method on vectors is marked as deprecated in and will be replaced by the iterator form of . There's currently no way to implement methods on fixed-size arrays, so the issue here is .

Discussion:
unsafe fn initializer(&self) -> Initializer { let initializer = self.first.initializer(); <del> if initializer.should_initialize() { initializer } else { self.second.initializer() } </del> <ins> if initializer.should_initialize() { initializer } else { self.second.initializer() } </ins> } }

} fn consume(&mut self, amt: usize) { <del> if !self.done_first { self.first.consume(amt) } else { self.second.consume(amt) } </del> <ins> if !self.done_first { self.first.consume(amt) } else { self.second.consume(amt) } </ins> } }

}; } } <ins> default fn size_hint(&self) -> (usize, Option<usize>) { (&self.inner as &SizeHint).size_hint() } } #[stable(feature = "bufreader_size_hint", since = "1.51.0")] trait SizeHint { fn lower_bound(&self) -> usize; fn upper_bound(&self) -> Option<usize> { None } fn size_hint(&self) -> (usize, Option<usize>) { (self.lower_bound(), self.upper_bound()) } } #[stable(feature = "bufreader_size_hint", since = "1.51.0")] impl<T> SizeHint for T { default fn lower_bound(&self) -> usize { 0 } } #[stable(feature = "bufreader_size_hint", since = "1.51.0")] impl<T> SizeHint for BufReader<T> { fn lower_bound(&self) -> usize { self.buffer().len() } </ins> } /// An iterator over the contents of an instance of `BufRead` split on a