jiebi/CodeConvo huggingface dataset:
Code change:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by

Related discussion:
text: <ins> // Copyright 2018 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 for issue #18804, #[linkage] does not propagate thorugh generic // functions. Failure results in a linker error. // ignore-asmjs no weak symbol support // ignore-emscripten no weak symbol support // aux-build:lib.rs extern crate lib; fn main() { lib::foo::<i32>(); } </ins>
Code change:
This was the smallest I could make it. Commenting out the lines for either or or making and the same type allows compilation to finish successfully. Error: What I don't understand is: why in the world is it even complaining about implementations when no one is using ? Is this some sort of weird interaction with trait object types? (rustc at commit , Linux)
I've been seeing this too, any time I have a trait with two associated types that are different. Still happens as of the current nightly. Strangely, if you make them the same (i.e. "type T0 = f32; type T1 = f32;" in the impl), the error goes away.
This seems to be fixed. The example compiles on

Related discussion:
text: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Tup { type T0; type T1; } impl Tup for isize { type T0 = f32; type T1 = (); } fn main() {} </ins>
Code change:
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: !

Related discussion:
text: 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(()) } }
Code change:
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: !

Related discussion:
text: 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") {
Code change:
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: !

Related discussion:
text: id = short, name = name)); } <del> 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, "<code> = </code>")); if s.contains("n") { match item.href() { Some(url) => { write!(f, "<a href='{}'>[definition]</a>", url) } None => Ok(()), } } else { write!(f, "<code>{}</code>", s.as_slice()) } } } </del> match myitem.inner { <del> clean::StaticItem(ref s) | clean::ForeignStaticItem(ref s) => { try!(write!(w, " <tr> <td>{}<code>{}static {}{}: {}</code>{}</td> <td class='docblock'>{}&nbsp;</td> </tr> ", 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, " <tr> <td>{}<code>{}const {}: {}</code>{}</td> <td class='docblock'>{}&nbsp;</td> </tr> ", 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())))); } </del> clean::ViewItemItem(ref item) => { match item.inner { clean::ExternCrate(ref name, ref src, _) => {
Code change:
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: !

Related discussion:
text: write!(w, "</table>") } <ins> 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, "<code> = </code>")); write!(f, "<code>{}</code>", s.as_slice()) } } fn item_constant(w: &mut fmt::Formatter, it: &clean::Item, c: &clean::Constant) -> fmt::Result { try!(write!(w, "<pre class='rust const'>{vis}const  {name}: {typ}{init}</pre>", 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, "<pre class='rust static'>{vis}static {mutability} {name}: {typ}{init}</pre>", 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) } </ins> fn item_function(w: &mut fmt::Formatter, it: &clean::Item, f: &clean::Function) -> fmt::Result { try!(write!(w, "<pre class='rust fn'>{vis}{fn_style}fn
Code change:
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.

Related discussion:
text: } } <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 ///
Code change:
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.

Related discussion:
text: 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;
Code change:
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.

Related discussion:
text: } } <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> {
Code change:
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.

Related discussion:
text: 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)) }
Code change:
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.

Related discussion:
text: <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>
Code change:
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...

Related discussion:
text: // 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
Code change:
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

Related discussion:
text: 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(..) |
Code change:
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

Related discussion:
text: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // 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>
Code change:
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!

Related discussion:
text: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait T : Iterator<Item=Self::Item> //~^ ERROR unsupported cyclic reference between types/traits detected {} fn main() {} </ins>