jiebi/CodeConvo huggingface dataset:
Change:
This code compiles right now, even though its a) attached to a struct and not a function, and b) used outside a proc-macro crate.

Discussion:
match item.node { ast::ItemKind::Fn(..) => {} _ => { <ins> // Check for invalid use of proc_macro_derive let attr = item.attrs.iter() .filter(|a| a.check_name("proc_macro_derive")) .next(); if let Some(attr) = attr { self.handler.span_err(attr.span(), "the `#[proc_macro_derive]`  attribute may only be used  on bare functions"); return; } </ins> self.check_not_pub_in_root(&item.vis, item.span); return visit::walk_item(self, item) }

<ins> // Copyright 2016 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(proc_macro)] extern crate proc_macro; #[proc_macro_derive(Foo)] //~^ ERROR: only usable with crates of the `proc-macro` crate type pub fn foo(a: proc_macro::TokenStream) -> proc_macro::TokenStream { a } // Issue #37590 #[proc_macro_derive(Foo)] //~^ ERROR: the `#[proc_macro_derive]` attribute may only be used on bare functions pub struct Foo { } fn main() {} </ins>

<del> // Copyright 2016 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(proc_macro)] extern crate proc_macro; #[proc_macro_derive(Foo)] //~^ ERROR: only usable with crates of the `proc-macro` crate type pub fn foo(a: proc_macro::TokenStream) -> proc_macro::TokenStream { a } fn main() {} </del>
Change:
My bad, there's a temporary that ended up in a discriminant. Minimal testcase: The can be fixed by pulling it out into a variable, .

Discussion:
} PatKind::Tuple(ref subpatterns, ddpos) => { <del> match self.tcx.tables().node_id_to_type(pat.id).sty { </del> <ins> let ty = self.tcx.tables().node_id_to_type(pat.id); match ty.sty { </ins> ty::TyTuple(ref tys) => { let subpatterns = subpatterns.iter()

<ins> // Copyright 2016 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. fn main() { match (0, 0) { (std::usize::MIN, std::usize::MAX) => {} _ => {} } } </ins>
Change:
Code: Compiles on 1.13-stable,beta, fails on 1.14-nightly.
(Forget that, see below).
Apart from that, this was introduced between and ().
I strongly suspect this is an unintended side effect of Prohibiting this deliberately doesn't make any sense, empty lists are allowed in () all other possible contexts.
Yeah, I probably mis-remembered :( I agree that this was probably a side effect of .
In fact, this fails too:

Discussion:
if let Some(recv) = followed_by_ty_params { assert!(recv.is_empty()); *recv = attrs; <del> } else { </del> <ins> debug!("parse_lifetime_defs ret {:?}", res); return Ok(res); } else if !attrs.is_empty() { </ins> let msg = "trailing attribute after lifetime parameters"; return Err(self.fatal(msg)); } <del> debug!("parse_lifetime_defs ret {:?}", res); return Ok(res); </del> } }

<ins> // Copyright 2016 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. type A = for<> fn(); type B = for<'a,> fn(); pub fn main() {} </ins>
Change:
If document strings for rustdoc are written as a sequence of single line comments (i.e. ///) then rustdoc only uses the first line. The whole sequence should be joined to form a single attribute for further processing.
I would be happy to have a look at this (I guess maybe I caused the issue).
It seems like one way to fix this issue would be to have rustdoc concatenate all doc-attributes/doc-comments for an item and use the concatenated text as if it were from a single doc-attribute/comment. Currently rustdoc discards all but the first doc-attribute, and emits a warning that the others were discarded. However the warning is emitted using warn!(...) which means it doesn't actually display to the user unless they have turned on warn logging for rustdoc, which seems unlikely. Would this approach (concatenating all doc-comments) be ok?
Another approach would be to change the lexer so that it parses multiple adjacent lines that all start with /// as a single doc-comment.
Having rustdoc concatenate the attributes sounds good to me.
You're right, I ran rustdoc without warnings being logged. Are you referring to fn docmeta in That looks like it would be a sensible place to do the concatenation.
Yup. See the pull request - it makes multi-line comments work the same as comments (as a side effect of concatenating all kinds of doc-comment). Unfortunately multi-line comments seem a bit broken in general with rustdoc. In html output mode they are concatenated into a single line (I think due to some weirdness with pandoc).
Fixed by

Discussion:
} } <del> fn doc_meta( attrs: ~[ast::attribute] ) -> Option<@ast::meta_item> { /*! * Given a vec of attributes, extract the meta_items contained in the  * doc attribute */ let doc_metas = doc_metas(attrs); if vec::is_not_empty(doc_metas) { if vec::len(doc_metas) != 1u { warn!("ignoring %u doc attributes", vec::len(doc_metas) - 1u); } Some(doc_metas[0]) } else { None } } </del> fn doc_metas( attrs: ~[ast::attribute] ) -> ~[@ast::meta_item] {

} fn parse_desc(attrs: ~[ast::attribute]) -> Option<~str> { <del> match doc_meta(attrs) { Some(meta) => { attr::get_meta_item_value_str(meta) } None => None </del> <ins> let doc_strs = do doc_metas(attrs).filter_map |meta| { attr::get_meta_item_value_str(*meta) }; if doc_strs.is_empty() { None } else { Some(str::connect(doc_strs, "n")) </ins> } }

let attrs = test::parse_attributes(source); assert parse_hidden(attrs) == false; } <ins> #[test] fn should_concatenate_multiple_doc_comments() { let source = ~"/// foon/// bar"; let desc = parse_desc(test::parse_attributes(source)); assert desc == Some(~"foonbar"); } </ins>
Change:
The trait system seems to be missing a normalization in bounds for associated items: produces the error:
cc
Note that this version works: (Removing the )
, which compiles.
This now compiles.

Discussion:
<ins> // check-pass #![allow(unused)] trait Bar<T> { fn dummy(&self); } trait Foo { type A; type B: Bar<Self::A>; fn get_b(&self) -> &Self::B; } fn test_bar<A, B: Bar<A>>(_: &B) {} fn test<A, F: Foo<A = A>>(f: &F) { test_bar(f.get_b()); } trait Bar1<T> {} trait Caz1 { type A; type B: Bar1<Self::A>; } fn test1<T, U>() where T: Caz1, U: Caz1<A = T::A> {} trait Bar2<T> {} trait Caz2 { type A; type B: Bar2<Self::A>; } fn test2<T: Caz2<A = ()>>() {} fn main() {} </ins>

<ins> // check-pass trait Parent { type Ty; type Assoc: Child<Self::Ty>; } trait Child<T> {} struct ChildWrapper<T>(T); impl<A, T> Child<A> for ChildWrapper<T> where T: Child<A> {} struct ParentWrapper<T>(T); impl<A, T: Parent<Ty = A>> Parent for ParentWrapper<T> { type Ty = A; type Assoc = ChildWrapper<T::Assoc>; } fn main() {} </ins>

<ins> // check-pass use std::ops::Mul; fn main() {} trait Ring {} trait Real: Ring {} trait Module: Sized + Mul<<Self as Module>::Ring, Output = Self> { type Ring: Ring; } trait EuclideanSpace { type Coordinates: Module<Ring = Self::Real>; type Real: Real; } trait Translation<E: EuclideanSpace> { fn to_vector(&self) -> E::Coordinates; fn powf(&self, n: <E::Coordinates as Module>::Ring) -> E::Coordinates { self.to_vector() * n } } </ins>

<ins> // check-pass #![allow(unused)] trait Foo { type Bar; type Baz: Bar<Self::Bar>; } trait Bar<T> {} fn x<T: Foo<Bar = U>, U>(t: &T) {} fn main() {} </ins>
Change:
The cross-compiled MIPS host compilers are fine, but stage1 immediately segfaults when asked to do just about anything: Notice the recursion, which is obviously wrong, and non-existent on stage0: This is . Maybe we should incorporate the workaround there as well.
This seems more complete than the one found in the LLVM bug thread.
It looks like the binaries we're distributing don't have this recursion, so I guess this is only happening when you're bootstrapping locally? If so, what compiler are you using? It'd be useful to drill into the command that actually compiled so we can figure out what's going on here.
I'm indeed bootstrapping natively on MIPS64el. output: Rust revision used is with applied. I'll try to look into the actual compiler invocation, as even though I applied the workaround the resulting still is broken.
The compiler invocation is like this (newlines by me): Ignore my previous comment that the workaround was ignored, I forgot to commit the submodule update and rustbuild reverted it to a previously broken one. The generated code now looks like this: But the function called is now (not in the output; MIPS objdump seems feature-lacking). I kicked off compilation now, hopefully stage1 would be done several hours later (the hardware is slow). I'll run some tests to see if the workaround really worked.
Hm ok, so is the same bug still happening? Or we're waiting to see if it's a new bug? Also, what was the workaround you applied? (e.g. the patch)
The commit is xen0n/compiler-rt I just saw a different crash but it's probably unrelated and spurious, I'm restarting the build to see if that's the case.
As for the bug: it is presumably fixed by the workaround. But we can never be sure until we've run the tests.
Quick update: the double free was indeed spurious, the build is happily running now. Unfortunately I can't test the stage1 immediately, it's 3 am here. I'll see if the build can progress to anything more than stage1 later in the day.
If you want to send that patch to our compiler-rt fork, I'd be happy to merge!
Problem solved, finished this morning and test failures are few, currently there are which are all expected to fail on MIPS but not ignored. I'll prepare a PR to shortly.
I've opened rust-lang/compiler-rt. I'll open another PR to update the submodule after that PR is merged.

Discussion:
<del> Subproject commit 3bc0272cab9fdcfc2ef4df9625ec3c9d5909db79 </del> <ins> Subproject commit a8fc4c169fac43a5dc204d4fd56ddb1739f8c178 </ins>
Change:
This ensures that someone looking at the documentation who searches for the word "length" to find the method which returns the length of the method will be able to find the method, and also explains the origin of the name if someone is unaware. I bring this up because one of my coworkers came to me asking for the name of the method, because they were having trouble finding it in the documentation.
The problem with this is that it's generally bad to include this in the summary, as it's just repeating what's already been said. So I didn't do this on purpose. I'm not sure what exact text rustdoc searches though.... i'd be against putting this in the summary, but for putting it in the longer description
We seem to be very inconsistent about what summaries to use for methods: Some say "length" and some say "number of elements". Perhaps changing them all to say something like "Returns the number of elements in / length of the slice." would help here.
It doesn't need to be in the summary(?), it can be in the body of the doc. already finds and and so on, so the focus is simply in Ctrl+F search inside the doc page itself (if I understand correctly?).

Discussion:
self.truncate(0) } <del> /// Returns the number of elements in the vector. </del> <ins> /// Returns the number of elements in the vector, also referred to /// as its 'length'. </ins> /// /// # Examples ///
Change:
According to and in , this feature-gate should not be used. It appears that earlier error checking in the compiler prevents it from ever mattering anyway.

Discussion:
* `unboxed_closures` - Rust's new closure design, which is currently a work in progress feature with many known bugs. <del> * `unmarked_api` - Allows use of items within a `#![staged_api]` crate which have not been marked with a stability marker. Such items should not be allowed by the compiler to exist, so if you need this there probably is a compiler bug. </del> * `allow_internal_unstable` - Allows `macro_rules!` macros to be tagged with the `#[allow_internal_unstable]` attribute, designed to allow `std` macros to call

// handled by the lint emitting logic above. } None => { <del> // This is an 'unmarked' API, which should not exist // in the standard library. if self.sess.features.borrow().unmarked_api { self.sess.struct_span_warn(span, "use of unmarked library feature") .span_note(span, "this is either a bug in the library you are  using or a bug in the compiler - please  report it in both places") .emit() } else { self.sess.struct_span_err(span, "use of unmarked library feature") .span_note(span, "this is either a bug in the library you are  using or a bug in the compiler - please  report it in both places") .span_note(span, "use #![feature(unmarked_api)] in the  crate attributes to override this") .emit() } </del> <ins> span_bug!(span, "encountered unmarked API"); </ins> } } }

// rustc internal (active, staged_api, "1.0.0", None), <del> // Allows using items which are missing stability attributes // rustc internal (active, unmarked_api, "1.0.0", None), </del> // Allows using #![no_core] (active, no_core, "1.3.0", Some(29639)),

(removed, test_removed_feature, "1.0.0", None), (removed, visible_private_types, "1.0.0", None), (removed, unsafe_no_drop_flag, "1.0.0", None), <ins> // Allows using items which are missing stability attributes // rustc internal (removed, unmarked_api, "1.0.0", None), </ins> ); declare_features! (
Change:
This code () gives me a segfault on the current beta: I've reduced it as much as I can, even removing the constructor on the enum causes it to work. I expect the output to be (which it is on stable), but instead I get
Appears to be broken on nightly as well - I get a stack overflow on x86_64 darwin.
FWIW, I don't get a segfault on beta or nightly with the playpen, I just get this output for both:
The stackoverflow on x86_64 darwin goes away for me on any .
This strongly reminds me of and .

Discussion:
let lldiscr = C_integral(Type::from_integer(ccx, d), discr.0 as u64, true); let mut vals_with_discr = vec![lldiscr]; vals_with_discr.extend_from_slice(vals); <del> let mut contents = build_const_struct(ccx, &variant, &vals_with_discr[..]); let needed_padding = l.size(dl).bytes() - variant.min_size.bytes(); </del> <ins> let mut contents = build_const_struct(ccx, &variant, &vals_with_discr[..]); let needed_padding = l.size(dl).bytes() - variant.stride().bytes(); </ins> if needed_padding > 0 { contents.push(padding(ccx, needed_padding)); }

} layout::Univariant { ref variant, .. } => { assert_eq!(discr, Disr(0)); <del> let contents = build_const_struct(ccx, &variant, vals); </del> <ins> let contents = build_const_struct(ccx, &variant, vals); </ins> C_struct(ccx, &contents[..], variant.packed) } layout::Vector { .. } => {

} layout::StructWrappedNullablePointer { ref nonnull, nndiscr, .. } => { if discr.0 == nndiscr { <del> C_struct(ccx, &build_const_struct(ccx, &nonnull, vals), false) </del> <ins> C_struct(ccx, &build_const_struct(ccx, &nonnull, vals), false) </ins> } else { let fields = compute_fields(ccx, t, nndiscr as usize, false); let vals = fields.iter().map(|&ty| {

// field; see #8506. C_null(type_of::sizing_type_of(ccx, ty)) }).collect::<Vec<ValueRef>>(); <del> C_struct(ccx, &build_const_struct(ccx, &nonnull, &vals[..]), false) </del> <ins> C_struct(ccx, &build_const_struct(ccx, &nonnull, &vals[..]), false) </ins> } } _ => bug!("trans_const: cannot handle type {} repreented as {:#?}", t, l)

<ins> // Copyright 2016 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. // Check that constant ADTs are translated OK, part k of N. #![feature(slice_patterns)] enum Bar { C } enum Foo { A {}, B { y: usize, z: Bar }, } const LIST: [(usize, Foo); 2] = [ (51, Foo::B { y: 42, z: Bar::C }), (52, Foo::B { y: 45, z: Bar::C }), ]; pub fn main() { match LIST { [ (51, Foo::B { y: 42, z: Bar::C }), (52, Foo::B { y: 45, z: Bar::C }) ] => {} _ => { // I would want to print the enum here, but if // the discriminant is garbage this causes an // `unreachable` and silent process exit. panic!("trivial match failed") } } } </ins>
Change:
with: (In this example: and ) when configured with or with . I think this is because rustbuild tries to use the that's supposed to be generated by building LLVM for but rusbuild nevers builds LLVM for in this case. cc
Call: before .
Fixed in

Discussion:
.run(move |s| compile::assemble_rustc(build, s.stage, s.target)); rules.build("llvm", "src/llvm") .host(true) <ins> .dep(move |s| { if s.target == build.config.build { dummy(s, build) } else { s.target(&build.config.build) } }) </ins> .run(move |s| native::llvm(build, s.target)); // ========================================================================
Change:
(In this example and ) This part: seems unnecessary as that compiler won't be used in the bootstrap (in fact, it can be executed by the build machine due to the differences in architectures) and it's not the requested rustc either. cc
Also it seems the wrong is being copied into the output directory: should be not , right?
Hm ok some of this is expected, some of this isn't expected. I can't seem to quite make sense of your original logs, though. Are you sure that was executed exactly to produce that trace? I unfortunately can't seem to reconstruct the sequence of events on master that'd lead to that.
repro as a shell script
Ok addressed in (this path redirected to the wrong step) but it'll need as well to be maximally effective.

Discussion:
}); } for (krate, path, default) in krates("rustc-main") { <ins> // We hijacked the `src/rustc` path above for "build just the compiler" // so let's not reinterpret it here as everything and redirect the // `src/rustc` path to a nonexistent path. let path = if path == "src/rustc" { "path/to/nowhere" } else { path }; </ins> rules.build(&krate.build_step, path) .dep(|s| s.name("libtest")) .dep(move |s| s.name("llvm").host(&build.config.build).stage(0))
Change:
Sometimes it is very useful when rustc figures out that the faulty module use you just made is probably just a typo and directs you a potential match (thanks for that!). However it also directs you to potential matches which haven't been found either in certain cases, for example compiling currently (2016-11-28) yields with both stable and nightly the following output: While this is merely a suggestion displayed and shouldn't cause any harm at all maybe it might still be worth to check if what is suggested was actually found in the current scope. Or would that be too expensive (e.g. overhead in tracking what was already successfully imported and what not) and is thus left as is by design?
Is this easy to fix ? If so - maybe worth marking as so and mentioning on Rust Weekly ?
Yeah, I believe this can be fixed by replacing with .
I think I can take this, if it hasn't been worked on so far!
go for it
How can I assign myself?
Not sure if you can via github, due to permissions, but you can just start working on it :) There's a trace in the comments, anyone looking for more work would see them hopefully here in this issue.

Discussion:
let names = resolutions.iter().filter_map(|(&(ref i, _), resolution)| { if *i == ident { return None; } // Never suggest the same name match *resolution.borrow() { <del> NameResolution { binding: Some(_), .. } => Some(&i.name), </del> <ins> NameResolution { binding: Some(name_binding), .. } => { match name_binding.kind { NameBindingKind::Import { binding, .. } => { match binding.kind { // Never suggest the name that has binding error // i.e. the name that cannot be previously resolved NameBindingKind::Def(Def::Err) => return None, _ => Some(&i.name), } }, _ => Some(&i.name), } }, </ins> NameResolution { single_imports: SingleImports::None, .. } => None, _ => Some(&i.name), }

<ins> // Copyright 2017 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. use Foo; use Foo1; fn main() {} </ins>

<ins> error[E0432]: unresolved import `Foo` --> $DIR/issue-38054-do-not-show-unresolved-names.rs:11:5 | 11 | use Foo; |     ^^^ no `Foo` in the root error[E0432]: unresolved import `Foo1` --> $DIR/issue-38054-do-not-show-unresolved-names.rs:13:5 | 13 | use Foo1; |     ^^^^ no `Foo1` in the root error: aborting due to 2 previous errors </ins>
Change:
Tagging as E-easy and E-mentor. The fix here involves changing the code to call to prevent the temp dir from destroying itself. This should be wrapped in an if like this one:
Hi, I want to try working on this.
Go ahead! Let me know if you need any assistance - feel free to either reach out here or over IRC (simulacrum is my handle there).

Discussion:
out_filenames.push(out_filename); } <ins> if sess.opts.cg.save_temps { let _ = tmpdir.into_path(); } </ins> out_filenames }