jiebi/CodeConvo huggingface dataset:
Change:
Version: rustc 1.13.0-nightly ( 2016-09-27) thinks you may have some insight into this...
This was probably caused by -- I'll investigate.
Fixed in -- thanks for the report!

Discussion:
let mut def_collector = DefCollector::new(&mut self.definitions); def_collector.visit_macro_invoc = Some(visit_macro_invoc); <del> def_collector.with_parent(def_index, |def_collector| if !const_integer { </del> <ins> def_collector.with_parent(def_index, |def_collector| { if const_integer { if let Expansion::Expr(ref expr) = *expansion { def_collector.visit_ast_const_integer(expr); } } </ins> expansion.visit_with(def_collector) <del> } else if let Expansion::Expr(ref expr) = *expansion { def_collector.visit_ast_const_integer(expr); </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. macro_rules! m { () => { 1 } } macro_rules! n { () => { 1 + m!() } } fn main() { let _: [u32; n!()] = [0, 0]; } </ins>
Change:
This crate compiles fine with beta (0.13.0-beta.1) and stable (0.12.0).
Last nightly that worked: nightly-2016-09-27
Could be a duplicate of , cc
I have a fresh build from master, fixed this as well.
Yay!

Discussion:
let mut def_collector = DefCollector::new(&mut self.definitions); def_collector.visit_macro_invoc = Some(visit_macro_invoc); <del> def_collector.with_parent(def_index, |def_collector| if !const_integer { </del> <ins> def_collector.with_parent(def_index, |def_collector| { if const_integer { if let Expansion::Expr(ref expr) = *expansion { def_collector.visit_ast_const_integer(expr); } } </ins> expansion.visit_with(def_collector) <del> } else if let Expansion::Expr(ref expr) = *expansion { def_collector.visit_ast_const_integer(expr); </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. macro_rules! m { () => { 1 } } macro_rules! n { () => { 1 + m!() } } fn main() { let _: [u32; n!()] = [0, 0]; } </ins>
Change:
The second error in this snippet is "nonsense" because it says the type parameter is not constrained, while the real error was already reported — the actual type could not be imported. Found in: rustc 1.13.0-nightly ( 2016-09-26)
.

Discussion:
} /// Returns the set of parameters constrained by the impl header. <del> pub fn parameters_for_impl<'tcx>(impl_self_ty: Ty<'tcx>, impl_trait_ref: Option<ty::TraitRef<'tcx>>) -> FxHashSet<Parameter> { </del> <ins> pub fn parameters_for_impl<'tcx>( impl_self_ty: Ty<'tcx>, impl_trait_ref: Option<ty::TraitRef<'tcx>>, ) -> FxHashSet<Parameter> { </ins> let vec = match impl_trait_ref { Some(tr) => parameters_for(&tr, false), None => parameters_for(&impl_self_ty, false),

/// uniquely determined by `t` (see RFC 447). If it is true, return the list /// of parameters whose values are needed in order to constrain `ty` - these /// differ, with the latter being a superset, in the presence of projections. <del> pub fn parameters_for<'tcx, T>(t: &T, include_nonconstraining: bool) -> Vec<Parameter> where T: TypeFoldable<'tcx> { </del> <ins> pub fn parameters_for<'tcx>( t: &impl TypeFoldable<'tcx>, include_nonconstraining: bool, ) -> Vec<Parameter> { </ins> let mut collector = ParameterCollector { parameters: vec![], include_nonconstraining,

use rustc::hir; use rustc::hir::itemlikevisit::ItemLikeVisitor; use rustc::hir::def_id::DefId; <del> use rustc::ty::{self, TyCtxt}; </del> <ins> use rustc::ty::{self, TyCtxt, TypeFoldable}; </ins> use rustc::ty::query::Providers; use rustc::util::nodemap::{FxHashMap, FxHashSet}; use std::collections::hash_map::Entry::{Occupied, Vacant};

) { // Every lifetime used in an associated type must be constrained. let impl_self_ty = tcx.type_of(impl_def_id); <ins> if impl_self_ty.references_error() { // Don't complain about unconstrained type params when self ty isn't known due to errors. // (#36836) tcx.sess.delay_span_bug( tcx.def_span(impl_def_id), "potentially unconstrained type parameters weren't evaluated", ); return; } </ins> let impl_generics = tcx.generics_of(impl_def_id); let impl_predicates = tcx.predicates_of(impl_def_id); let impl_trait_ref = tcx.impl_trait_ref(impl_def_id);

<ins> // Previously, in addition to the real cause of the problem as seen below, // the compiler would tell the user: // // ``` // error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or // predicates // ``` // // With this test, we check that only the relevant error is emitted. trait Foo {} impl<T> Foo for Bar<T> {} //~ ERROR cannot find type `Bar` in this scope fn main() {} </ins>

<ins> error[E0412]: cannot find type `Bar` in this scope --> $DIR/issue-36836.rs:13:17 | LL | impl<T> Foo for Bar<T> {} |                 ^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0412`. </ins>
Change:
In 1.12, figures out which libraries it needs for external LLVM using which breaks if you have LLVM with and (which is needed for clang 3.9 these days), since then there is a dynamic and lots of , but the code sees the and decides it has to link statically, which fails. The code should decide whether to link static or dynamic first, and then call resp , to get the correct library name.
Thanks for the report! Sounds like it should be a relatively easy bug to tackle as well!
In Void, we work around it by just adding , I guess for a general fix you need some policy how to link it.
Oh we basically always want to link LLVM statically, so we can probably just always pass it.
We emphatically don't want that in distro builds. Would you accept a patch to make this conditional?
certainly!

Discussion:
// of llvm-config, not the target that we're attempting to link. let mut cmd = Command::new(&llvm_config); cmd.arg("--libs"); <ins> // Force static linking with "--link-static" if available. let mut version_cmd = Command::new(&llvm_config); version_cmd.arg("--version"); let version_output = output(&mut version_cmd); let mut parts = version_output.split('.'); if let (Some(major), Some(minor)) = (parts.next().and_then(|s| s.parse::<u32>().ok()), parts.next().and_then(|s| s.parse::<u32>().ok())) { if major > 3 || (major == 3 && minor >= 8) { cmd.arg("--link-static"); } } </ins> if !is_crossed { cmd.arg("--system-libs"); }
Change:
The currently say about the macro: But in fact, is defined as calling the method on its argument, as per .

Discussion:
//! This and `writeln` are two macros which are used to emit the format string //! to a specified stream. This is used to prevent intermediate allocations of //! format strings and instead directly write the output. Under the hood, this <del> //! function is actually invoking the `write` function defined in this module. //! Example usage is: </del> <ins> //! function is actually invoking the `write_fmt` function defined on the //! `std::io::Write` trait. Example usage is: </ins> //! //! ``` //! # #![allow(unused_must_use)]
Change:
I was just investigating a that Fedora's rust binaries for armv7hl use NEON, but they should not per , supposedly fixed in . (Fedora's build is 1.11, but I applied that patch.) I can see the exact same issue in the latest official , whose version file says . In particular, they flagged that as a problem. I'm no ARM expert, but from it appears the registers are NEON-only. I believe those instructions using are also a problem, because with VFP3-D16 we should only have to .
Hm looks like it's definitely still there:
( TIL of ! :open_mouth: )
Just to confirm: No . This doesn't explicitly mention vs. though. I ran on all binaries in . I see no mention of NEON registers. I see uses of -, but no higher, so I think is OK too. I'll know better if someone with a limited armv7 actually tries to run this, but LGTM!
Thanks for the confirmation

Discussion:
options: TargetOptions { // Info about features at https://wiki.debian.org/ArmHardFloatPort <del> features: "+v7,+vfp3,+d16,+thumb2".to_string(), </del> <ins> features: "+v7,+vfp3,+d16,+thumb2,-neon".to_string(), </ins> cpu: "generic".to_string(), max_atomic_width: 64, .. base
Change:
In rustllvm, uses an external symbol (DebugFlag), which is conditionally exported by LLVM in llvm/Support/Debug.h in between an #ifndef NDEBUG block. Unfortunately the Debian packaged llvm is currently configured to define it: Thus rust fails to build. Would adding a #ifndef inside LLVMSetDebug() suffice?
I think an #ifndef inside LLVMSetDebug is fine.

Discussion:
} extern "C" void LLVMSetDebug(int Enabled) { <ins> #ifndef NDEBUG </ins> DebugFlag = Enabled; <ins> #endif </ins> }
Change:
A shows regressions related to () () I'm opening an issue to ensure that we're tracking these regressions and they're either expected (so we can close), this is a dupe (so we can close), or we can fix (and then close!) cc
Fixed in .

Discussion:
// 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)

<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>
Change:
A shows regressions related to () () I'm opening an issue to ensure that we're tracking these regressions and they're either expected (so we can close), this is a dupe (so we can close), or we can fix (and then close!) cc
Also fixed by .

Discussion:
// 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)

<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>
Change:
I was trying an pattern match for a nullary constructor like this: but the compiler choked on the pattern match in an unexpected way. The fact that it's qualified does not seem to matter. See minimal repro below. I tried this code: I expected to see this happen: An plain, ordinary, not-scary type error. Instead, this happened: : Backtrace:
Works fine on 1.11.
Affects beta as well. Requires the type on the lhs to come from an extern crate. This is fixed on ( still fails, ) I suspect this was fixed by (although I may be wrong).
Originally introduced between and () The most likely cause is , I think.
cc
This happens when gets struct constructor as an argument (as opposed to of the struct itself) + it's the first time this struct is decoded. doesn't fix this issue, only masks it, it still can be reproduced with tuple struct patterns. How to fix this: add something like this at the beginning of : I have no idea how and can be implemented, need to investigate how new metadata works.
Fix for beta is in
Nice job

Discussion:
let enum_did = self.parent_def_id(did).unwrap(); self.lookup_adt_def(enum_did).variant_with_id(did) } <del> Def::Struct(did) | Def::StructCtor(did, ..) | Def::Union(did) => { </del> <ins> Def::Struct(did) | Def::Union(did) => { self.lookup_adt_def(did).struct_variant() } Def::StructCtor(ctor_did, ..) => { let did = self.parent_def_id(ctor_did).expect("struct ctor has no parent"); </ins> self.lookup_adt_def(did).struct_variant() } _ => bug!("expect_variant_def used with unexpected def {:?}", def)

<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. // aux-build:empty-struct.rs extern crate empty_struct; fn main() { let empty_struct::XEmpty2 = (); //~ ERROR mismatched types let empty_struct::XEmpty6(..) = (); //~ ERROR mismatched types } </ins>
Change:
With an old-style derive plugin, triggers a warning about an empty trait list. For example in Servo:

Discussion:
}); if new_attributes.len() > 0 { item = item.map(|mut i| { <del> let list = cx.meta_list(mitem.span, intern_and_get_ident("derive"), traits); </del> i.attrs.extend(new_attributes); <del> i.attrs.push(cx.attribute(mitem.span, list)); </del> <ins> if traits.len() > 0 { let list = cx.meta_list(mitem.span, intern_and_get_ident("derive"), traits); i.attrs.push(cx.attribute(mitem.span, list)); } </ins> i }); return vec![Annotatable::Item(item)]
Change:
Given the code: rustc reports: Ideally error messages would use correct plurals, so 'expected 1 type argument, found 2' in this case.
I guess I should start remembering to use "fixes" or "resolves" language so that GitHub can .
Let me do the honours :)

Discussion:
} else { "expected" }; <ins> let arguments_plural = if required == 1 { "" } else { "s" }; </ins> struct_span_err!(tcx.sess, span, E0243, "wrong number of type arguments") .span_label( span, <del> &format!("{} {} type arguments, found {}", expected, required, supplied) </del> <ins> &format!("{} {} type argument{}, found {}", expected, required, arguments_plural, supplied) </ins> ) .emit(); } else if supplied > accepted {

} else { format!("expected {}", accepted) }; <ins> let arguments_plural = if accepted == 1 { "" } else { "s" }; </ins> struct_span_err!(tcx.sess, span, E0244, "wrong number of type arguments") .span_label( span, <del> &format!("{} type arguments, found {}", expected, supplied) </del> <ins> &format!("{} type argument{}, found {}", expected, arguments_plural, supplied) </ins> ) .emit(); }

struct Foo<T> { x: T } struct Bar { x: Foo } //~^ ERROR E0243 <del> //~| NOTE expected 1 type arguments, found 0 </del> <ins> //~| NOTE expected 1 type argument, found 0 </ins> fn main() { }

fn main() { let _: Vec; //~^ ERROR E0243 <del> //~| NOTE expected at least 1 type arguments, found 0 </del> <ins> //~| NOTE expected at least 1 type argument, found 0 </ins> }

fn fn1(0: Box) {} //~^ ERROR E0243 <del> //~| NOTE expected 1 type arguments, found 0 </del> <ins> //~| NOTE expected 1 type argument, found 0 </ins> fn main() {}

pub fn main() { let c: Foo<_, _> = Foo { r: &5 }; //~^ ERROR E0244 <del> //~| NOTE expected 1 type arguments, found 2 </del> <ins> //~| NOTE expected 1 type argument, found 2 </ins> }

pub fn main() { let c: Foo<_, usize> = Foo { r: &5 }; //~^ ERROR E0244 <del> //~| NOTE expected 1 type arguments, found 2 </del> <ins> //~| NOTE expected 1 type argument, found 2 </ins> }
Change:
The documentation for describes implementation details of how it internally rearranges the data structure which make it unclear on what the actual behavior of the method call is: "Inserts an element at index within the VecDeque. Whichever end is closer to the insertion point will be moved to make room, and all the affected elements will be moved to new positions. Element at index 0 is the front of the queue." The doc should clearly state that the element will be inserted at this index and the existing element at this index will be pushed towards the back of the deque. The current doc makes it sound like which direction the existing element will be pushed towards could be different depending on that implementation detail.
Opened a PR for this:

Discussion:
self.pop_front() } <del> /// Inserts an element at `index` within the `VecDeque`. Whichever /// end is closer to the insertion point will be moved to make room, /// and all the affected elements will be moved to new positions. </del> <ins> /// Inserts an element at `index` within the `VecDeque`, shifting all elements with indices /// greater than or equal to `index` towards the back. </ins> /// /// Element at index 0 is the front of the queue. ///

/// Panics if `index` is greater than `VecDeque`'s length /// /// # Examples <ins> /// </ins> /// ``` /// use std::collections::VecDeque; /// <del> /// let mut buf = VecDeque::new(); /// buf.push_back(10); /// buf.push_back(12); /// buf.insert(1, 11); /// assert_eq!(Some(&11), buf.get(1)); </del> <ins> /// let mut vec_deque = VecDeque::new(); /// vec_deque.push_back('a'); /// vec_deque.push_back('b'); /// vec_deque.push_back('c'); /// /// vec_deque.insert(1, 'd'); /// /// let vec = vec_deque.into_iter().collect::<Vec<_>>(); /// assert_eq!(vec, ['a', 'd', 'b', 'c']); </ins> /// ``` #[stable(feature = "deque_extras_15", since = "1.5.0")] pub fn insert(&mut self, index: usize, value: T) {
Change:
STR: run with on a program with a name resolution error. Result: cc (bug manifests in the RLS)
I can take this. I already dug into some time ago, I encountered the same bug when I was trying to write a refactoring tool. To fix the issue, I have to remove all the around there, right ?
great, thanks for digging in. There's likely to be some s that don't need to be there, but it won't be quite as simple as just ripping them out. There will be some error condition that needs to be dealt with.

Discussion:
let path_data = match path_data { Some(pd) => pd, None => { <del> span_bug!(path.span, "Unexpected def kind while looking up path in `{}`", self.span.snippet(path.span)) </del> <ins> return; </ins> } };
Change:
Running this code in either release or debug mode will yield a segfault: It looks like this also runs successfully on stable, just failing on beta/nightly cc
This looks very similar to .
This was introduced between and (). I'm no llvm ir expert, however I believe the following excerpts show the problem: The definition in the case is missing the padding between the slice elements. Edit: Note that this ir was obtained from a slightly modified code, the definition was changed to And the struct changed to Also, some manually edited impl's revealed that (in the modified case) the first is correctly handled as a , however the second is (which then leads to the segfault when trying read the string literal from an invalid address.
The following code reproduces the problem without the segfault: The expected hexdump would be (from the working nightly): The actual hexdump is:
Waiting on backport.
Reopened because this still affects beta.
Backported in , so closing.

Discussion:
offset += machine::llsize_of_alloc(ccx, val_ty(val)); } <del> if offset < st.min_size.bytes() { cfields.push(padding(ccx, st.min_size.bytes() - offset)); </del> <ins> if offset < st.stride().bytes() { cfields.push(padding(ccx, st.stride().bytes() - offset)); </ins> } cfields

<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. #[derive(Debug, PartialEq)] enum Bar { A(i64), B(i32), C, } #[derive(Debug, PartialEq)] struct Foo(Bar, u8); static FOO: [Foo; 2] = [Foo(Bar::C, 0), Foo(Bar::C, 0xFF)]; fn main() { assert_eq!(&FOO[1],  &Foo(Bar::C, 0xFF)); } </ins>
Change:
Failure happens in the crate: This probably has to do with how we're calling the "custom resume" function, unsure what's going on.
Duplicate of
Indeed!

Discussion:
nightly ) msg "overriding settings for $CFG_RELEASE_CHANNEL" CFG_ENABLE_LLVM_ASSERTIONS=1 <del> CFG_ENABLE_DEBUGINFO_LINES=1 </del> <ins> # FIXME(#37364) shouldn't have to disable this on windows-gnu case "$CFG_BUILD" in *-pc-windows-gnu) ;; *) CFG_ENABLE_DEBUGINFO_LINES=1 ;; esac </ins> ;; beta | stable) msg "overriding settings for $CFG_RELEASE_CHANNEL" <del> CFG_ENABLE_DEBUGINFO_LINES=1 </del> <ins> case "$CFG_BUILD" in *-pc-windows-gnu) ;; *) CFG_ENABLE_DEBUGINFO_LINES=1 ;; esac </ins> ;; dev) ;;

CFG_RUSTC_FLAGS += -g else ifdef CFG_ENABLE_DEBUGINFO_LINES $(info cfg: enabling line number debuginfo (CFG_ENABLE_DEBUGINFO_LINES)) <del> CFG_RUSTC_FLAGS += -C debuginfo=1 </del> <ins> CFG_RUSTC_FLAGS += -Cdebuginfo=1 </ins> endif ifdef SAVE_TEMPS

# is a separate choice from whether to pass `-g` when building the # compiler and standard library themselves. CTEST_RUSTC_FLAGS := $$(subst -g,,$$(CTEST_RUSTC_FLAGS)) <ins> CTEST_RUSTC_FLAGS := $$(subst -Cdebuginfo=1,,$$(CTEST_RUSTC_FLAGS)) </ins> ifdef CFG_ENABLE_DEBUGINFO_TESTS CTEST_RUSTC_FLAGS += -g endif
Change:
Unexpected non-scalars in register inputs of can ICE the compiler. To reproduce: This mistake goes uncaught until it reaches where it s. I would expect it to have been caught earlier, during argument validation. I've found a similar case which dumps core, which will be the subject of a separate bug. : rustc 1.14.0-nightly ( 2016-10-26) binary: rustc commit-hash: commit-date: 2016-10-26 host: x8664-unknown-linux-gnu release: 1.14.0-nightly LLVM version: 3.9 Backtrace:
Got an updated backtrace:
Ran into this with which I would sort of hope would just work. Backtrace is identical (at least as far as a compiler without debugging information outputs).
Still reproducible with .
No longer reproduces:

Discussion:
<ins> #![crate_type = "lib"] pub struct SomeType { pub some_member: usize, } pub static SOME_VALUE: SomeType = SomeType { some_member: 1, }; </ins>

<ins> #![crate_type = "lib"] pub fn foo() -> Vec<String> { std::env::args() .skip(1) .collect() } </ins>

<ins> // aux-build:issue-29265.rs // check-pass extern crate issue_29265 as lib; static _UNUSED: &'static lib::SomeType = &lib::SOME_VALUE; fn main() { vec![0u8; lib::SOME_VALUE.some_member]; } </ins>

<ins> // ignore-emscripten no asm! support #![feature(asm)] fn main() { unsafe { asm!("" :: "r"("")); //~^ ERROR: invalid value for constraint in inline assembly } } </ins>

<ins> error[E0669]: invalid value for constraint in inline assembly --> $DIR/issue-37433.rs:7:24 | LL |         asm!("" :: "r"("")); |                        ^^ error: aborting due to previous error </ins>

<ins> // aux-build:issue-49544.rs // check-pass extern crate issue_49544; use issue_49544::foo; fn main() { let _ = foo(); } </ins>