jiebi/CodeConvo huggingface dataset:
Code change:
There are many situations in which we wind up reporting duplicate errors during trait matching and elsewhere. You can see this in many of the compile-fail tests which wind up with the same error several times. These messages often arise naturally because multiple parts of the code give rise to the same obligation, and because of type inference, which can make it hard to tell whether two trait obligations are in fact the same until it is too late. (In fact, we already silently drop two EXACT DUPLICATE obligations for various other reasons). I think the best thing is just to add some sort of hashset and check for duplicates in or maybe . But we should do this check after doing full type resolution. I am not sure whether to consider the spans. On the one hand, getting the same error for every line where it occurs is useful, and it can be confusing if you get an error from line A but not B even though they seem identical. This may lead you to think that B is somehow ok, when in fact the compiler was just helpfully suppressing a duplicate error. On the other hand, we already some amount of suppression like that, so the situation above can already arise, and perhaps being more consistent would wind up being less confusing overall.
Marking as mentor.
Is there something left to do here? it seems like fix for does the thing suggested in this ticket.
Closing per .

Related discussion:
text: <ins> // Copyright 2015 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. trait Array: Sized {} fn f<T: Array>(x: &T) { let _ = x //~^ ERROR `Array` cannot be made into an object //~| NOTE the trait cannot require that `Self : Sized` as &Array; //~^ ERROR `Array` cannot be made into an object //~| NOTE the trait cannot require that `Self : Sized` } fn main() {} </ins>
Code change:
On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.

Related discussion:
text: projection_ty: projection_ty, ty: ty_var }); <del> let obligation = Obligation::with_depth(cause, depth+1, projection.to_predicate()); </del> <ins> let obligation = Obligation::with_depth( cause, depth + 1, projection.to_predicate()); </ins> Normalized { value: ty_var, obligations: vec!(obligation)
Code change:
On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.

Related discussion:
text: obligations); if projected_ty.has_projection_types() { <del> let mut normalizer = AssociatedTypeNormalizer::new(selcx, cause, depth); </del> <ins> let mut normalizer = AssociatedTypeNormalizer::new(selcx, cause, depth+1); </ins> let normalized_ty = normalizer.fold(&projected_ty); debug!("normalize_projection_type: normalized_ty={:?} depth={}",
Code change:
On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.

Related discussion:
text: /// contexts around the same size. n_llvm_insns: Cell<usize>, <ins> /// Depth of the current type-of computation - used to bail out type_of_depth: Cell<usize>, </ins> trait_cache: RefCell<FnvHashMap<ty::PolyTraitRef<'tcx>, traits::Vtable<'tcx, ()>>>, }
Code change:
On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.

Related discussion:
text: unwind_resume_hooked: Cell::new(false), intrinsics: RefCell::new(FnvHashMap()), n_llvm_insns: Cell::new(0), <ins> type_of_depth: Cell::new(0), </ins> trait_cache: RefCell::new(FnvHashMap()), };
Code change:
On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.

Related discussion:
text: obj)) } <ins> pub fn enter_type_of(&self, ty: Ty<'tcx>) -> TypeOfDepthLock<'b, 'tcx> { let current_depth = self.local.type_of_depth.get(); debug!("enter_type_of({:?}) at depth {:?}", ty, current_depth); if current_depth > self.sess().recursion_limit.get() { self.sess().fatal( &format!("overflow representing the type `{}`", ty)) } self.local.type_of_depth.set(current_depth + 1); TypeOfDepthLock(self.local) } </ins> pub fn check_overflow(&self) -> bool { self.shared.check_overflow }
Code change:
On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.

Related discussion:
text: } } <ins> pub struct TypeOfDepthLock<'a, 'tcx: 'a>(&'a LocalCrateContext<'tcx>); impl<'a, 'tcx> Drop for TypeOfDepthLock<'a, 'tcx> { fn drop(&mut self) { self.0.type_of_depth.set(self.0.type_of_depth.get() - 1); } } </ins> /// Declare any llvm intrinsics that you might need fn declare_intrinsic(ccx: &CrateContext, key: &str) -> Option<ValueRef> { macro_rules! ifn {
Code change:
On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.

Related discussion:
text: } debug!("sizing_type_of {:?}", t); <ins> let _recursion_lock = cx.enter_type_of(t); </ins> let llsizingty = match t.sty { _ if !type_is_sized(cx.tcx(), t) => { Type::struct_(cx, &[Type::i8p(cx), Type::i8p(cx)], false)
Code change:
On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.

Related discussion:
text: <ins> // Copyright 2015 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. trait Foo { type A; } struct FooStruct; impl Foo for FooStruct { //~^ ERROR overflow evaluating the requirement `<FooStruct as Foo>::A` type A = <FooStruct as Foo>::A; } fn main() {} </ins>
Code change:
On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.

Related discussion:
text: <ins> // Copyright 2015 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: overflow representing the type `S` trait Mirror { type It; } impl<T> Mirror for T { type It = Self; } struct S(Option<<S as Mirror>::It>); fn main() { let _s = S(None); } </ins>
Code change:
On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.

Related discussion:
text: <ins> // Copyright 2015 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. pub struct Outer<T: Trait>(T); pub struct Inner<'a> { value: &'a bool } pub trait Trait { type Error; fn ready(self) -> Self::Error; } impl<'a> Trait for Inner<'a> { type Error = Outer<Inner<'a>>; fn ready(self) -> Outer<Inner<'a>> { Outer(self) } } fn main() { let value = true; let inner = Inner { value: &value }; assert_eq!(inner.ready().0.value, &value); } </ins>
Code change:
This isn't a big deal but the documentation is slightly out of date for the variant of . Reference: The comment should read: I will fix this if I have time, otherwise it is a small tweak that someone looking to contribute could make. cc
I've taken the liberty of fixing that comment :)
can you open up a pull request please?
Yep, done! Is this the right way to do it?

Related discussion:
text: /// /// ``` /// let a = [1, 2, 3, 4, 5]; <del> /// assert!(a.iter().fold(0, |a, &b| a + b) == 15); </del> <ins> /// assert!(a.iter().fold(0, |acc, &item| acc + item) == 15); </ins> /// ``` #[inline] #[stable(feature = "rust1", since = "1.0.0")]
Code change:
This isn't a big deal but the documentation is slightly out of date for the variant of . Reference: The comment should read: I will fix this if I have time, otherwise it is a small tweak that someone looking to contribute could make. cc
I've taken the liberty of fixing that comment :)
can you open up a pull request please?
Yep, done! Is this the right way to do it?

Related discussion:
text: /// instance, it will behave *as if* an instance of the type `T` were /// present for the purpose of various automatic analyses. /// <del> /// For example, embedding a `PhantomData<T>` will inform the compiler </del> <ins> /// # Examples /// /// When handling external resources over a foreign function interface, `PhantomData<T>` can /// prevent mismatches by enforcing types in the method implementations, although the struct /// doesn't actually contain values of the resource type. /// /// ``` /// # trait ResType { fn foo(&self); }; /// # struct ParamType; /// # mod foreign_lib { /// # pub fn new(_: usize) -> *mut () { 42 as *mut () } /// # pub fn do_stuff(_: *mut (), _: usize) {} /// # } /// # fn convert_params(_: ParamType) -> usize { 42 } /// use std::marker::PhantomData; /// use std::mem; /// /// struct ExternalResource<R> { ///    resource_handle: *mut (), ///    resource_type: PhantomData<R>, /// } /// /// impl<R: ResType> ExternalResource<R> { ///     fn new() -> ExternalResource<R> { ///         let size_of_res = mem::size_of::<R>(); ///         ExternalResource { ///             resource_handle: foreign_lib::new(size_of_res), ///             resource_type: PhantomData, ///         } ///     } /// ///     fn do_stuff(&self, param: ParamType) { ///         let foreign_params = convert_params(param); ///         foreign_lib::do_stuff(self.resource_handle, foreign_params); ///     } /// } /// ``` /// /// Another example: embedding a `PhantomData<T>` will inform the compiler </ins> /// that one or more instances of the type `T` could be dropped when /// instances of the type itself is dropped, though that may not be /// apparent from the other structure of the type itself. This is
Code change:
This isn't a big deal but the documentation is slightly out of date for the variant of . Reference: The comment should read: I will fix this if I have time, otherwise it is a small tweak that someone looking to contribute could make. cc
I've taken the liberty of fixing that comment :)
can you open up a pull request please?
Yep, done! Is this the right way to do it?

Related discussion:
text: /// The different kinds of types recognized by the compiler pub enum Ty_ { TyVec(P<Ty>), <del> /// A fixed length array (`[T, ..n]`) </del> <ins> /// A fixed length array (`[T; n]`) </ins> TyFixedLengthVec(P<Ty>, P<Expr>), /// A raw pointer (`*const T` or `*mut T`) TyPtr(MutTy),
Code change:
The behavior of .consume when the buffer is empty is weird : while :
Currently the contract of is that you can only pass a number the number of bytes you receive from . In this case the method is never being called, causing the weird behavior. I believe this is a documentation issue as the documentation for the method is pretty curt.
Maybe adding an assert_debug to check that could be useful too ?
What's the intended use of if it must always be passed a value the return value of ?
Oh sorry, I meant ! The function is intended to tell the buffer how many bytes you've consumed from the return value of

Related discussion:
text: /// This function does not perform any I/O, it simply informs this object /// that some amount of its buffer, returned from `fill_buf`, has been /// consumed and should no longer be returned. <ins> /// /// This function is used to tell the buffer how many bytes you've consumed /// from the return value of `fill_buf`, and so may do odd things if /// `fill_buf` isn't called before calling this. /// /// The `amt` must be `<=` the number of bytes in the buffer returned by `fill_buf`. </ins> #[stable(feature = "rust1", since = "1.0.0")] fn consume(&mut self, amt: usize);
Code change:
Slightly smaller example:
Running with code block code block I can't reproduce the ICE. Can this be closed?
Tests in .
Should be closed now,

Related discussion:
text: <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. enum Foo { Bar } fn main() { Foo::Bar.a; //~^ ERROR: attempted access of field `a` on type `Foo`, but no field with that name was found } </ins>
Code change:
This affects the test suites for the and crates.
triage: I-wrong, P-high (1.0)
triage: P-high (1.0)
I ended up adding the 1.0 milestone by hand; isn't the above note with supposed to do it?
cc
the log above says that highfive did add this to the 1.0 milestone - it might just have been that your local view of the webpage needed refreshing?
yeah I guess so, I don't know what happened anymore. Maybe I should have given highfive a little more time to react.

Related discussion:
text: <del> // Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT </del> <ins> // Copyright 2012-2015 The Rust Project Developers. See the COPYRIGHT </ins> // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. //
Code change:
This affects the test suites for the and crates.
triage: I-wrong, P-high (1.0)
triage: P-high (1.0)
I ended up adding the 1.0 milestone by hand; isn't the above note with supposed to do it?
cc
the log above says that highfive did add this to the 1.0 milestone - it might just have been that your local view of the webpage needed refreshing?
yeah I guess so, I don't know what happened anymore. Maybe I should have given highfive a little more time to react.

Related discussion:
text: use std::num::wrapping::OverflowingOps; use std::cmp::Ordering; use std::collections::hash_map::Entry::Vacant; <del> use std::{i8, i16, i32, i64}; </del> <ins> use std::{i8, i16, i32, i64, u8, u16, u32, u64}; </ins> use std::rc::Rc; fn lookup_const<'a>(tcx: &'a ty::ctxt, e: &Expr) -> Option<&'a Expr> {
Code change:
This affects the test suites for the and crates.
triage: I-wrong, P-high (1.0)
triage: P-high (1.0)
I ended up adding the 1.0 milestone by hand; isn't the above note with supposed to do it?
cc
the log above says that highfive did add this to the 1.0 milestone - it might just have been that your local view of the webpage needed refreshing?
yeah I guess so, I don't know what happened anymore. Maybe I should have given highfive a little more time to react.

Related discussion:
text: Ok(const_uint((!a).wrapping_add(1))) } <ins> fn const_uint_not(a: u64, opt_ety: Option<UintTy>) -> const_val { let mask = match opt_ety { Some(UintTy::U8) => u8::MAX as u64, Some(UintTy::U16) => u16::MAX as u64, Some(UintTy::U32) => u32::MAX as u64, None | Some(UintTy::U64) => u64::MAX, }; const_uint(!a & mask) } </ins> macro_rules! overflow_checking_body { ($a:ident, $b:ident, $ety:ident, $overflowing_op:ident, lhs: $to_8_lhs:ident $to_16_lhs:ident $to_32_lhs:ident,
Code change:
This affects the test suites for the and crates.
triage: I-wrong, P-high (1.0)
triage: P-high (1.0)
I ended up adding the 1.0 milestone by hand; isn't the above note with supposed to do it?
cc
the log above says that highfive did add this to the 1.0 milestone - it might just have been that your local view of the webpage needed refreshing?
yeah I guess so, I don't know what happened anymore. Maybe I should have given highfive a little more time to react.

Related discussion:
text: ast::ExprUnary(ast::UnNot, ref inner) => { match try!(eval_const_expr_partial(tcx, &**inner, ety)) { const_int(i) => const_int(!i), <del> const_uint(i) => const_uint(!i), </del> <ins> const_uint(i) => const_uint_not(i, expr_uint_type), </ins> const_bool(b) => const_bool(!b), const_str(_) => signal!(e, NotOnString), const_float(_) => signal!(e, NotOnFloat),
Code change:
This affects the test suites for the and crates.
triage: I-wrong, P-high (1.0)
triage: P-high (1.0)
I ended up adding the 1.0 milestone by hand; isn't the above note with supposed to do it?
cc
the log above says that highfive did add this to the 1.0 milestone - it might just have been that your local view of the webpage needed refreshing?
yeah I guess so, I don't know what happened anymore. Maybe I should have given highfive a little more time to react.

Related discussion:
text: <ins> // Copyright 2015 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. const U8_MAX_HALF: u8 = !0u8 / 2; const U16_MAX_HALF: u16 = !0u16 / 2; const U32_MAX_HALF: u32 = !0u32 / 2; const U64_MAX_HALF: u64 = !0u64 / 2; fn main() { assert_eq!(U8_MAX_HALF, 0x7f); assert_eq!(U16_MAX_HALF, 0x7fff); assert_eq!(U32_MAX_HALF, 0x7fff_ffff); assert_eq!(U64_MAX_HALF, 0x7fff_ffff_ffff_ffff); } </ins>
Code change:
For example  should have a bound, but we're a little too aggressive about pruning out the bounds. For comparison  does indeed have the bound. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This also applies to bounds on traits.
This prompted a question on IRC about whether requires , because the bound is not visible in the libstd documentation. It is visible in the libcore docs though.
Triage: This still happens
This actually ended up biting me today, is there a plan to handle this? I could help implement if I get pointers
did not fix this - it now shows , which is nice, but it doesn't show bounds on traits. For traits it does matter because the default is .
I would start by finding out why this is different between local crates and cross-crate re-exports. I expect is behaving differently from .
Ah, I also hit this today when looking at . Kudos to whoever can figure this one out :)
claim

Related discussion:
text: <ins> #![crate_type = "lib"] pub trait U/*: ?Sized */ { fn modified(self) -> Self where Self: Sized { self } fn touch(&self)/* where Self: ?Sized */{} } pub trait S: Sized {} </ins>