Question: Here's what I think is wrong: keywords , and appear next to the name of the constant, when clearly they are redundant. the constants page through search brings the user to an empty page. value assigned to the constant appears along side its name. When reading the documentation of constants, the most important information is the name of the constant and its description. Having the declaration appear inline makes scanning for the name of harder. Better output would replace the declaration with the name of the constant followed by its type. Also it would move the declaration of the constant to the empty page mentioned in point 2 and have the identifier of the constant link to this page. All these points are relevant for statics as well. Example of ugly output: ! This page should show the definition and a description of the constant: !

clean::TypedefItem(ref t) => item_typedef(fmt, self.item, t), clean::MacroItem(ref m) => item_macro(fmt, self.item, m), clean::PrimitiveItem(ref p) => item_primitive(fmt, self.item, p), <ins> clean::StaticItem(ref i) => item_static(fmt, self.item, i), clean::ConstantItem(ref c) => item_constant(fmt, self.item, c), </ins> _ => Ok(()) } }


Question: Here's what I think is wrong: keywords , and appear next to the name of the constant, when clearly they are redundant. the constants page through search brings the user to an empty page. value assigned to the constant appears along side its name. When reading the documentation of constants, the most important information is the name of the constant and its description. Having the declaration appear inline makes scanning for the name of harder. Better output would replace the declaration with the name of the constant followed by its type. Also it would move the declaration of the constant to the empty page mentioned in point 2 and have the identifier of the constant link to this page. All these points are relevant for statics as well. Example of ugly output: ! This page should show the definition and a description of the constant: !

return s } <del> fn blank<'a>(s: Option<&'a str>) -> &'a str { match s { Some(s) => s, None => "" } } </del> fn shorter<'a>(s: Option<&'a str>) -> &'a str { match s { Some(s) => match s.find_str("nn") {


Question: Here's what I think is wrong: keywords , and appear next to the name of the constant, when clearly they are redundant. the constants page through search brings the user to an empty page. value assigned to the constant appears along side its name. When reading the documentation of constants, the most important information is the name of the constant and its description. Having the declaration appear inline makes scanning for the name of harder. Better output would replace the declaration with the name of the constant followed by its type. Also it would move the declaration of the constant to the empty page mentioned in point 2 and have the identifier of the constant link to this page. All these points are relevant for statics as well. Example of ugly output: ! This page should show the definition and a description of the constant: !

id = short, name = name)); }  struct Initializer<'a>(&'a str, Item<'a>); impl<'a> fmt::Show for Initializer<'a> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { let Initializer(s, item) = *self; if s.len() == 0 { return Ok(()); } try!(write!(f, " = ")); if s.contains("n") { match item.href() { Some(url) => { write!(f, "[definition]", url) } None => Ok(()), } } else { write!(f, "{}", s.as_slice()) } } }  match myitem.inner {  clean::StaticItem(ref s) | clean::ForeignStaticItem(ref s) => { try!(write!(w, "
 {}{}static {}{}: {}{}	 {}
 ", ConciseStability(&myitem.stability), VisSpace(myitem.visibility), MutableSpace(s.mutability), *myitem.name.as_ref().unwrap(), s.type_, Initializer(s.expr.as_slice(), Item { cx: cx, item: myitem }), Markdown(blank(myitem.doc_value())))); } clean::ConstantItem(ref s) => { try!(write!(w, "
 {}{}const {}: {}{}	 {}
 ", ConciseStability(&myitem.stability), VisSpace(myitem.visibility), *myitem.name.as_ref().unwrap(), s.type_, Initializer(s.expr.as_slice(), Item { cx: cx, item: myitem }), Markdown(blank(myitem.doc_value())))); }  clean::ViewItemItem(ref item) => { match item.inner { clean::ExternCrate(ref name, ref src, _) => {


Question: Here's what I think is wrong: keywords , and appear next to the name of the constant, when clearly they are redundant. the constants page through search brings the user to an empty page. value assigned to the constant appears along side its name. When reading the documentation of constants, the most important information is the name of the constant and its description. Having the declaration appear inline makes scanning for the name of harder. Better output would replace the declaration with the name of the constant followed by its type. Also it would move the declaration of the constant to the empty page mentioned in point 2 and have the identifier of the constant link to this page. All these points are relevant for statics as well. Example of ugly output: ! This page should show the definition and a description of the constant: !

write!(w, "
") }  struct Initializer<'a>(&'a str); impl<'a> fmt::Show for Initializer<'a> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { let Initializer(s) = *self; if s.len() == 0 { return Ok(()); } try!(write!(f, " = ")); write!(f, "{}", s.as_slice()) } } fn item_constant(w: &mut fmt::Formatter, it: &clean::Item, c: &clean::Constant) -> fmt::Result { try!(write!(w, "
{vis}const  {name}: {typ}{init}
", vis = VisSpace(it.visibility), name = it.name.as_ref().unwrap().as_slice(), typ = c.type_, init = Initializer(c.expr.as_slice()))); document(w, it) } fn item_static(w: &mut fmt::Formatter, it: &clean::Item, s: &clean::Static) -> fmt::Result { try!(write!(w, "
{vis}static {mutability} {name}: {typ}{init}
", vis = VisSpace(it.visibility), mutability = MutableSpace(s.mutability), name = it.name.as_ref().unwrap().as_slice(), typ = s.type_, init = Initializer(s.expr.as_slice()))); document(w, it) }  fn item_function(w: &mut fmt::Formatter, it: &clean::Item, f: &clean::Function) -> fmt::Result { try!(write!(w, "
{vis}{fn_style}fn


Question:
The documentation is misleading. The pointer is not allowed to be null.
How do you make an empty slice if the pointer is not allowed to be null?
The underlying representation is an implementation detail and shouldn't be documented beyond the ability to convert the raw parts obtained from a vector back into a vector.
The language and library documentation has a love affair with making far too many promises about the implementation. In the vector module, there are numerous errors when it comes to information about the vector's capacity too. It tends to guarantee that the capacity is exactly what was asked for rather than at least that much. It is allowed to set the capacity to a value provided by the allocator.
Does that mean you are required to special case the empty case and then use a different way to make an empty vector?
No, it means you can't use this method outside of the standard library beyond converting from an existing vector.
If what you're asking is how it does this internally, the answer is that empty vectors along with zero-size allocations in general are allowed to be entirely arbitrary pointers. They will never be dereferenced and the compiler / library code will never attempt to deallocate them.
The documentation is not supposed to cover these implementation details. It would make sense to cover it in comments (which it is) or internal design documentation.
In that case I suppose the docs should say: can only be constructed from components of an already existing vector.

} } <del> /// Creates a `Vec<T>` directly from the raw constituents. </del> <ins> /// Creates a `Vec<T>` directly from the raw components of another vector. </ins> /// <del> /// This is highly unsafe: /// /// - if `ptr` is null, then `length` and `capacity` should be 0 /// - `ptr` must point to an allocation of size `capacity` /// - there must be `length` valid instances of type `T` at the ///   beginning of that allocation /// - `ptr` must be allocated by the default `Vec` allocator </del> <ins> /// This is highly unsafe, due to the number of invariants that aren't checked. </ins> /// /// # Example ///


Question:
cc
It seems like the second part of this (type parameter shadowing) is backwards incompatible, but AFAICT, isn't implemented yet.
I suggest we leave it and go straight for the lint (as we plan to do eventually with the lifetime version). Then no backwards compatibility issues. Also, since type shadowing is allowed in every other language it is going to really surprise people if it is forbidden in Rust. And, it is the shadowed lifetimes which were causing the motivating confusion.
just for future visitors, type parameter shadowing (like the example in the RFC) does, in fact, produce a clear compiler error. The comments above and lack of linked "type parameter shadowing" PRs might otherwise suggest that type parameter shadowing was left as a lint rather than a compiler error.

use syntax::ast_util::{local_def}; use syntax::attr; use syntax::codemap::Span; <ins> use syntax::parse::token; </ins> use syntax::visit; use syntax::visit::Visitor;


Question:
cc
It seems like the second part of this (type parameter shadowing) is backwards incompatible, but AFAICT, isn't implemented yet.
I suggest we leave it and go straight for the lint (as we plan to do eventually with the lifetime version). Then no backwards compatibility issues. Also, since type shadowing is allowed in every other language it is going to really surprise people if it is forbidden in Rust. And, it is the shadowed lifetimes which were causing the motivating confusion.
just for future visitors, type parameter shadowing (like the example in the RFC) does, in fact, produce a clear compiler error. The comments above and lack of linked "type parameter shadowing" PRs might otherwise suggest that type parameter shadowing was left as a lint rather than a compiler error.

} } <ins> fn reject_shadowing_type_parameters<'tcx>(tcx: &ty::ctxt<'tcx>, span: Span, generics: &ty::Generics<'tcx>) { let impl_params = generics.types.get_slice(subst::TypeSpace).iter() .map(|tp| tp.name).collect::<HashSet<_>>(); for method_param in generics.types.get_slice(subst::FnSpace).iter() { if impl_params.contains(&method_param.name) { tcx.sess.span_err( span, &*format!("type parameter `{}` shadows another type parameter of the same name", token::get_name(method_param.name))); } } } </ins> impl<'ccx, 'tcx, 'v> Visitor<'v> for CheckTypeWellFormedVisitor<'ccx, 'tcx> { fn visit_item(&mut self, i: &ast::Item) { self.check_item_well_formed(i); visit::walk_item(self, i); } <ins> fn visit_fn(&mut self, fk: visit::FnKind<'v>, fd: &'v ast::FnDecl, b: &'v ast::Block, span: Span, id: ast::NodeId) { match fk { visit::FkFnBlock | visit::FkItemFn(..) => {} visit::FkMethod(..) => { match ty::impl_or_trait_item(self.ccx.tcx, local_def(id)) { ty::ImplOrTraitItem::MethodTraitItem(ty_method) => { reject_shadowing_type_parameters(self.ccx.tcx, span, &ty_method.generics) } _ => {} } } } visit::walk_fn(self, fk, fd, b, span) } fn visit_trait_item(&mut self, t: &'v ast::TraitItem) { match t { &ast::TraitItem::ProvidedMethod(_) | &ast::TraitItem::TypeTraitItem(_) => {}, &ast::TraitItem::RequiredMethod(ref method) => { match ty::impl_or_trait_item(self.ccx.tcx, local_def(method.id)) { ty::ImplOrTraitItem::MethodTraitItem(ty_method) => { reject_shadowing_type_parameters( self.ccx.tcx, method.span, &ty_method.generics) } _ => {} } } } visit::walk_trait_item(self, t) } </ins> } pub struct BoundsChecker<'cx,'tcx:'cx> {


Question:
cc
It seems like the second part of this (type parameter shadowing) is backwards incompatible, but AFAICT, isn't implemented yet.
I suggest we leave it and go straight for the lint (as we plan to do eventually with the lifetime version). Then no backwards compatibility issues. Also, since type shadowing is allowed in every other language it is going to really surprise people if it is forbidden in Rust. And, it is the shadowed lifetimes which were causing the motivating confusion.
just for future visitors, type parameter shadowing (like the example in the RFC) does, in fact, produce a clear compiler error. The comments above and lack of linked "type parameter shadowing" PRs might otherwise suggest that type parameter shadowing was left as a lint rather than a compiler error.

self.ch == Some(c) } <del> fn error<T>(&self, reason: ErrorCode) -> Result<T, ParserError> { </del> <ins> fn error<U>(&self, reason: ErrorCode) -> Result<U, ParserError> { </ins> Err(SyntaxError(reason, self.line, self.col)) }


Question:
cc
It seems like the second part of this (type parameter shadowing) is backwards incompatible, but AFAICT, isn't implemented yet.
I suggest we leave it and go straight for the lint (as we plan to do eventually with the lifetime version). Then no backwards compatibility issues. Also, since type shadowing is allowed in every other language it is going to really surprise people if it is forbidden in Rust. And, it is the shadowed lifetimes which were causing the motivating confusion.
just for future visitors, type parameter shadowing (like the example in the RFC) does, in fact, produce a clear compiler error. The comments above and lack of linked "type parameter shadowing" PRs might otherwise suggest that type parameter shadowing was left as a lint rather than a compiler error.

<ins> // Copyright 2013 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 that shadowed lifetimes generate an error. struct Foo<T>; impl<T> Foo<T> { fn shadow_in_method<T>(&self) {} //~^ ERROR type parameter `T` shadows another type parameter fn not_shadow_in_item<U>(&self) { struct Bar<T, U>; // not a shadow, separate item fn foo<T, U>() {} // same } } trait<T> Bar<T> { fn shadow_in_required<T>(&self); //~^ ERROR type parameter `T` shadows another type parameter fn shadow_in_provided<T>(&self) {} //~^ ERROR type parameter `T` shadows another type parameter fn not_shadow_in_required<U>(&self); fn not_shadow_in_provided<U>(&self) {} } fn main() {} </ins>


Question:
Tracking issue for this failure:
It appears that the compiler is producing corrupt metadata somehow. I have modified the test to ignore and only link to , and I've found an interesting phenomena. When running the test via the rlib for -2 may end up containing two blobs of metadata. One blob of metadata ends in four 0x0a bytes (corrupted), and the other blob is the exact same but without these trailing bytes. The compilation of the -3 crate is the one that's failing, and it will deterministically fail depending on the metadata of the -2 crate. I do not currently know where the extra bytes come from, still trying to track that down...

// aux-build:issue-13560-1.rs // aux-build:issue-13560-2.rs // aux-build:issue-13560-3.rs <ins> // ignore-pretty FIXME #19501 </ins> // ignore-stage1 // Regression test for issue #13560, the test itself is all in the dependent


Question: Right now we don't normalize impl bounds during method probing, which means that the winnow stage may not work great when those bounds involve associated types. I think with the new setup we should be able to do this but didn't have time to test. Search for the FIXME in

match probe.kind { InherentImplCandidate(impl_def_id, ref substs) | ExtensionImplCandidate(impl_def_id, _, ref substs, _) => { <ins> let selcx = &mut traits::SelectionContext::new(self.infcx(), self.fcx); let cause = traits::ObligationCause::misc(self.span, self.fcx.body_id); </ins> // Check whether the impl imposes obligations we have to worry about. let impl_generics = ty::lookup_item_type(self.tcx(), impl_def_id).generics; let impl_bounds = impl_generics.to_bounds(self.tcx(), substs); <del> // FIXME(#20378) assoc type normalization here? // Erase any late-bound regions bound in the impl // which appear in the bounds. let impl_bounds = self.erase_late_bound_regions(&ty::Binder(impl_bounds)); </del> <ins> let traits::Normalized { value: impl_bounds, obligations: norm_obligations } = traits::normalize(selcx, cause.clone(), &impl_bounds); </ins> // Convert the bounds into obligations. let obligations = <del> traits::predicates_for_generics( self.tcx(), traits::ObligationCause::misc(self.span, self.fcx.body_id), &impl_bounds); </del> <ins> traits::predicates_for_generics(self.tcx(), cause.clone(), &impl_bounds); </ins> debug!("impl_obligations={}", obligations.repr(self.tcx())); // Evaluate those obligations to see if they might possibly hold. <del> let mut selcx = traits::SelectionContext::new(self.infcx(), self.fcx); obligations.all(|o| selcx.evaluate_obligation(o)) </del> <ins> obligations.all(|o| selcx.evaluate_obligation(o)) && norm_obligations.iter().all(|o| selcx.evaluate_obligation(o)) </ins> } ObjectCandidate(..) |


Question: Right now we don't normalize impl bounds during method probing, which means that the winnow stage may not work great when those bounds involve associated types. I think with the new setup we should be able to do this but didn't have time to test. Search for the FIXME in

<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. // Test that we handle projection types which wind up important for // resolving methods. This test was reduced from a larger example; the // call to `foo()` at the end was failing to resolve because the // winnowing stage of method resolution failed to handle an associated // type projection. #![feature(associated_types)] trait Hasher { type Output; fn finish(&self) -> Self::Output; } trait Hash<H: Hasher> { fn hash(&self, h: &mut H); } trait HashState { type Wut: Hasher; fn hasher(&self) -> Self::Wut; } struct SipHasher; impl Hasher for SipHasher { type Output = u64; fn finish(&self) -> u64 { 4 } } impl Hash<SipHasher> for int { fn hash(&self, h: &mut SipHasher) {} } struct SipState; impl HashState for SipState { type Wut = SipHasher; fn hasher(&self) -> SipHasher { SipHasher } } struct Map<S> { s: S, } impl<S> Map<S> where S: HashState, <S as HashState>::Wut: Hasher<Output=u64>, { fn foo<K>(&self, k: K) where K: Hash< <S as HashState>::Wut> {} } fn foo<K: Hash<SipHasher>>(map: &Map<SipState>) { map.foo(22); } fn main() {} </ins>


Question:
I think I found a bug with non-power-of-2 SIMD vectors. They're randomly turned into zero values when I store them on Expected result: What we get: Tested with:
As you can see, this is a fault of assuming (while for this is 12 and 16 respectively). More accurately, for , every growth allocates bytes while it actually needs bytes; any element after will overflow the memory, and they will be omitted at the next reallocation.
Ack!
CC
I've got through and I guess there's something wrong with for and other non-power-of-2 SIMD types.<!-- (Don't trust me!) --I think now we've got 2 available options. Make always true even for non-power-of-2 SIMD types like . Make function properly even for situation. I'm pretty new with Rust. Someone pleaes make me an advise!
I'm not sure what the exact behaviour should be. Part of the problem is that non-power-of-two SIMD types don't exist on most platforms, so it gets widened to whatever it needs to be. However, an f32x3 is still only 12 bytes of actual data. I think that Vec should handle the case anyway. Whether the case should come up... I don't really know.
Given that sizeof (f32x3, u32) == 32, it seems like rust already adds padding for SIMD types, so it's simply sizeof that's broken, and should include the padding. At the same time, Vec<Tshould probably assert that sizeof T = minalignof T to catch any errors if in the future there are any types where their size is less than their alignment.
Nominating because the required change may be a back-compat change to some primitive semantics.
Actually, thinking about it some more. I believe that the current behaviour is correct. doesn't account for padding, because padding is situation-dependent: has 7 bytes of padding after the , but that doesn't stop from being 1 byte in size. Just because the type gets padding, doesn't mean it needs to change size. The whole point of having a different alignment to size is to cover these kinds of cases, where the number of usable bytes is not a nice integer multiple of the alignment.
In that situation, the extra padding is to meet the alignment requirements of "u64", not the "i8". In the SIMD example, the extra padding is part of the SIMD type. ie. for (f32x3, u32) there are 4 bytes of padding between the fields, even though u32 only requires alignment to 4 bytes. Either the compiler should not add any padding and sizeof (f32x3, u32) == 16, and any accesses take care to preserve the u32 or as is more usual, the SIMD type should include it's padding. edit: To clarify, types do include their padding in sizeof, which is why sizeof (u64, i8) == 16 as opposed to 9
Amusingly, has a size of 16, whereas f32x3 on it's own has a size of 12, which really shouldn't happen. The issue is caused by sizeof being implemented as a call to this function: The comment above the function is wrong: LLVM does include padding when calculating the size of types, but only for structs (not for vectorised types), which makes that function fairly useless and definitely not the preferred option as the comment suggests. should be preferred instead which always includes padding, so is at least consistent.
NB. and are experimental and are highly unlikely to be stable at 1.0.
Current works like below: and I found that current LLVM doesn't have any guarantee between and . Instead, for SIMD vector types, is guaranteed to be greater or equal than . For example, and of 80-bit floating point format is and . I know that Rust doesn't have but if it does, will be and will be . Which means would have same problem. Now I see 2 options here call , not (as said) function properly even for situation. → → → → → → → alignof → → → → →
I meant more-so the size_of semantics, but simd semantics might also be affected.
I think this is a compiler bug. There are many low-level APIs assuming that size is a multiple of the alignment...
For example, C11's function requires that is a multiple of the parameter. It's expected that the compiler will always output sane values for both (unlike :P) so it is a sensible limitation.
Unfortunately, forcing to return a multiple of would make impossible, which seems like a big missed opportunity. Perhaps there should be a function that just rounds to the next multiple of ?
You could have both sizeof and paddedsizeof, but for the moment, they'd both have to include padding because for struct types LLVM provides no way to get the size without padding, and for vectorised types, even sizeof should include padding as can't be applied to vectorised types without masking every load/store to avoid overwriting the u32 in (f32x3, u32).
Currently I'm testing , and it seems to cause no trouble. Please make me an advise if I'm doing something wrong.
OK Let's do this →

(_, "size_of") => { let tp_ty = *substs.types.get(FnSpace, 0); let lltp_ty = type_of::type_of(ccx, tp_ty); <del> C_uint(ccx, machine::llsize_of_real(ccx, lltp_ty)) </del> <ins> C_uint(ccx, machine::llsize_of_alloc(ccx, lltp_ty)) </ins> } (_, "min_align_of") => { let tp_ty = *substs.types.get(FnSpace, 0);


Question:
I think I found a bug with non-power-of-2 SIMD vectors. They're randomly turned into zero values when I store them on Expected result: What we get: Tested with:
As you can see, this is a fault of assuming (while for this is 12 and 16 respectively). More accurately, for , every growth allocates bytes while it actually needs bytes; any element after will overflow the memory, and they will be omitted at the next reallocation.
Ack!
CC
I've got through and I guess there's something wrong with for and other non-power-of-2 SIMD types.<!-- (Don't trust me!) --I think now we've got 2 available options. Make always true even for non-power-of-2 SIMD types like . Make function properly even for situation. I'm pretty new with Rust. Someone pleaes make me an advise!
I'm not sure what the exact behaviour should be. Part of the problem is that non-power-of-two SIMD types don't exist on most platforms, so it gets widened to whatever it needs to be. However, an f32x3 is still only 12 bytes of actual data. I think that Vec should handle the case anyway. Whether the case should come up... I don't really know.
Given that sizeof (f32x3, u32) == 32, it seems like rust already adds padding for SIMD types, so it's simply sizeof that's broken, and should include the padding. At the same time, Vec<Tshould probably assert that sizeof T = minalignof T to catch any errors if in the future there are any types where their size is less than their alignment.
Nominating because the required change may be a back-compat change to some primitive semantics.
Actually, thinking about it some more. I believe that the current behaviour is correct. doesn't account for padding, because padding is situation-dependent: has 7 bytes of padding after the , but that doesn't stop from being 1 byte in size. Just because the type gets padding, doesn't mean it needs to change size. The whole point of having a different alignment to size is to cover these kinds of cases, where the number of usable bytes is not a nice integer multiple of the alignment.
In that situation, the extra padding is to meet the alignment requirements of "u64", not the "i8". In the SIMD example, the extra padding is part of the SIMD type. ie. for (f32x3, u32) there are 4 bytes of padding between the fields, even though u32 only requires alignment to 4 bytes. Either the compiler should not add any padding and sizeof (f32x3, u32) == 16, and any accesses take care to preserve the u32 or as is more usual, the SIMD type should include it's padding. edit: To clarify, types do include their padding in sizeof, which is why sizeof (u64, i8) == 16 as opposed to 9
Amusingly, has a size of 16, whereas f32x3 on it's own has a size of 12, which really shouldn't happen. The issue is caused by sizeof being implemented as a call to this function: The comment above the function is wrong: LLVM does include padding when calculating the size of types, but only for structs (not for vectorised types), which makes that function fairly useless and definitely not the preferred option as the comment suggests. should be preferred instead which always includes padding, so is at least consistent.
NB. and are experimental and are highly unlikely to be stable at 1.0.
Current works like below: and I found that current LLVM doesn't have any guarantee between and . Instead, for SIMD vector types, is guaranteed to be greater or equal than . For example, and of 80-bit floating point format is and . I know that Rust doesn't have but if it does, will be and will be . Which means would have same problem. Now I see 2 options here call , not (as said) function properly even for situation. → → → → → → → alignof → → → → →
I meant more-so the size_of semantics, but simd semantics might also be affected.
I think this is a compiler bug. There are many low-level APIs assuming that size is a multiple of the alignment...
For example, C11's function requires that is a multiple of the parameter. It's expected that the compiler will always output sane values for both (unlike :P) so it is a sensible limitation.
Unfortunately, forcing to return a multiple of would make impossible, which seems like a big missed opportunity. Perhaps there should be a function that just rounds to the next multiple of ?
You could have both sizeof and paddedsizeof, but for the moment, they'd both have to include padding because for struct types LLVM provides no way to get the size without padding, and for vectorised types, even sizeof should include padding as can't be applied to vectorised types without masking every load/store to avoid overwriting the u32 in (f32x3, u32).
Currently I'm testing , and it seems to cause no trouble. Please make me an advise if I'm doing something wrong.
OK Let's do this →

// Returns, as near as we can figure, the "real" size of a type. As in, the // bits in this number of bytes actually carry data related to the datum <del> // with the type. Not junk, padding, accidentally-damaged words, or // whatever. Rounds up to the nearest byte though, so if you have a 1-bit </del> <ins> // with the type. Not junk, accidentally-damaged words, or whatever. // Note that padding of the type will be included for structs, but not for the // other types (i.e. SIMD types). // Rounds up to the nearest byte though, so if you have a 1-bit </ins> // value, we return 1 here, not 0. Most of rustc works in bytes. Be warned // that LLVM *does* distinguish between e.g. a 1-bit value and an 8-bit value // at the codegen level! In general you should prefer `llbitsize_of_real`


Question:
I think I found a bug with non-power-of-2 SIMD vectors. They're randomly turned into zero values when I store them on Expected result: What we get: Tested with:
As you can see, this is a fault of assuming (while for this is 12 and 16 respectively). More accurately, for , every growth allocates bytes while it actually needs bytes; any element after will overflow the memory, and they will be omitted at the next reallocation.
Ack!
CC
I've got through and I guess there's something wrong with for and other non-power-of-2 SIMD types.<!-- (Don't trust me!) --I think now we've got 2 available options. Make always true even for non-power-of-2 SIMD types like . Make function properly even for situation. I'm pretty new with Rust. Someone pleaes make me an advise!
I'm not sure what the exact behaviour should be. Part of the problem is that non-power-of-two SIMD types don't exist on most platforms, so it gets widened to whatever it needs to be. However, an f32x3 is still only 12 bytes of actual data. I think that Vec should handle the case anyway. Whether the case should come up... I don't really know.
Given that sizeof (f32x3, u32) == 32, it seems like rust already adds padding for SIMD types, so it's simply sizeof that's broken, and should include the padding. At the same time, Vec<Tshould probably assert that sizeof T = minalignof T to catch any errors if in the future there are any types where their size is less than their alignment.
Nominating because the required change may be a back-compat change to some primitive semantics.
Actually, thinking about it some more. I believe that the current behaviour is correct. doesn't account for padding, because padding is situation-dependent: has 7 bytes of padding after the , but that doesn't stop from being 1 byte in size. Just because the type gets padding, doesn't mean it needs to change size. The whole point of having a different alignment to size is to cover these kinds of cases, where the number of usable bytes is not a nice integer multiple of the alignment.
In that situation, the extra padding is to meet the alignment requirements of "u64", not the "i8". In the SIMD example, the extra padding is part of the SIMD type. ie. for (f32x3, u32) there are 4 bytes of padding between the fields, even though u32 only requires alignment to 4 bytes. Either the compiler should not add any padding and sizeof (f32x3, u32) == 16, and any accesses take care to preserve the u32 or as is more usual, the SIMD type should include it's padding. edit: To clarify, types do include their padding in sizeof, which is why sizeof (u64, i8) == 16 as opposed to 9
Amusingly, has a size of 16, whereas f32x3 on it's own has a size of 12, which really shouldn't happen. The issue is caused by sizeof being implemented as a call to this function: The comment above the function is wrong: LLVM does include padding when calculating the size of types, but only for structs (not for vectorised types), which makes that function fairly useless and definitely not the preferred option as the comment suggests. should be preferred instead which always includes padding, so is at least consistent.
NB. and are experimental and are highly unlikely to be stable at 1.0.
Current works like below: and I found that current LLVM doesn't have any guarantee between and . Instead, for SIMD vector types, is guaranteed to be greater or equal than . For example, and of 80-bit floating point format is and . I know that Rust doesn't have but if it does, will be and will be . Which means would have same problem. Now I see 2 options here call , not (as said) function properly even for situation. → → → → → → → alignof → → → → →
I meant more-so the size_of semantics, but simd semantics might also be affected.
I think this is a compiler bug. There are many low-level APIs assuming that size is a multiple of the alignment...
For example, C11's function requires that is a multiple of the parameter. It's expected that the compiler will always output sane values for both (unlike :P) so it is a sensible limitation.
Unfortunately, forcing to return a multiple of would make impossible, which seems like a big missed opportunity. Perhaps there should be a function that just rounds to the next multiple of ?
You could have both sizeof and paddedsizeof, but for the moment, they'd both have to include padding because for struct types LLVM provides no way to get the size without padding, and for vectorised types, even sizeof should include padding as can't be applied to vectorised types without masking every load/store to avoid overwriting the u32 in (f32x3, u32).
Currently I'm testing , and it seems to cause no trouble. Please make me an advise if I'm doing something wrong.
OK Let's do this →

<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. #![feature(simd)] #![allow(non_camel_case_types)] use std::mem; /// `T` should satisfy `size_of T (mod min_align_of T) === 0` to be stored at `Vec<T>` properly /// Please consult the issue #20460 fn check<T>() { assert_eq!(mem::size_of::<T>() % mem::min_align_of::<T>(), 0) } fn main() { check::<u8x2>(); check::<u8x3>(); check::<u8x4>(); check::<u8x5>(); check::<u8x6>(); check::<u8x7>(); check::<u8x8>(); check::<i16x2>(); check::<i16x3>(); check::<i16x4>(); check::<i16x5>(); check::<i16x6>(); check::<i16x7>(); check::<i16x8>(); check::<f32x2>(); check::<f32x3>(); check::<f32x4>(); check::<f32x5>(); check::<f32x6>(); check::<f32x7>(); check::<f32x8>(); } #[simd] struct u8x2(u8, u8); #[simd] struct u8x3(u8, u8, u8); #[simd] struct u8x4(u8, u8, u8, u8); #[simd] struct u8x5(u8, u8, u8, u8, u8); #[simd] struct u8x6(u8, u8, u8, u8, u8, u8); #[simd] struct u8x7(u8, u8, u8, u8, u8, u8, u8); #[simd] struct u8x8(u8, u8, u8, u8, u8, u8, u8, u8); #[simd] struct i16x2(i16, i16); #[simd] struct i16x3(i16, i16, i16); #[simd] struct i16x4(i16, i16, i16, i16); #[simd] struct i16x5(i16, i16, i16, i16, i16); #[simd] struct i16x6(i16, i16, i16, i16, i16, i16); #[simd] struct i16x7(i16, i16, i16, i16, i16, i16, i16); #[simd] struct i16x8(i16, i16, i16, i16, i16, i16, i16, i16); #[simd] struct f32x2(f32, f32); #[simd] struct f32x3(f32, f32, f32); #[simd] struct f32x4(f32, f32, f32, f32); #[simd] struct f32x5(f32, f32, f32, f32, f32); #[simd] struct f32x6(f32, f32, f32, f32, f32, f32); #[simd] struct f32x7(f32, f32, f32, f32, f32, f32, f32); #[simd] struct f32x8(f32, f32, f32, f32, f32, f32, f32, f32); </ins>


Question:
Compiling the above (admittedly ill-typed) file will cause My version is
cc didn't easily find a dup of this.
Looks like I am hitting a similar issue. Repro:
your code compiles with code still ICEs though
I have a similar issue with:
With the latest nightly, your example doesn't ICE, but errors instead:
So that would be wrong...? Should I make a new issue?
Why would that be wrong? implementors don't have a associated type, so is correctly rejected (the first error). The second error pops up because of a typo (I just noticed) it says Resouces in .
Oh, woops - the example was meant to be:
that compiles with the latest nightly ()
Yay!

<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 T : Iterator<Item=Self::Item> //~^ ERROR unsupported cyclic reference between types/traits detected {} fn main() {} </ins>


Question:
Compiling the above (admittedly ill-typed) file will cause My version is
cc didn't easily find a dup of this.
Looks like I am hitting a similar issue. Repro:
your code compiles with code still ICEs though
I have a similar issue with:
With the latest nightly, your example doesn't ICE, but errors instead:
So that would be wrong...? Should I make a new issue?
Why would that be wrong? implementors don't have a associated type, so is correctly rejected (the first error). The second error pops up because of a typo (I just noticed) it says Resouces in .
Oh, woops - the example was meant to be:
that compiles with the latest nightly ()
Yay!

<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 {} impl<'a> Foo for Foo+'a {} //~^ ERROR the object type `Foo + 'a` automatically implements the trait `Foo` fn main() {} </ins>


Question:
Compiling the above (admittedly ill-typed) file will cause My version is
cc didn't easily find a dup of this.
Looks like I am hitting a similar issue. Repro:
your code compiles with code still ICEs though
I have a similar issue with:
With the latest nightly, your example doesn't ICE, but errors instead:
So that would be wrong...? Should I make a new issue?
Why would that be wrong? implementors don't have a associated type, so is correctly rejected (the first error). The second error pops up because of a typo (I just noticed) it says Resouces in .
Oh, woops - the example was meant to be:
that compiles with the latest nightly ()
Yay!

<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. // ignore-tidy-linelength use std::ops::Add; fn main() { let x = &10 as //~^ ERROR the value of the associated type `Output` (from the trait `core::ops::Add`) must be specified &Add; //~^ ERROR the type parameter `RHS` must be explicitly specified in an object type because its default value `Self` references the type `Self` } </ins>


Question:
Compiling the above (admittedly ill-typed) file will cause My version is
cc didn't easily find a dup of this.
Looks like I am hitting a similar issue. Repro:
your code compiles with code still ICEs though
I have a similar issue with:
With the latest nightly, your example doesn't ICE, but errors instead:
So that would be wrong...? Should I make a new issue?
Why would that be wrong? implementors don't have a associated type, so is correctly rejected (the first error). The second error pops up because of a typo (I just noticed) it says Resouces in .
Oh, woops - the example was meant to be:
that compiles with the latest nightly ()
Yay!

<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. extern crate libc; fn main() { let foo: *mut libc::c_void; let cb: &mut Fn() = unsafe { &mut *(foo as *mut Fn()) //~^ ERROR use of possibly uninitialized variable: `foo` }; } </ins>


Question:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"

use self::Arch::*; #[allow(non_camel_case_types)] <ins> #[derive(Copy)] </ins> pub enum Arch { Armv7, Armv7s,


Question:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"

"-Wl,-syslibroot".to_string(), get_sdk_root(sdk_name)] } <ins> fn target_cpu(arch: Arch) -> String { match arch { X86_64 => "x86-64", _ => "generic", }.to_string() } </ins> pub fn opts(arch: Arch) -> TargetOptions { TargetOptions { <ins> cpu: target_cpu(arch), </ins> dynamic_linking: false, executables: true, // Although there is an experimental implementation of LLVM which


Question:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"

pub fn target() -> Target { let mut base = super::apple_base::opts(); <ins> base.cpu = "x86-64".to_string(); </ins> base.eliminate_frame_pointer = false; base.pre_link_args.push("-m64".to_string());


Question:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"

pub fn target() -> Target { let mut base = super::windows_base::opts(); <ins> base.cpu = "x86-64".to_string(); </ins> // On Win64 unwinding is handled by the OS, so we can link libgcc statically. base.pre_link_args.push("-static-libgcc".to_string()); base.pre_link_args.push("-m64".to_string());


Question:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"

pub fn target() -> Target { let mut base = super::dragonfly_base::opts(); <ins> base.cpu = "x86-64".to_string(); </ins> base.pre_link_args.push("-m64".to_string()); Target {


Question:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"

pub fn target() -> Target { let mut base = super::freebsd_base::opts(); <ins> base.cpu = "x86-64".to_string(); </ins> base.pre_link_args.push("-m64".to_string()); Target {


Question:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"

pub fn target() -> Target { let mut base = super::linux_base::opts(); <ins> base.cpu = "x86-64".to_string(); </ins> base.pre_link_args.push("-m64".to_string()); Target {


Question:
I've got bitten by: The compiler silently accepts this code, no warning at all, but nothing is derived. (rustc 1.0.0-nightly ( 2015-01-08 17:03:40 -0800))
I get two warnings with a more recent nightly ():
I tried playpen just now: And the output gives: I think it is a clear warning which is good enough.
If one uses the type in a place that needs the derived trait, one will get type errors before any of those warnings appear. E.g.
I've updated to rustc 1.0.0-nightly ( 2015-01-14 00:41:55 +0000). I'm getting same error as Even though it shows an error, I think this is a problem, because it shows a wrong, misleading error — the problem isn't in the line where value is copied. It's in the line which has been ignored. Because of that I've been pulling my hair out and tripple-checking all borrows in my program, documentation etc. and wondering why correctly-looking code does't work.

ext::log_syntax::expand_syntax_ext)); syntax_expanders.insert(intern("derive"), Decorator(box ext::deriving::expand_meta_derive)); <ins> syntax_expanders.insert(intern("deriving"), Decorator(box ext::deriving::expand_deprecated_deriving)); </ins> if ecfg.enable_quotes { // Quasi-quoting expanders


Question:
I've got bitten by: The compiler silently accepts this code, no warning at all, but nothing is derived. (rustc 1.0.0-nightly ( 2015-01-08 17:03:40 -0800))
I get two warnings with a more recent nightly ():
I tried playpen just now: And the output gives: I think it is a clear warning which is good enough.
If one uses the type in a place that needs the derived trait, one will get type errors before any of those warnings appear. E.g.
I've updated to rustc 1.0.0-nightly ( 2015-01-14 00:41:55 +0000). I'm getting same error as Even though it shows an error, I think this is a problem, because it shows a wrong, misleading error — the problem isn't in the line where value is copied. It's in the line which has been ignored. Because of that I've been pulling my hair out and tripple-checking all borrows in my program, documentation etc. and wondering why correctly-looking code does't work.

pub mod generic; <ins> pub fn expand_deprecated_deriving(cx: &mut ExtCtxt, span: Span, _: &MetaItem, _: &Item, _: Box<FnMut(P<Item>)>) { cx.span_err(span, "`deriving` has been renamed to `derive`"); } </ins> pub fn expand_meta_derive(cx: &mut ExtCtxt, _span: Span, mitem: &MetaItem,


Question:
I've got bitten by: The compiler silently accepts this code, no warning at all, but nothing is derived. (rustc 1.0.0-nightly ( 2015-01-08 17:03:40 -0800))
I get two warnings with a more recent nightly ():
I tried playpen just now: And the output gives: I think it is a clear warning which is good enough.
If one uses the type in a place that needs the derived trait, one will get type errors before any of those warnings appear. E.g.
I've updated to rustc 1.0.0-nightly ( 2015-01-14 00:41:55 +0000). I'm getting same error as Even though it shows an error, I think this is a problem, because it shows a wrong, misleading error — the problem isn't in the line where value is copied. It's in the line which has been ignored. Because of that I've been pulling my hair out and tripple-checking all borrows in my program, documentation etc. and wondering why correctly-looking code does't work.

<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. #[deriving(Clone)] //~ ERROR `deriving` has been renamed to `derive` struct Foo; fn main() {} </ins>


Question:
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 .

use middle::infer::InferCtxt; use middle::ty::{self, ToPredicate, HasTypeFlags, ToPolyTraitRef, TraitRef, Ty}; use middle::ty::fold::TypeFoldable; <del> use std::collections::HashMap; </del> <ins> use util::nodemap::{FnvHashMap, FnvHashSet}; </ins> use std::fmt; use syntax::codemap::Span; use syntax::attr::{AttributeMethods, AttrMetaMethods};


Question:
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 .

(gen.name.as_str().to_string(), trait_ref.substs.types.get(param, i) .to_string()) <del> }).collect::<HashMap<String, String>>(); </del> <ins> }).collect::<FnvHashMap<String, String>>(); </ins> generic_map.insert("Self".to_string(), trait_ref.self_ty().to_string()); let parser = Parser::new(&istring);


Question:
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 .

"the trait `{}` cannot be made into an object", tcx.item_path_str(trait_def_id)); <ins> let mut reported_violations = FnvHashSet(); </ins> for violation in violations { <ins> if !reported_violations.insert(violation.clone()) { continue; } </ins> match violation { ObjectSafetyViolation::SizedSelf => { tcx.sess.fileline_note(


Question:
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 .

use std::rc::Rc; use syntax::ast; <del> #[derive(Debug)] </del> <ins> #[derive(Clone, Debug, PartialEq, Eq, Hash)] </ins> pub enum ObjectSafetyViolation<'tcx> { /// Self : Sized declared on the trait SizedSelf,


Question:
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 .

} } <ins> impl<'tcx> PartialEq for Method<'tcx> { #[inline] fn eq(&self, other: &Self) -> bool { self.def_id == other.def_id } } impl<'tcx> Eq for Method<'tcx> {} impl<'tcx> Hash for Method<'tcx> { #[inline] fn hash<H: Hasher>(&self, s: &mut H) { self.def_id.hash(s) } } </ins> #[derive(Clone, Copy, Debug)] pub struct AssociatedConst<'tcx> { pub name: Name,


Question:
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 .

<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>


Question:
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.

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)


Question:
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.

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={}",


Question:
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.

/// 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, ()>>>, }


Question:
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.

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()), };


Question:
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.

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 }


Question:
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.

} } <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 {


Question:
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.

} 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)


Question:
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.

<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>


Question:
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.

<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>


Question:
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.

<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>


Question:
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?

/// /// ``` /// 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")]


Question:
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?

/// 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


Question:
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?

/// 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),


Question:
with rustc 1.0.0-nightly ( 2015-03-01) (built 2015-03-01)
This is still an issue
Still an issue in 1.0.0.
This is still an issue in 1.3.0-nightly: $ rustc error: internal compiler error: unexpected panic thread 'rustc' panicked at 'assertion failed: <= ()', stack backtrace: 1: 0x7fd6c19bd5ee - sys::backtrace::write::h04a6ced565b26815Lqs 2: 0x7fd6c19c5214 - panicking::onpanic::h521f84b604e22dfel8w 3: 0x7fd6c198804e - rt::unwind::beginunwindinner::hd3dee614a0e1c16cZNw 4: 0x7fd6c1988d7c - rt::unwind::beginunwindfmt::ha4ce6704c81423045Mw 5: 0x7fd6c19c4dd6 - rustbeginunwind 6: 0x7fd6c1a15bb4 - panicking::panicfmt::he89ea3094b3178e919B 7: 0x7fd6c1a0f9dd - panicking::panic::h9e565ee21070221by8B 8: 0x7fd6c11f8271 - astconv::finishresolvingdeftoty::h03670159ac2fefe7aTv 9: 0x7fd6c11b6340 - astconv::asttytoty::hb2c49d2cf31c029bYUv 10: 0x7fd6c1189eed - check::closure::checkexprclosure::hbce85e7beaf0ebd52zl 11: 0x7fd6c11d360b - check::checkexprwithunifier::h16314096699859592584 12: 0x7fd6c11f998b - check::checkdeclinitializer::h491ede37e45bce9e84r 13: 0x7fd6c11f9a4d - check::checkdecllocal::h1c782249285c9ae3m6r 14: 0x7fd6c11f9c79 - check::checkstmt::h48bf6ea3f412b86bf8r 15: 0x7fd6c11a91b3 - check::checkblockwithexpected::h072b2c4702c43b1cjcs 16: 0x7fd6c118bef4 - check::checkfn::h8218f9adb3734183iQn 17: 0x7fd6c11a35ca - check::checkbarefn::h3c567a2d1339f838RFn 18: 0x7fd6c11a1523 - check::checkitembody::h8e17e6521c30131ay6n 19: 0x7fd6c11a31e4 - check::checkitemtypes::h62e908b1d9f74b39oDn 20: 0x7fd6c12609b8 - checkcrate::h594ee0148d251222uZC 21: 0x7fd6c1f1dc69 - driver::phase3runanalysispasses::closure. 22: 0x7fd6c1f1c633 - middle::ty::ctxt<'tcx::createandenter::h349256048753845929 23: 0x7fd6c1f17a17 - driver::phase3runanalysispasses::h15521018079403107052 24: 0x7fd6c1efa266 - driver::compileinput::hbf698b02349f7ce3Tba 25: 0x7fd6c1fd3ed3 - runcompiler::hd724b5fef3441688y7b 26: 0x7fd6c1fd18ae - boxed::F.FnBox<A::callbox::h6609070342514802751 27: 0x7fd6c1fd10f9 - rt::unwind::try::tryfn::h10774555836369096370 28: 0x7fd6c1a3ed48 - rusttryinner 29: 0x7fd6c1a3ed35 - rusttry 30: 0x7fd6c19b08a7 - rt::unwind::try::innertry::hb0d7a3eb324339ceSJw 31: 0x7fd6c1fd130b - boxed::F.FnBox<A::callbox::h18179817771297192954 32: 0x7fd6c19c3e71 - sys::thread::Thread::new::threadstart::hf8c7448e27294ed0PTv 33: 0x7fd6bb60f353 - startthread 34: 0x7fd6c161ebfc - _clone 35: 0x0 - <unknown
$ rustc --version rustc 1.3.0-nightly ( 2015-06-30)
This problem has gone away for me now. It may have been from mixing versions? It may have gone away after a .
It is still an issue on nightly according to the playpen:
You're right. I must have been in the wrong project.
I just ran into the same assertion (with both stable 1.1 and nightly 1.3), but with different code. Would it help if I try to create another minimal working example and post it here or a new bug report? This is my backtrace: didn't help.
Okay here it is: Unfortunately it has something to do with glium, so I guess this doesn't help much :/
May be related, not sure: (rustc 1.2.0 ( 2015-08-03))
minimized:

debug!("(building reduced graph for external  crate) building type {}", final_ident); <ins> let modifiers = match new_parent.kind.get() { NormalModuleKind => modifiers, _ => modifiers & !DefModifiers::IMPORTABLE }; </ins> child_name_bindings.define_type(def, DUMMY_SP, modifiers); } DefStruct(def_id) => {


Question:
with rustc 1.0.0-nightly ( 2015-03-01) (built 2015-03-01)
This is still an issue
Still an issue in 1.0.0.
This is still an issue in 1.3.0-nightly: $ rustc error: internal compiler error: unexpected panic thread 'rustc' panicked at 'assertion failed: <= ()', stack backtrace: 1: 0x7fd6c19bd5ee - sys::backtrace::write::h04a6ced565b26815Lqs 2: 0x7fd6c19c5214 - panicking::onpanic::h521f84b604e22dfel8w 3: 0x7fd6c198804e - rt::unwind::beginunwindinner::hd3dee614a0e1c16cZNw 4: 0x7fd6c1988d7c - rt::unwind::beginunwindfmt::ha4ce6704c81423045Mw 5: 0x7fd6c19c4dd6 - rustbeginunwind 6: 0x7fd6c1a15bb4 - panicking::panicfmt::he89ea3094b3178e919B 7: 0x7fd6c1a0f9dd - panicking::panic::h9e565ee21070221by8B 8: 0x7fd6c11f8271 - astconv::finishresolvingdeftoty::h03670159ac2fefe7aTv 9: 0x7fd6c11b6340 - astconv::asttytoty::hb2c49d2cf31c029bYUv 10: 0x7fd6c1189eed - check::closure::checkexprclosure::hbce85e7beaf0ebd52zl 11: 0x7fd6c11d360b - check::checkexprwithunifier::h16314096699859592584 12: 0x7fd6c11f998b - check::checkdeclinitializer::h491ede37e45bce9e84r 13: 0x7fd6c11f9a4d - check::checkdecllocal::h1c782249285c9ae3m6r 14: 0x7fd6c11f9c79 - check::checkstmt::h48bf6ea3f412b86bf8r 15: 0x7fd6c11a91b3 - check::checkblockwithexpected::h072b2c4702c43b1cjcs 16: 0x7fd6c118bef4 - check::checkfn::h8218f9adb3734183iQn 17: 0x7fd6c11a35ca - check::checkbarefn::h3c567a2d1339f838RFn 18: 0x7fd6c11a1523 - check::checkitembody::h8e17e6521c30131ay6n 19: 0x7fd6c11a31e4 - check::checkitemtypes::h62e908b1d9f74b39oDn 20: 0x7fd6c12609b8 - checkcrate::h594ee0148d251222uZC 21: 0x7fd6c1f1dc69 - driver::phase3runanalysispasses::closure. 22: 0x7fd6c1f1c633 - middle::ty::ctxt<'tcx::createandenter::h349256048753845929 23: 0x7fd6c1f17a17 - driver::phase3runanalysispasses::h15521018079403107052 24: 0x7fd6c1efa266 - driver::compileinput::hbf698b02349f7ce3Tba 25: 0x7fd6c1fd3ed3 - runcompiler::hd724b5fef3441688y7b 26: 0x7fd6c1fd18ae - boxed::F.FnBox<A::callbox::h6609070342514802751 27: 0x7fd6c1fd10f9 - rt::unwind::try::tryfn::h10774555836369096370 28: 0x7fd6c1a3ed48 - rusttryinner 29: 0x7fd6c1a3ed35 - rusttry 30: 0x7fd6c19b08a7 - rt::unwind::try::innertry::hb0d7a3eb324339ceSJw 31: 0x7fd6c1fd130b - boxed::F.FnBox<A::callbox::h18179817771297192954 32: 0x7fd6c19c3e71 - sys::thread::Thread::new::threadstart::hf8c7448e27294ed0PTv 33: 0x7fd6bb60f353 - startthread 34: 0x7fd6c161ebfc - _clone 35: 0x0 - <unknown
$ rustc --version rustc 1.3.0-nightly ( 2015-06-30)
This problem has gone away for me now. It may have been from mixing versions? It may have gone away after a .
It is still an issue on nightly according to the playpen:
You're right. I must have been in the wrong project.
I just ran into the same assertion (with both stable 1.1 and nightly 1.3), but with different code. Would it help if I try to create another minimal working example and post it here or a new bug report? This is my backtrace: didn't help.
Okay here it is: Unfortunately it has something to do with glium, so I guess this doesn't help much :/
May be related, not sure: (rustc 1.2.0 ( 2015-08-03))
minimized:

// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(associated_consts)] </ins> pub use self::sub::{Bar, Baz}; pub trait Trait { fn foo(&self); <ins> type Assoc; const CONST: u32; </ins> } struct Foo; impl Foo { pub fn new() {} <ins> pub const C: u32 = 0; </ins> } mod sub {


Question:
with rustc 1.0.0-nightly ( 2015-03-01) (built 2015-03-01)
This is still an issue
Still an issue in 1.0.0.
This is still an issue in 1.3.0-nightly: $ rustc error: internal compiler error: unexpected panic thread 'rustc' panicked at 'assertion failed: <= ()', stack backtrace: 1: 0x7fd6c19bd5ee - sys::backtrace::write::h04a6ced565b26815Lqs 2: 0x7fd6c19c5214 - panicking::onpanic::h521f84b604e22dfel8w 3: 0x7fd6c198804e - rt::unwind::beginunwindinner::hd3dee614a0e1c16cZNw 4: 0x7fd6c1988d7c - rt::unwind::beginunwindfmt::ha4ce6704c81423045Mw 5: 0x7fd6c19c4dd6 - rustbeginunwind 6: 0x7fd6c1a15bb4 - panicking::panicfmt::he89ea3094b3178e919B 7: 0x7fd6c1a0f9dd - panicking::panic::h9e565ee21070221by8B 8: 0x7fd6c11f8271 - astconv::finishresolvingdeftoty::h03670159ac2fefe7aTv 9: 0x7fd6c11b6340 - astconv::asttytoty::hb2c49d2cf31c029bYUv 10: 0x7fd6c1189eed - check::closure::checkexprclosure::hbce85e7beaf0ebd52zl 11: 0x7fd6c11d360b - check::checkexprwithunifier::h16314096699859592584 12: 0x7fd6c11f998b - check::checkdeclinitializer::h491ede37e45bce9e84r 13: 0x7fd6c11f9a4d - check::checkdecllocal::h1c782249285c9ae3m6r 14: 0x7fd6c11f9c79 - check::checkstmt::h48bf6ea3f412b86bf8r 15: 0x7fd6c11a91b3 - check::checkblockwithexpected::h072b2c4702c43b1cjcs 16: 0x7fd6c118bef4 - check::checkfn::h8218f9adb3734183iQn 17: 0x7fd6c11a35ca - check::checkbarefn::h3c567a2d1339f838RFn 18: 0x7fd6c11a1523 - check::checkitembody::h8e17e6521c30131ay6n 19: 0x7fd6c11a31e4 - check::checkitemtypes::h62e908b1d9f74b39oDn 20: 0x7fd6c12609b8 - checkcrate::h594ee0148d251222uZC 21: 0x7fd6c1f1dc69 - driver::phase3runanalysispasses::closure. 22: 0x7fd6c1f1c633 - middle::ty::ctxt<'tcx::createandenter::h349256048753845929 23: 0x7fd6c1f17a17 - driver::phase3runanalysispasses::h15521018079403107052 24: 0x7fd6c1efa266 - driver::compileinput::hbf698b02349f7ce3Tba 25: 0x7fd6c1fd3ed3 - runcompiler::hd724b5fef3441688y7b 26: 0x7fd6c1fd18ae - boxed::F.FnBox<A::callbox::h6609070342514802751 27: 0x7fd6c1fd10f9 - rt::unwind::try::tryfn::h10774555836369096370 28: 0x7fd6c1a3ed48 - rusttryinner 29: 0x7fd6c1a3ed35 - rusttry 30: 0x7fd6c19b08a7 - rt::unwind::try::innertry::hb0d7a3eb324339ceSJw 31: 0x7fd6c1fd130b - boxed::F.FnBox<A::callbox::h18179817771297192954 32: 0x7fd6c19c3e71 - sys::thread::Thread::new::threadstart::hf8c7448e27294ed0PTv 33: 0x7fd6bb60f353 - startthread 34: 0x7fd6c161ebfc - _clone 35: 0x0 - <unknown
$ rustc --version rustc 1.3.0-nightly ( 2015-06-30)
This problem has gone away for me now. It may have been from mixing versions? It may have gone away after a .
It is still an issue on nightly according to the playpen:
You're right. I must have been in the wrong project.
I just ran into the same assertion (with both stable 1.1 and nightly 1.3), but with different code. Would it help if I try to create another minimal working example and post it here or a new bug report? This is my backtrace: didn't help.
Okay here it is: Unfortunately it has something to do with glium, so I guess this doesn't help much :/
May be related, not sure: (rustc 1.2.0 ( 2015-08-03))
minimized:

use use_from_trait_xc::Trait::foo; //~^ ERROR `foo` is not directly importable <ins> use use_from_trait_xc::Trait::Assoc; //~^ ERROR `Assoc` is not directly importable use use_from_trait_xc::Trait::CONST; //~^ ERROR `CONST` is not directly importable </ins> use use_from_trait_xc::Foo::new; //~^ ERROR `new` is not directly importable <ins> use use_from_trait_xc::Foo::C; //~^ ERROR unresolved import `use_from_trait_xc::Foo::C` </ins> use use_from_trait_xc::Bar::new as bnew; //~^ ERROR `bnew` is not directly importable


Question:
with rustc 1.0.0-nightly ( 2015-03-01) (built 2015-03-01)
This is still an issue
Still an issue in 1.0.0.
This is still an issue in 1.3.0-nightly: $ rustc error: internal compiler error: unexpected panic thread 'rustc' panicked at 'assertion failed: <= ()', stack backtrace: 1: 0x7fd6c19bd5ee - sys::backtrace::write::h04a6ced565b26815Lqs 2: 0x7fd6c19c5214 - panicking::onpanic::h521f84b604e22dfel8w 3: 0x7fd6c198804e - rt::unwind::beginunwindinner::hd3dee614a0e1c16cZNw 4: 0x7fd6c1988d7c - rt::unwind::beginunwindfmt::ha4ce6704c81423045Mw 5: 0x7fd6c19c4dd6 - rustbeginunwind 6: 0x7fd6c1a15bb4 - panicking::panicfmt::he89ea3094b3178e919B 7: 0x7fd6c1a0f9dd - panicking::panic::h9e565ee21070221by8B 8: 0x7fd6c11f8271 - astconv::finishresolvingdeftoty::h03670159ac2fefe7aTv 9: 0x7fd6c11b6340 - astconv::asttytoty::hb2c49d2cf31c029bYUv 10: 0x7fd6c1189eed - check::closure::checkexprclosure::hbce85e7beaf0ebd52zl 11: 0x7fd6c11d360b - check::checkexprwithunifier::h16314096699859592584 12: 0x7fd6c11f998b - check::checkdeclinitializer::h491ede37e45bce9e84r 13: 0x7fd6c11f9a4d - check::checkdecllocal::h1c782249285c9ae3m6r 14: 0x7fd6c11f9c79 - check::checkstmt::h48bf6ea3f412b86bf8r 15: 0x7fd6c11a91b3 - check::checkblockwithexpected::h072b2c4702c43b1cjcs 16: 0x7fd6c118bef4 - check::checkfn::h8218f9adb3734183iQn 17: 0x7fd6c11a35ca - check::checkbarefn::h3c567a2d1339f838RFn 18: 0x7fd6c11a1523 - check::checkitembody::h8e17e6521c30131ay6n 19: 0x7fd6c11a31e4 - check::checkitemtypes::h62e908b1d9f74b39oDn 20: 0x7fd6c12609b8 - checkcrate::h594ee0148d251222uZC 21: 0x7fd6c1f1dc69 - driver::phase3runanalysispasses::closure. 22: 0x7fd6c1f1c633 - middle::ty::ctxt<'tcx::createandenter::h349256048753845929 23: 0x7fd6c1f17a17 - driver::phase3runanalysispasses::h15521018079403107052 24: 0x7fd6c1efa266 - driver::compileinput::hbf698b02349f7ce3Tba 25: 0x7fd6c1fd3ed3 - runcompiler::hd724b5fef3441688y7b 26: 0x7fd6c1fd18ae - boxed::F.FnBox<A::callbox::h6609070342514802751 27: 0x7fd6c1fd10f9 - rt::unwind::try::tryfn::h10774555836369096370 28: 0x7fd6c1a3ed48 - rusttryinner 29: 0x7fd6c1a3ed35 - rusttry 30: 0x7fd6c19b08a7 - rt::unwind::try::innertry::hb0d7a3eb324339ceSJw 31: 0x7fd6c1fd130b - boxed::F.FnBox<A::callbox::h18179817771297192954 32: 0x7fd6c19c3e71 - sys::thread::Thread::new::threadstart::hf8c7448e27294ed0PTv 33: 0x7fd6bb60f353 - startthread 34: 0x7fd6c161ebfc - _clone 35: 0x0 - <unknown
$ rustc --version rustc 1.3.0-nightly ( 2015-06-30)
This problem has gone away for me now. It may have been from mixing versions? It may have gone away after a .
It is still an issue on nightly according to the playpen:
You're right. I must have been in the wrong project.
I just ran into the same assertion (with both stable 1.1 and nightly 1.3), but with different code. Would it help if I try to create another minimal working example and post it here or a new bug report? This is my backtrace: didn't help.
Okay here it is: Unfortunately it has something to do with glium, so I guess this doesn't help much :/
May be related, not sure: (rustc 1.2.0 ( 2015-08-03))
minimized:

// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(associated_consts)] </ins> use Trait::foo; //~^ ERROR `foo` is not directly importable <ins> use Trait::Assoc; //~^ ERROR `Assoc` is not directly importable use Trait::C; //~^ ERROR `C` is not directly importable </ins> use Foo::new; //~^ ERROR unresolved import `Foo::new`. Not a module `Foo` <ins> use Foo::C2; //~^ ERROR unresolved import `Foo::C2`. Not a module `Foo` </ins> pub trait Trait { fn foo(); <ins> type Assoc; const C: u32; </ins> } struct Foo; impl Foo { fn new() {} <ins> const C2: u32 = 0; </ins> } fn main() {}


Question:
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

/// 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);


Question:
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,

<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>


Question:
Reading the current documentation about at it is not clear to me what the effect of is. I was supposing calling this function returns the value stored in the Option type and replaces it by an value. However, this seems not to be the case as the second assertion in the following example program passes fine: (You can run the program online at ). In addition, the current documentation says: Does this means the value contained in the is moved out or cloned or is a borrow taken? Also, is a type and I don't think that the function really returns a type, but a value of type . Therefore, should the quoted sentence maybe reworded towards something along the lines of: Please let me know what you think about these points. I am more than happy to provide a PR to improve the documentation, but I don't know all the answers to the questions I have raised above and I am also not sure if my claims are correct :/
moves the value out of the option if it is , or panics if it is . In your example, the call to performs an implicit copy of because is of type , and implements when implements (as does). This example will not compile, because does not implement : The error is: The documentation could be updated to mention moving, but this is implicit in the method's parameter, which is by-value.
thanks a lot for your explanation! Still, I don't think I grasped how the works completely yet. Here is an example: I understand that moving a value from a borrowed object is not possible and that's why the first attempt fails. However, I don't see why the second attempt works. In a sense, the new type after the call to can be written as with . In that case the call to as done in looks to me again as a move. But as is borrowed, I don't see why this move is different from the first move attempt in my code, which failed. Is there a special rule to the method, which makes the later case work but the first not or am I missing something on how the borrow/move rules in rust work?
Basically, in order to call , you need to have an owned . This is the case in your "ATTEMPT WORKS" code because goes from to . The code under "ATTEMPT FAILED" doesn't compile because is borrowed (), not because contains a borrowed value. For example, the following code does compile:
Thanks again The point that you need an owned makes sense to me and was something I was not that much aware about before :) What I don't see at this point is why in my example is not an owned already. As you can see in this code example: It seems that is of the owning type already. From reading your last comment it sounds to me that is supposed to be of type with here. But that is something I don't see yet :/ Any comments is highly appreciated! PS: I hope digging deeper on this issue is okay for you? From your comments so far I think I can fix the documentation but still I would love to have a good overall understanding how the interaction with really works :)
In that example, the type of is indeed , but it is not owned from the perspective of the compiler, because it is accessed through a reference ().
Ahh, I think now I get it - thanks a lot Are these the (hidden) steps the compiler is doing when executing ? The compiler knows that is of type The definition of is given by , which means for calling the , the must be a mutable borrow. As the is NOT a mutable borrow, the compiler takes an implicit mutable borrow like and uses the result as the argument when calling . The call to does type check and returns a fully owned type. Here I am using the term "fully owned" to differentiate to the case of the previous which is not owned due to the access through the reference of . Because the result of is now fully owned, the call to type checks. I've got to say: I love and be impressed what the rust compiler is doing underneath here (once you understand it :) )! thank you sooo much for these helpful and very educational comments!!!
So, given all this: is there anything actionable we can do to improve these docs? What would you suggest, ?
how do you feel about this: the description gave as sounds much better and is more precise compared to the current description of , which is . Therefore, I would love to exchange them. do you think there is value in adding a section about and how it works to the existing documentation?
I like it! would you like to submit a PR or should I take care of it? I'm not sure.
I don't think we need to add anything about , because there's nothing special about it. It just follows Rust's ownership and borrowing rules. However, 's documentation in general does need work, both convention-wise and content-wise.

} } <del> /// Returns the inner `T` of a `Some(T)`. </del> <ins> /// Moves the value `v` out of the `Option<T>` if the content of the `Option<T>` is a `Some(v)`. </ins> /// /// # Panics ///


Question:
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.

<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. //


Question:
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.

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> {


Question:
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.

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,