jiebi/CodeConvo huggingface dataset:
Change:
It's a minor thing but currently "' not needed here" is an error and does not actually mean "needed" but "allowed because implied". Maybe the message would be less confusing for a user if it actually says " not permitted here because it's implied".
Fixed in .

Discussion:
E0449, "unnecessary visibility qualifier"); if vis.node == VisibilityKind::Public { <del> err.span_label(vis.span, "`pub` not needed here"); </del> <ins> err.span_label(vis.span, "`pub` not permitted here because it's implied"); </ins> } if let Some(note) = note { err.note(note);

--> $DIR/E0449.rs:17:1 | LL | pub impl Bar {} //~ ERROR E0449 <del> | ^^^ `pub` not needed here </del> <ins> | ^^^ `pub` not permitted here because it's implied </ins> | = note: place qualifiers on individual impl items instead

--> $DIR/E0449.rs:19:1 | LL | pub impl Foo for Bar { //~ ERROR E0449 <del> | ^^^ `pub` not needed here </del> <ins> | ^^^ `pub` not permitted here because it's implied </ins> error[E0449]: unnecessary visibility qualifier --> $DIR/E0449.rs:20:5 | LL |     pub fn foo() {} //~ ERROR E0449 <del> |     ^^^ `pub` not needed here </del> <ins> |     ^^^ `pub` not permitted here because it's implied </ins> error: aborting due to 3 previous errors
Change:
As far as i see it, "deriving" is documented neither in the tutorial nor in the manual. Example:

Discussion:
* The `test` attribute, for marking functions as unit tests. * The `allow`, `warn`, `forbid`, and `deny` attributes, for controlling lint checks. Lint checks supported by the compiler can be found via `rustc -W help`. <ins> * The `deriving` attribute, for automatically generating implementations of certain traits. </ins> Other attributes may be added or removed during development of the language.

> **Note:** This list is likely to become out of date. We should auto-generate it > from `librustc/middle/lang_items.rs`. <ins> ### Deriving The `deriving` attribute allows certain traits to be automatically implemented for data structures. For example, the following will create an `impl` for the `Eq` and `Clone` traits for `Foo`, the type parameter `T` will be given the `Eq` or `Clone` constraints for the appropriate `impl`: ~~~ #[deriving(Eq, Clone)] struct Foo<T> { a: int, b: T } ~~~ The generated `impl` for `Eq` is equivalent to ~~~ # struct Foo<T> { a: int, b: T } impl<T: Eq> Eq for Foo<T> { fn eq(&self, other: &Foo<T>) -> bool { self.a == other.a && self.b == other.b } fn ne(&self, other: &Foo<T>) -> bool { self.a != other.a || self.b != other.b } } ~~~ Supported traits for `deriving` are: * Comparison traits: `Eq`, `TotalEq`, `Ord`, `TotalOrd`. * Serialization: `Encodable`, `Decodable`. These require `std`. * `Clone`, to perform deep copies. * `IterBytes`, to iterate over the bytes in a data type. * `Rand`, to create a random instance of a data type. * `ToStr`, to convert to a string. For a type with this instance, `obj.to_str()` has the same output as `fmt!("%?", obj)`. </ins> # Statements and expressions Rust is _primarily_ an expression language. This means that most forms of

> ***Note:*** Trait inheritance does not actually work with objects yet <ins> ## Deriving implementations for traits A small number of traits in `core` and `std` can have implementations that can be automatically derived. These instances are specified by placing the `deriving` attribute on a data type declaration. For example, the following will mean that `Circle` has an implementation for `Eq` and can be used with the equality operators, and that a value of type `ABC` can be randomly generated and converted to a string: ~~~ #[deriving(Eq)] struct Circle { radius: float } #[deriving(Rand, ToStr)] enum ABC { A, B, C } ~~~ The full list of derivable traits is `Eq`, `TotalEq`, `Ord`, `TotalOrd`, `Encodable` `Decodable`, `Clone`, `IterBytes`, `Rand` and `ToStr`. </ins> # Modules and crates The Rust namespace is arranged in a hierarchy of modules. Each source
Change:
I was trying to build which pulls in pango 0.1.3 as dependency . While building pango, rustc segfaults  meta: Crash happens in So apparently const eval produces a discriminant that doesn't match any variant's discriminant. more concretely, it happens during a match on which is the only discriminant with as its value.
weird, I am still getting the panic with todays nightly :(
Same backtrace? We do have a regression test for this exact issue
Yeah, backtrace is identical except for the rustc version string in the ICE notes. :/
Fix confirmed, thanks!

Discussion:
ty::TyAdt(adt_def, substs) if adt_def.is_enum() => { match cv.val { ConstVal::Value(val) => { <del> let discr = const_discr( </del> <ins> let discr_val = const_discr( </ins> self.tcx, self.param_env, instance, val, cv.ty <del> ).unwrap(); let variant_index = adt_def .discriminants(self.tcx) .position(|var| var.val == discr) .unwrap(); </del> <ins> ).expect("const_discr failed"); let layout = self .tcx .layout_of(self.param_env.and(cv.ty)) .expect("layout of enum not available"); let variant_index = match layout.variants { ty::layout::Variants::Single { index } => index, ty::layout::Variants::Tagged { ref discr, .. } => { // raw discriminants for enums are isize or bigger during // their computation, but later shrunk to the smallest possible // representation let size = discr.value.size(self.tcx).bits(); let amt = 128 - size; adt_def .discriminants(self.tcx) .position(|var| ((var.val << amt) >> amt) == discr_val) .unwrap_or_else(|| { bug!("discriminant {} not found in {:#?}", discr_val, adt_def .discriminants(self.tcx) .collect::<Vec<_>>(), ); }) } ty::layout::Variants::NicheFilling { .. } => { assert_eq!(discr_val as usize as u128, discr_val); discr_val as usize }, }; </ins> let subpatterns = adt_subpatterns( adt_def.variants[variant_index].fields.len(), Some(variant_index),

const F : C = C::D; assert_eq!(match C::D { F => 1, _ => 2, }, 1); <ins> // test gaps #[derive(PartialEq, Eq)] enum G { H = 3, I = 5 } const K : G = G::I; assert_eq!(match G::I { K => 1, _ => 2, }, 1); </ins> } fn issue_13731() {
Change:
produces without any additional info. If the value is not dereferenced, but instead fed to llvm, we get an ICE in trans: results in Even though it should be reporting a dangling pointer const eval error
Both samples now require The first reports a dereferenced dangling pointer and the second sample no longer triggers an ICE
Thanks for checking up on this! So all we need is a ui test for the first example, because I don't think we have a regression test for that error. The second one definitely has a bunch of tests.

Discussion:
<ins> // issue-49296: Unsafe shenigans in constants can result in missing errors #![feature(const_fn)] #![feature(const_fn_union)] const unsafe fn transmute<T: Copy, U: Copy>(t: T) -> U { union Transmute<T: Copy, U: Copy> { from: T, to: U, } Transmute { from: t }.to } const fn wat(x: u64) -> &'static u64 { unsafe { transmute(&x) } } const X: u64 = *wat(42); //~^ ERROR any use of this value will cause an error fn main() { println!("{}", X); } </ins>

<ins> error: any use of this value will cause an error --> $DIR/issue-49296.rs:18:1 | LL | const X: u64 = *wat(42); | ^^^^^^^^^^^^^^^--------^ |                | |                dangling pointer was dereferenced | = note: #[deny(const_err)] on by default error: aborting due to previous error </ins>
Change:
clauses on associated types don't work yet so should be feature gated, presumably with . cc . Happens on versions = 1.24

Discussion:
} } ast::TraitItemKind::Type(_, ref default) => { <del> // We use two if statements instead of something like match guards so that both // of these errors can be emitted if both cases apply. </del> <ins> // We use three if statements instead of something like match guards so that all // of these errors can be emitted if all cases apply. </ins> if default.is_some() { gate_feature_post!(&self, associated_type_defaults, ti.span, "associated type defaults are unstable");

gate_feature_post!(&self, generic_associated_types, ti.span, "generic associated types are unstable"); } <ins> if !ti.generics.where_clause.predicates.is_empty() { gate_feature_post!(&self, generic_associated_types, ti.span, "where clauses on associated types are unstable"); } </ins> } _ => {} }

//~^ ERROR generic associated types are unstable type Pointer2<T>: Deref<Target = T> where T: Clone, U: Clone; //~^ ERROR generic associated types are unstable <ins> //~| ERROR where clauses on associated types are unstable </ins> } struct Foo;

//~^ ERROR generic associated types are unstable } <ins> trait Bar { type Assoc where Self: Sized; //~^ ERROR where clauses on associated types are unstable } </ins> fn main() {}

| = help: add #![feature(generic_associated_types)] to the crate attributes to enable <ins> error[E0658]: where clauses on associated types are unstable (see issue #44265) --> $DIR/feature-gate-generic_associated_types.rs:16:5 | LL |     type Pointer2<T>: Deref<Target = T> where T: Clone, U: Clone; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: add #![feature(generic_associated_types)] to the crate attributes to enable </ins> error[E0658]: generic associated types are unstable (see issue #44265) <del> --> $DIR/feature-gate-generic_associated_types.rs:22:5 </del> <ins> --> $DIR/feature-gate-generic_associated_types.rs:23:5 </ins> | LL |     type Pointer<usize> = Box<usize>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

= help: add #![feature(generic_associated_types)] to the crate attributes to enable error[E0658]: generic associated types are unstable (see issue #44265) <del> --> $DIR/feature-gate-generic_associated_types.rs:24:5 </del> <ins> --> $DIR/feature-gate-generic_associated_types.rs:25:5 </ins> | LL |     type Pointer2<u32> = Box<u32>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: add #![feature(generic_associated_types)] to the crate attributes to enable <del> error: aborting due to 4 previous errors </del> <ins> error[E0658]: where clauses on associated types are unstable (see issue #44265) --> $DIR/feature-gate-generic_associated_types.rs:30:5 | LL |     type Assoc where Self: Sized; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: add #![feature(generic_associated_types)] to the crate attributes to enable error: aborting due to 6 previous errors </ins> For more information about this error, try `rustc --explain E0658`.
Change:
I guess this should be erroring with or E0666 (nested impl trait is not allowed).
Continues crashing in 1.26 stable.
This does not crash:
Particularly unfortunate because of and . <strikeWhat is going on here: There is a syntactical check to forbid nested impl Trait, but the default sneaks past that check, so we probably have to check for that substitution after lowering from HIR in type collection. Though it can also be done in the syntax check with some contortion.</strikeI was thinking that this shouldn't be allowed because it's like nested impl Trait, but is not at all like because the latter allows the inner type to be different from the outer one, while the former doesn't. So it might just be a case of fixing the overflow itself . I can take this myself but someone looking for mentorship or who is just faster is welcome.

Discussion:
use rustc::ty::{self, TyCtxt, Ty, TypeFoldable}; use rustc::ty::fold::TypeVisitor; use rustc::ty::maps::Providers; <ins> use rustc::ty::subst::UnpackedKind; </ins> use rustc::util::nodemap::NodeSet; use syntax::ast::{self, CRATE_NODE_ID, Ident}; use syntax::symbol::keywords;

use std::cmp; use std::mem::replace; <ins> use rustc_data_structures::fx::FxHashSet; </ins> use rustc_data_structures::sync::Lrc; mod diagnostics;

in_body: bool, span: Span, empty_tables: &'a ty::TypeckTables<'tcx>, <ins> visited_anon_tys: FxHashSet<DefId> </ins> } impl<'a, 'tcx> TypePrivacyVisitor<'a, 'tcx> {

self.tcx.sess.span_err(self.span, &msg); return true; } <del> // `Self` here is the same `TyAnon`, so skip it to avoid infinite recursion for subst in trait_ref.substs.iter().skip(1) { </del> <ins> for subst in trait_ref.substs.iter() { // Skip repeated `TyAnon`s to avoid infinite recursion. if let UnpackedKind::Type(ty) = subst.unpack() { if let ty::TyAnon(def_id, ..) = ty.sty { if !self.visited_anon_tys.insert(def_id) { continue; } } } </ins> if subst.visit_with(self) { return true; }

in_body: false, span: krate.span, empty_tables: &empty_tables, <ins> visited_anon_tys: FxHashSet() </ins> }; intravisit::walk_crate(&mut visitor, krate);

<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. // Tests for nested self-reference which caused a stack overflow. use std::fmt::Debug; use std::ops::*; fn gen() -> impl PartialOrd + PartialEq + Debug { } struct Bar {} trait Foo<T = Self> {} impl Foo for Bar {} fn foo() -> impl Foo { Bar {} } fn test_impl_ops() -> impl Add + Sub + Mul + Div { 1 } fn test_impl_assign_ops() -> impl AddAssign + SubAssign + MulAssign + DivAssign { 1 } fn main() {} </ins>
Change:
I am trying to see if -Z pgo-gen is available on Windows-Gnu: I am using: I am using a very small Rust test program: If I compile with: rustc -Z pgo-gen It gives me: error: debugging option requires a string (Z pgo-gen=<value) If I compile with (using a random string?): rustc -Z pgo-gen=abc It gives me: error[E0463]: can't find crate for
Hi, I was also struggling with that! :) The is supposed to be the profile file which details are written into after executing the pgo-gen instrumented binary and details are read from when building the binary for the second time with pgo-use. So  might work :)
I've tried to do as you say, but perhaps I am doing something wrong. I've created a binary project with cargo (just the hello world), then I've set the variable: Then I've compiled: It gives me:
Hm, I'm not sure what is going on there now (I also can't reproduce since not a windows user), sorry :/
Using: Calling rustc directly gives:
GNU toolchain is built without profiler:
I wonder if we could just enable the profiler on .
I think I can find time this week to test it. I'm almost sure PGO was broken on some older GCC version but I cannot recall the details.
Status update: I've got it working few days ago but pushing this upstream is blocked on upgrading to 0.1.15. It was meant to be done by but was backed off.

Discussion:
DEPLOY: 1 - CI_JOB_NAME: dist-i686-mingw MSYS_BITS: 32 <del> RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-full-tools </del> <ins> RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-full-tools --enable-profiler </ins> SCRIPT: python x.py dist MINGW_URL: https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror MINGW_ARCHIVE: i686-6.3.0-release-posix-dwarf-rt_v5-rev2.7z

- CI_JOB_NAME: dist-x86_64-mingw MSYS_BITS: 64 SCRIPT: python x.py dist <del> RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-full-tools </del> <ins> RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-full-tools --enable-profiler </ins> MINGW_URL: https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror MINGW_ARCHIVE: x86_64-6.3.0-release-posix-seh-rt_v5-rev2.7z MINGW_DIR: mingw64

cfg.flag("-fomit-frame-pointer"); cfg.flag("-ffreestanding"); cfg.define("VISIBILITY_HIDDEN", None); <del> cfg.define("COMPILER_RT_HAS_UNAME", Some("1")); </del> <ins> if !target.contains("windows") { cfg.define("COMPILER_RT_HAS_UNAME", Some("1")); } else { profile_sources.push("WindowsMMap.c"); } </ins> } // Assume that the Unixes we are building this for have fnctl() available
Change:
As per comment in
The original fixme comment was introduced in (in the file in that commit; github does not show it for me in the commit, you need to do view file, or not use github. :) From looking at the resolve code, it seems like we indeed push and pop rib objects in a pretty regular fashion, and may also only use it like a stack... (maybe fixing this is actually easy; I do not immediately see a case where the elements of escape from their containing vector...)
I believe resolve has changed quite a bit since this was opened, and I think it's best to track the implementation details of resolve inside of resolve itself to make sure they stay up to date.
This issue is still relevant. That is, we still do allocations (pushes) and deallocations (pops). Maybe we should move from vector to some implementation of stack instead (not that it would decrease amount of allocations much)?

Discussion:
parent_scope: ParentScope<'a>, /// The current set of local scopes for types and values. <del> /// FIXME #4948: Reuse ribs to avoid allocation. </del> ribs: PerNS<Vec<Rib<'a>>>, /// Previous poped `rib`, only used for diagnostic.
Change:
Some of the section anchors that appear when you hover over an item can be difficult to click. It seems to disappear when the mouse transitions over the spacing between the item and the symbol. ! Tested on a variety of browsers, all seem to behave similarly. Rust 1.25 seems OK (there isn't as much spacing). I only notice this on nightly (1.26.0-nightly ( 2018-03-28)).
There is already a PR to fix it .
Resolving? has been merged.
Oh indeed!
Actually it still happens with section headers. I have a small patch I'm testing out to deal with that.

Discussion:
left: -5px; } .small-section-header > .anchor { <del> left: -20px; } .small-section-header > .anchor:not(.field) { </del> left: -28px; <ins> padding-right: 10px; /* avoid gap that causes hover to disappear */ </ins> } .anchor:before { content: '200200a72002';

.section-header:hover a:before { position: absolute; left: -25px; <ins> padding-right: 10px; /* avoid gap that causes hover to disappear */ </ins> content: '200200a72002'; }
Change:
Expressions involving an adaptor function like can cause an internal compiler error. If a line of code in a submodule uses an undeclared type or module in an expression using an adaptor, the compiler panics at . Code in a submodule needs to specify a path relative to the crate root, which means prefixing to a call like . We will use the following two files to demonstrate the issue: Code in a submodule needs to specify a path relative to the crate root, which means prefixing to a call like . If we use the program compiles and runs successfully. As written however, the files above cause this internal compiler error: This panic will occur for other adapters, like . After commenting out the line, the compiler does not panic. and only this output is seen after trying to compile: I ran into this error because the error is not required for code in the crate root. If is moved from to , then the internal compiler error no longer occurs. If code outside of the crate root causes an error due to the use of an undeclared type or module, it would be nice if the compiler warning would mention the possibility of a missing prefix, if the name that could not be resolved was a type or module in the standard library. When I reviewed the information given by running , it mostly mentions the possibility of typos being the cause of this error. Mentioning some other common situations that lead to symbols failing to resolve might be helpful. : Backtrace: P.S. I am still somewhat new to Rust, but I would love to help out with this however I can!
I just tested it and it doesn't ICE anymore, at least not on nightly.

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>
Change:
I got ICE for sometime and also searched in issues but cannot find a relative one. Sorry for not able to produce the minimal cases to pin down the actual failing case in my code base by simply reverting my code. x This issue does not exists in . Error message as follows: meta for 2018-03-21 meta for 2018-03-24 I appreciate any hints and suggestions on helping me to reproduce this issue into minimal case but right now I just can't find out what changes in my code caused this problem. My code base is
I have dig into this and found the snippet of code caused this problem: It should produce an error which did not appeared in previous build This is not the whole story, when I assign to a variable and return the variable, it got the same ICE but the type inference error gone. I finally able to mitigate the problem by turning the return type from to
I got a possibly same ICE with this code: Meta: <detailsBacktrace: </details
This gives me the same ICE: However this does not ICE:
Hi all. does not fix my issue.
Sorry, I forgot to test with your case. Though you seem to be using a nightly-2018-03-23 which can never contain unmerged , right? depends on which is not even compilable with recent nightlies.
Hi, sorry for the slow reply. I will try that again once the branch have been merged. Any ETA on when it will go into nightly? Thanks
No, it varies due to approval of other PRs. Here is the current queue:
Nightly 2018-04-14 contains . Could you reopen if the problem persists?
As at least one data point, I had the same issue and it was resolved with 2018-04-15.

Discussion:
match r { // ignore bound regions that appear in the type (e.g., this // would ignore `'r` in a type like `for<'r> fn(&'r u32)`. <del> ty::ReLateBound(..) => return r, </del> <ins> ty::ReLateBound(..) | </ins> // ignore `'static`, as that can appear anywhere <del> ty::ReStatic => return r, </del> <ins> ty::ReStatic | // ignore `ReScope`, as that can appear anywhere // See `src/test/run-pass/issue-49556.rs` for example. ty::ReScope(..) => return r, </ins> _ => { } }

self.msg_span_from_early_bound_and_free_regions(region) }, ty::ReStatic => ("the static lifetime".to_owned(), None), <del> _ => bug!(), </del> <ins> _ => bug!("{:?}", region), </ins> } }

<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. fn iter<'a>(data: &'a [usize]) -> impl Iterator<Item = usize> + 'a { data.iter() .map( |x| x // fn(&'a usize) -> &'(ReScope) usize ) .map( |x| *x // fn(&'(ReScope) usize) -> usize ) } fn main() { } </ins>