jiebi/CodeConvo huggingface dataset:
Code change:
Full code: Given a smart pointer, which only works on types implementing the trait or on trait objects, such that is allowed to coerce to , and the corresponding implementation : Applying the operator on two will try to coerce them to , even though this isn't needed. This is an issue since coercion moves the original pointer. Removing the implementation lets the code build, which means that the coercion is not needed. As , if the is restricted to pointers with identical types (), then no coercion occurs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Seems related to
I've discovered a simpler reproduction: Curiously, when you just do , there's no problem. The overeager coercion can only occur in the presence of type inference. It also only occurs when the is non-parametric, i.e. not written like this: Likely because this allows to coerce to itself, hiding the issue. This also explains why it hasn't come up in the stdlib, because no type tries to coerce to a specific unsized type; it's all parametric.
The original code compiles with no errors today, so seems like E-needstest.
I think I tested the wrong thing; not E-needstest.
The linked reproduction from no longer fails to compile; is this fixed?
This is fixed but does need a test, though I think it could also be closed without a test, since it's been open for so long there's probably already coverage :thinking:
I think we should add the test just to be sure.
claim

Related discussion:
text: <ins> // check-pass #![feature(coerce_unsized, unsize)] use std::marker::Unsize; use std::ops::CoerceUnsized; struct Foo<T: ?Sized>(Box<T>); impl<T> CoerceUnsized<Foo<dyn Baz>> for Foo<T> where T: Unsize<dyn Baz> {} struct Bar; trait Baz {} impl Baz for Bar {} fn main() { let foo = Foo(Box::new(Bar)); let foobar: Foo<Bar> = foo; } </ins>
Code change:
From: src/test/compile- E0516 needs a span_label, updating it from: To:

Related discussion:
text: impl<'a> CheckAttrVisitor<'a> { fn check_inline(&self, attr: &ast::Attribute, target: Target) { if target != Target::Fn { <del> span_err!(self.sess, attr.span, E0518, "attribute should be applied to function"); </del> <ins> struct_span_err!(self.sess, attr.span, E0518, "attribute should be applied to function") .span_label(attr.span, &format!("requires a function")) .emit(); </ins> } }
Code change:
From: src/test/compile- E0516 needs a span_label, updating it from: To:

Related discussion:
text: let mut conflicting_reprs = 0; for word in words { let name = match word.name() { Some(word) => word, None => continue, }; <del> let message = match &*name { </del> <ins> let (message, label) = match &*name { </ins> "C" => { conflicting_reprs += 1; if target != Target::Struct && target != Target::Union && target != Target::Enum { <del> "attribute should be applied to struct, enum or union" </del> <ins> ("attribute should be applied to struct, enum or union", "a struct, enum or union") </ins> } else { continue }
Code change:
From: src/test/compile- E0516 needs a span_label, updating it from: To:

Related discussion:
text: // can be used to modify another repr hint if target != Target::Struct && target != Target::Union { <del> "attribute should be applied to struct or union" </del> <ins> ("attribute should be applied to struct or union", "a struct or union") </ins> } else { continue }
Code change:
From: src/test/compile- E0516 needs a span_label, updating it from: To:

Related discussion:
text: "isize" | "usize" => { conflicting_reprs += 1; if target != Target::Enum { <del> "attribute should be applied to enum" </del> <ins> ("attribute should be applied to enum", "an enum") </ins> } else { continue } } _ => continue, }; <del> span_err!(self.sess, attr.span, E0517, "{}", message); </del> <ins> struct_span_err!(self.sess, attr.span, E0517, "{}", message) .span_label(attr.span, &format!("requires {}", label)) .emit(); </ins> } if conflicting_reprs > 1 { span_warn!(self.sess, attr.span, E0566,
Code change:
From: src/test/compile- E0516 needs a span_label, updating it from: To:

Related discussion:
text: } } hir::TyTypeof(ref _e) => { <del> span_err!(tcx.sess, ast_ty.span, E0516, "`typeof` is a reserved keyword but unimplemented"); </del> <ins> struct_span_err!(tcx.sess, ast_ty.span, E0516, "`typeof` is a reserved keyword but unimplemented") .span_label(ast_ty.span, &format!("reserved keyword")) .emit(); </ins> tcx.types.err } hir::TyInfer => {
Code change:
From: src/test/compile- E0516 needs a span_label, updating it from: To:

Related discussion:
text: // except according to those terms. #[repr(C)] //~ ERROR E0517 <ins> //~| requires a struct, enum or union </ins> type Foo = u8; #[repr(packed)] //~ ERROR E0517 <ins> //~| requires a struct </ins> enum Foo2 {Bar, Baz} #[repr(u8)] //~ ERROR E0517 <ins> //~| requires an enum </ins> struct Foo3 {bar: bool, baz: bool} #[repr(C)] //~ ERROR E0517 <ins> //~| requires a struct, enum or union </ins> impl Foo3 { }
Code change:
From: src/test/compile- E0516 needs a span_label, updating it from: To:

Related discussion:
text: // except according to those terms. #[inline(always)] //~ ERROR E0518 <ins> //~| requires a function </ins> struct Foo; #[inline(never)] //~ ERROR E0518 <ins> //~| requires a function </ins> impl Foo { }
Code change:
From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.

Related discussion:
text: impl<'a> CheckAttrVisitor<'a> { fn check_inline(&self, attr: &ast::Attribute, target: Target) { if target != Target::Fn { <del> span_err!(self.sess, attr.span, E0518, "attribute should be applied to function"); </del> <ins> struct_span_err!(self.sess, attr.span, E0518, "attribute should be applied to function") .span_label(attr.span, &format!("requires a function")) .emit(); </ins> } }
Code change:
From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.

Related discussion:
text: let mut conflicting_reprs = 0; for word in words { let name = match word.name() { Some(word) => word, None => continue, }; <del> let message = match &*name { </del> <ins> let (message, label) = match &*name { </ins> "C" => { conflicting_reprs += 1; if target != Target::Struct && target != Target::Union && target != Target::Enum { <del> "attribute should be applied to struct, enum or union" </del> <ins> ("attribute should be applied to struct, enum or union", "a struct, enum or union") </ins> } else { continue }
Code change:
From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.

Related discussion:
text: // can be used to modify another repr hint if target != Target::Struct && target != Target::Union { <del> "attribute should be applied to struct or union" </del> <ins> ("attribute should be applied to struct or union", "a struct or union") </ins> } else { continue }
Code change:
From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.

Related discussion:
text: "simd" => { conflicting_reprs += 1; if target != Target::Struct { <del> "attribute should be applied to struct" </del> <ins> ("attribute should be applied to struct", "a struct") </ins> } else { continue }
Code change:
From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.

Related discussion:
text: "isize" | "usize" => { conflicting_reprs += 1; if target != Target::Enum { <del> "attribute should be applied to enum" </del> <ins> ("attribute should be applied to enum", "an enum") </ins> } else { continue } } _ => continue, }; <del> span_err!(self.sess, attr.span, E0517, "{}", message); </del> <ins> struct_span_err!(self.sess, attr.span, E0517, "{}", message) .span_label(attr.span, &format!("requires {}", label)) .emit(); </ins> } if conflicting_reprs > 1 { span_warn!(self.sess, attr.span, E0566,
Code change:
From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.

Related discussion:
text: } } hir::TyTypeof(ref _e) => { <del> span_err!(tcx.sess, ast_ty.span, E0516, "`typeof` is a reserved keyword but unimplemented"); </del> <ins> struct_span_err!(tcx.sess, ast_ty.span, E0516, "`typeof` is a reserved keyword but unimplemented") .span_label(ast_ty.span, &format!("reserved keyword")) .emit(); </ins> tcx.types.err } hir::TyInfer => {
Code change:
From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.

Related discussion:
text: // except according to those terms. #[repr(C)] //~ ERROR E0517 <ins> //~| requires a struct, enum or union </ins> type Foo = u8; #[repr(packed)] //~ ERROR E0517 <ins> //~| requires a struct </ins> enum Foo2 {Bar, Baz} #[repr(u8)] //~ ERROR E0517 <ins> //~| requires an enum </ins> struct Foo3 {bar: bool, baz: bool} #[repr(C)] //~ ERROR E0517 <ins> //~| requires a struct, enum or union </ins> impl Foo3 { }
Code change:
From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.

Related discussion:
text: // except according to those terms. #[inline(always)] //~ ERROR E0518 <ins> //~| requires a function </ins> struct Foo; #[inline(never)] //~ ERROR E0518 <ins> //~| requires a function </ins> impl Foo { }
Code change:
I get an ICE on an older project, when running cargo doc - when documenting glium v0.13.5 specifically - with the current nightly build. The issue seems to be the line in of that glium version The glium crate is linked in the backend::glutin_backend module. The compiler warns about PR , but at the moment it compiles fine, only generating docs doesn't work. A minimal example, that generates the same behaviour, when documenting, is: : Backtrace for minimal example:
Introduced between and ()
cc looks like this points to , any ideas here?
Hmm, that's odd -- I'll investigate.
Fixed in .

Related discussion:
text: // If the resolution doesn't depend on glob definability, check privacy and return. if let Some(result) = self.try_result(&resolution, ns) { return result.and_then(|binding| { <del> if self.is_accessible(binding.vis) && !is_disallowed_private_import(binding) { </del> <ins> if self.is_accessible(binding.vis) && !is_disallowed_private_import(binding) || binding.is_extern_crate() { // c.f. issue #37020 </ins> Success(binding) } else { Failed(None)
Code change:
I get an ICE on an older project, when running cargo doc - when documenting glium v0.13.5 specifically - with the current nightly build. The issue seems to be the line in of that glium version The glium crate is linked in the backend::glutin_backend module. The compiler warns about PR , but at the moment it compiles fine, only generating docs doesn't work. A minimal example, that generates the same behaviour, when documenting, is: : Backtrace for minimal example:
Introduced between and ()
cc looks like this points to , any ideas here?
Hmm, that's odd -- I'll investigate.
Fixed in .

Related discussion:
text: <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. #![allow(private_in_public)] mod foo { pub mod bar { extern crate core; } } mod baz { pub use foo::bar::core; } fn main() { baz::core::cell::Cell::new(0u32); } </ins>
Code change:
When I configured with and ran , my install ended up in .
Seems to be because of which was apparently for . If the cannot be removed, then converting to absolute path before installing might work.
I think this is still an issue with rustbuild, but should be somewhat easy to fix.. I think we just want to call canonicalize on the paths here: Does that sound correct to you? If so, this is E-easy and E-mentor (by me).
I believe so!
I can take a crack at this one if nobody else has started on it yet.
Go ahead! Let us know if there's anything we can do to help you.
Just an update - still working on this, just got buried in a move. Will try to get it knocked out this week.
are there any unit-like tests that run against the install scripts? or do they just get tested as part of the full build?
No unfortunately I don't think we test this step at all on CI :(
canonicalizing the prefix breaks when prefix is a symbolic link. e.g., /usr/local -/some/other/location Now if you want to install to <destdir/usr/local, everything goes to <destdir/some/other/location instead with many files including references to /some/other/location internally. Now when I want to change the /usr/local sym link (in my case, the underlying location is a shared NFS mount point) to point to /a/different/location that contains the rust install, all the references to /some/other/location are wrong - leaving the best remaining option to recompile rust (and that's painful) on each occurrence where the underlying path pointed to by <prefixis different. There must be a better way to solve the relative path issue than by manually converting all sym links to their resolved paths. I can't think of any packages right now where defining prefix to a sym link breaks in this way.

Related discussion:
text: let bindir_default = PathBuf::from("bin"); let libdir_default = PathBuf::from("lib"); let mandir_default = datadir_default.join("man"); <del> let prefix = build.config.prefix.as_ref().unwrap_or(&prefix_default); </del> <ins> let prefix = build.config.prefix.as_ref().map_or(prefix_default, |p| { fs::canonicalize(p).expect(&format!("could not canonicalize {}", p.display())) }); </ins> let sysconfdir = build.config.sysconfdir.as_ref().unwrap_or(&sysconfdir_default); let datadir = build.config.datadir.as_ref().unwrap_or(&datadir_default); let docdir = build.config.docdir.as_ref().unwrap_or(&docdir_default);
Code change:
Here's an example:
I'm going to vote for this to be a 0.4 blocker since it's breaking cargos like . Cargo is violating an assumption in the parser that there's only one parser made per task. calls , which caches an interner in TLS on the first call, or assert if an interner has already been created. Unfortunately cargo creates a new parser session per crate, which triggers the assertion. I think this won't be too hard to work around. We could just get rid of the assertion, and share the interner across all parsers in the same thread. I'll prep a patch for this. I'm not sure if this will violate other assumptions in the compiler though. The other option would be to hack up cargo to run in a new thread. This will require some jury rigging, but it'll keep us from having to tweak the parser this close to release.
-- is this bug fixed now that your interner cache fix is merged?
yep, closing.

Related discussion:
text: ) fn mk_ident_interner() -> @ident_interner { <del> /* the indices here must correspond to the numbers in special_idents */ let init_vec = ~[@~"_", @~"anon", @~"drop", @~"", @~"unary", @~"!", @~"[]", @~"unary-", @~"__extensions__", @~"self", @~"item", @~"block", @~"stmt", @~"pat", @~"expr", @~"ty", @~"ident", @~"path", @~"tt", @~"matchers", @~"str", @~"TyVisitor", @~"arg", @~"descrim", @~"__rust_abi", @~"__rust_stack_shim", @~"TyDesc", @~"dtor", @~"main", @~"<opaque>", @~"blk", @~"static", @~"intrinsic", @~"__foreign_mod__"]; let rv = @ident_interner { interner: interner::mk_prefill::<@~str>(init_vec) }; /* having multiple interners will just confuse the serializer */ </del> unsafe { <del> assert task::local_data::local_data_get(interner_key!()).is_none() }; unsafe { task::local_data::local_data_set(interner_key!(), @rv) }; rv </del> <ins> match task::local_data::local_data_get(interner_key!()) { Some(interner) => *interner, None => { // the indices here must correspond to the numbers in // special_idents. let init_vec = ~[ @~"_", @~"anon", @~"drop", @~"", @~"unary", @~"!", @~"[]", @~"unary-", @~"__extensions__", @~"self", @~"item", @~"block", @~"stmt", @~"pat", @~"expr", @~"ty", @~"ident", @~"path", @~"tt", @~"matchers", @~"str", @~"TyVisitor", @~"arg", @~"descrim", @~"__rust_abi", @~"__rust_stack_shim", @~"TyDesc", @~"dtor", @~"main", @~"<opaque>", @~"blk", @~"static", @~"intrinsic", @~"__foreign_mod__" ]; let rv = @ident_interner { interner: interner::mk_prefill(init_vec) }; task::local_data::local_data_set(interner_key!(), @rv); rv } } } </ins> } /* for when we don't care about the contents; doesn't interact with TLD or
Code change:
Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.

Related discussion:
text: pub llvm_version_check: bool, pub llvm_static_stdcpp: bool, pub llvm_link_shared: bool, <ins> pub llvm_targets: Option<String>, </ins> // rust codegen options pub rust_optimize: bool,
Code change:
Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.

Related discussion:
text: release_debuginfo: Option<bool>, version_check: Option<bool>, static_libstdcpp: Option<bool>, <ins> targets: Option<String>, </ins> } #[derive(RustcDecodable)]
Code change:
Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.

Related discussion:
text: set(&mut config.llvm_release_debuginfo, llvm.release_debuginfo); set(&mut config.llvm_version_check, llvm.version_check); set(&mut config.llvm_static_stdcpp, llvm.static_libstdcpp); <ins> config.llvm_targets = llvm.targets.clone(); </ins> } if let Some(ref rust) = toml.rust {
Code change:
Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.

Related discussion:
text: # example. #ninja = false <ins> # LLVM targets to build support for. # Note: this is NOT related to Rust compilation targets. However, as Rust is # dependent on LLVM for code generation, turning targets off here WILL lead to # the resulting rustc being unable to compile for the disabled architectures. # Also worth pointing out is that, in case support for new targets are added to # LLVM, enabling them here doesn't mean Rust is automatically gaining said # support. You'll need to write a target specification at least, and most # likely, teach rustc about the C ABI of the target. Get in touch with the # Rust team and file an issue if you need assistance in porting! #targets = "X86;ARM;AArch64;Mips;PowerPC;SystemZ;JSBackend;MSP430;Sparc" </ins> # ============================================================================= # General build configuration options # =============================================================================