jiebi/CodeConvo huggingface dataset:
Change:
Steps to reproduce: 1) make an new crate, set crate type to 2) put a simple function in : 3) build with 4) copy the command line used from above step, and run it as-is example: As you can see, the first time in step 3) has no warnings, however, step 4) cause complains is unused, which isn't true. Step 4) can be replaced by: modify , so that it cause rebuild run again rustc 1.35.0-nightly ( 2019-04-16)
I have same error on today's nightly too
Same for me
I see the same warning text during a build for crate type “staticlib” using nightly 1.36.0 commit 2019-04-18
I will bisect this and then pass the baton to to fix this.
Bisection claims , (). cc
My guess is that should be a attribute? It was declared twice before and the variant got removed.
Also our scheme to track unused attributes does not work the incremental compilation, which is probably why it only happens with that.
cc
A fix is up. I this still nightly only or do we need to backport?
Seems to be nightly-only still
I get this with regular on a crate type with nightly
can you try with the latest nightly? This was only closed yesterday, so today's nightly should contain the fix.
My case () is no longer reproducible on 2019-05-21 nightly.
I no longer see the ~error~ warning with .
Yep it seems it's fixed. sorry I missed that it was merged yesterday. thanks!

Discussion:
(sym::repr, Normal, template!(List: "C, packed, ..."), Ungated), (sym::path, Normal, template!(NameValueStr: "file"), Ungated), (sym::automatically_derived, Normal, template!(Word), Ungated), <del> (sym::no_mangle, Normal, template!(Word), Ungated), </del> <ins> (sym::no_mangle, Whitelisted, template!(Word), Ungated), </ins> (sym::no_link, Normal, template!(Word), Ungated), (sym::derive, Normal, template!(List: "Trait1, Trait2, ..."), Ungated), (

<ins> // revisions:rpass1 rpass2 // compile-flags: --crate-type cdylib // skip-codegen #![deny(unused_attributes)] #[no_mangle] pub extern "C" fn rust_no_mangle() -> i32 { 42 } </ins>

//~^ WARN unused attribute #![path = "3800"] //~ WARN unused attribute #![automatically_derived] //~ WARN unused attribute <del> #![no_mangle] //~ WARN unused attribute </del> <ins> #![no_mangle] </ins> #![no_link] //~ WARN unused attribute // see issue-43106-gating-of-derive.rs #![should_panic] //~ WARN unused attribute

| ^^^^^^^^^^^^^^^^^^^^^^^^^ warning: unused attribute <del> --> $DIR/issue-43106-gating-of-builtin-attrs.rs:55:1 | LL | #![no_mangle] | ^^^^^^^^^^^^^ warning: unused attribute </del> --> $DIR/issue-43106-gating-of-builtin-attrs.rs:56:1 | LL | #![no_link]
Change:
I got an internal compiler error while compiling some code with a syntax error. The error is in the final line of the match statement in the function parse. () Errors:
triage: P-high. (Unnominating since there doesn't seem to be much else to discuss)
Assigning myself to look into and fix.
:
this ICE only happens for already broken code, I don't believe this is P-high.

Discussion:
}; (respan(self.prev_span, Constness::NotConst), unsafety, abi) }; <del> self.expect_keyword(keywords::Fn)?; </del> <ins> if !self.eat_keyword(keywords::Fn) { // It is possible for `expect_one_of` to recover given the contents of // `self.expected_tokens`, therefore, do not use `self.unexpected()` which doesn't // account for this. if !self.expect_one_of(&[], &[])? { unreachable!() } } </ins> Ok((constness, unsafety, asyncness, abi)) }

<ins> fn main() {} trait T { fn qux() -> Option<usize> { let _ = if true { }); //~^ ERROR expected one of `async`, `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `;` //~^^ ERROR expected one of `.`, `;`, `?`, `else`, or an operator, found `}` //~^^^ ERROR 6:11: 6:12: expected identifier, found `;` //~^^^^ ERROR missing `fn`, `type`, or `const` for trait-item declaration Some(4) } </ins>

<ins> error: expected one of `.`, `;`, `?`, `else`, or an operator, found `}` --> $DIR/issue-60075.rs:6:10 | LL |         }); |          ^ expected one of `.`, `;`, `?`, `else`, or an operator here error: expected one of `async`, `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `;` --> $DIR/issue-60075.rs:6:11 | LL |     fn qux() -> Option<usize> { |                               - unclosed delimiter LL |         let _ = if true { LL |         }); |           ^ |           | |           help: `}` may belong here error: expected identifier, found `;` --> $DIR/issue-60075.rs:6:11 | LL |         }); |           ^ expected identifier error: missing `fn`, `type`, or `const` for trait-item declaration --> $DIR/issue-60075.rs:6:12 | LL |           }); |  ____________^ LL | | LL | | LL | | LL | | LL | |         Some(4) | |________^ missing `fn`, `type`, or `const` error: aborting due to 4 previous errors </ins>
Change:
Hi, I got the compiler to panic with this invalid code: The panic does not happen when the code is outside . Happens on Backtrace : and also on Backtrace :
First appeared in 1.33.0, 1.32.0 gives this error:

Discussion:
} else { ("fn` or `struct", "function or struct", true) }; <del> self.consume_block(token::Brace); </del> let msg = format!("missing `{}` for {} definition", kw, kw_name); let mut err = self.diagnostic().struct_span_err(sp, &msg); if !ambiguous { <ins> self.consume_block(token::Brace); </ins> let suggestion = format!("add `{}` here to parse `{}` as a public {}", kw, ident,

<ins> // #60115 mod foo { pub bar(); //~^ ERROR missing `fn` or `struct` for function or struct definition } fn main() {} </ins>

<ins> error: missing `fn` or `struct` for function or struct definition --> $DIR/pub-ident-fn-3.rs:4:8 | LL |     pub bar(); |     ---^--- help: if you meant to call a macro, try: `bar!` error: aborting due to previous error </ins>
Change:
from a crater run: crate affected: interact (0.3.3), named-tuple (0.1.2), photonix (0.1.1), serdetuple (0.2.2), susy-codec (3.1.0), thrift (0.12.0), zeroize (0.6.0) authors: logs: https://crater- https://crater- https://crater- https://crater- https://crater- https://crater-, https://crater- probable duplicate of
cc
thrift and zeroize are the regressions that are most notable here; the others don't have notable reverse dependencies.

Discussion:
if text.is_empty() { self.span_bug(sp, "found empty literal suffix in Some") } <del> self.struct_span_err(sp, &format!("suffixes on {} are invalid", kind)) .span_label(sp, format!("invalid suffix `{}`", text)) .emit(); </del> <ins> let mut err = if kind == "a tuple index" && ["i32", "u32", "isize", "usize"].contains(&text.to_string().as_str()) { // #59553: warn instead of reject out of hand to allow the fix to percolate // through the ecosystem when people fix their macros let mut err = self.struct_span_warn( sp, &format!("suffixes on {} are invalid", kind), ); err.note(&format!( "`{}` is *temporarily* accepted on tuple index fields as it was  incorrectly accepted on stable for a few releases", text, )); err.help( "on proc macros, you'll want to use `syn::Index::from` or  `proc_macro::Literal::*_unsuffixed` for code that will desugar  to tuple field access", ); err.note( "for more context, see https://github.com/rust-lang/rust/issues/60210", ); err } else { self.struct_span_err(sp, &format!("suffixes on {} are invalid", kind)) }; err.span_label(sp, format!("invalid suffix `{}`", text)); err.emit(); </ins> } } }

fn struct_span_err<S: Into<MultiSpan>>(&self, sp: S, m: &str) -> DiagnosticBuilder<'a> { self.sess.span_diagnostic.struct_span_err(sp, m) } <ins> fn struct_span_warn<S: Into<MultiSpan>>(&self, sp: S, m: &str) -> DiagnosticBuilder<'a> { self.sess.span_diagnostic.struct_span_warn(sp, m) } </ins> crate fn span_bug<S: Into<MultiSpan>>(&self, sp: S, m: &str) -> ! { self.sess.span_diagnostic.span_bug(sp, m) }
Change:
The following code: results in an ICE Tested this on stable and nightly. May be somehow related to .
Backtrace: Happens on stable, beta, nightly
Litte bit simplified:
Bisection show ICE was introduced in , but I'm not sure how related that is, because it's a very very big PR. CC
I will investigate.
ping , any progress here?
I did some investigation. This bugs turns out to have been fixed -- well, more likely it was worked around by I'm going to land a test for it so that when I get around to reversing , I can fix it then.

Discussion:
<ins> // Regression test for #60218 // // This was reported to cause ICEs. use std::iter::Map; pub trait Foo {} pub fn trigger_error<I, F>(iterable: I, functor: F) where for<'t> &'t I: IntoIterator, for<'t> Map<<&'t I as IntoIterator>::IntoIter, F>: Iterator, for<'t> <Map<<&'t I as IntoIterator>::IntoIter, F> as Iterator>::Item: Foo, { } fn main() { trigger_error(vec![], |x: &u32| x) //~ ERROR E0277 } </ins>

<ins> error[E0277]: the trait bound `for<'t> <std::iter::Map<<&'t _ as std::iter::IntoIterator>::IntoIter, _> as std::iter::Iterator>::Item: Foo` is not satisfied --> $DIR/issue-60218.rs:18:5 | LL | pub fn trigger_error<I, F>(iterable: I, functor: F) |        ------------- ... LL | for<'t> <Map<<&'t I as IntoIterator>::IntoIter, F> as Iterator>::Item: Foo, |                                                                        --- required by this bound in `trigger_error` ... LL |     trigger_error(vec![], |x: &u32| x) |     ^^^^^^^^^^^^^ the trait `for<'t> Foo` is not implemented for `<std::iter::Map<<&'t _ as std::iter::IntoIterator>::IntoIter, _> as std::iter::Iterator>::Item` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>
Change:
This is a tracking issue for and , proposed and implemented in
modify labels to T-libs, C-tracking-issue.
These have been available on nightly for some time with no controversy. They're pretty useful when working with -- do y'all have anything you'd like to see here before merging?
Let's see! Proposed APIs look to be: fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [ ] [x] [x] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
r+
I don't think you can r+ issues ;)
Since this seems to have gone quiet again, I took the liberty of creating to do the actual stabilization.

Discussion:
/// can ignore the pinning invariants when unwrapping it. /// /// [`Unpin`]: ../../std/marker/trait.Unpin.html <del> #[unstable(feature = "pin_into_inner", issue = "60245")] </del> <ins> #[stable(feature = "pin_into_inner", since = "1.39.0")] </ins> #[inline(always)] pub fn into_inner(pin: Pin<P>) -> P { pin.pointer

/// /// [`Unpin`]: ../../std/marker/trait.Unpin.html /// [`Pin::into_inner`]: #method.into_inner <del> #[unstable(feature = "pin_into_inner", issue = "60245")] </del> <ins> #[stable(feature = "pin_into_inner", since = "1.39.0")] </ins> #[inline(always)] pub unsafe fn into_inner_unchecked(pin: Pin<P>) -> P { pin.pointer
Change:
The following ICE's on nightly only: Notice I didn't specify the feature <details<summaryBacktrace:</summary</details
In general, presence or absence of shouldn't affect compiler's behavior in any way beside reporting the "feature is unstable" error, so ICEs like this need to fixed unconditionally.
Strongly related (not sure why two issues though) with and therefore with and I already pinged you in because of this ;)
2 issue's because the ICE messages are different, sorry for the confusion! To clearify, on both issue's there are 2 things wrong: Being able to get the ICE's, without specifying the feature The ICE's themselves (Which was likely to happen, given the incompleteness. Consider these as test-cases, or something :) )
This should be fixed on the next nightly, but will add a regression test for it.

Discussion:
<ins> struct B<const I: u8>; //~ ERROR const generics are unstable impl B<0> { fn bug() -> Self { panic!() } } fn main() {} </ins>

<ins> error[E0658]: const generics are unstable --> $DIR/issue-60263.rs:1:16 | LL | struct B<const I: u8>; |                ^ | = note: for more information, see https://github.com/rust-lang/rust/issues/44580 = help: add #![feature(const_generics)] to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0658`. </ins>
Change:
Another ICE that uses a nightly only feature, but still crashes on stable, beta and nightly without the flag. According to godbolt, this sneaked in with 1.34. 1.33 and lower are not affected. <details<summaryBacktrace:</summary
nevermind I was thinking of , which you also filed
I found this verry related:
Again this is kinda 2 issue's in 1, so I dont know if this should have it's own issue... After some more trying, I found this also panics, but only on nightly: Notice I removed the on the line <details<summaryBacktrace:</summary</details
Another one, stable, beta & nightly: <details<summaryBacktrace:</summary</details
triage: P-high due to ICE; removing nomination.
Likely duplicate from

Discussion:
} } <del> let new = ty::ResolvedOpaqueTy { concrete_type: definition_ty, substs: self.tcx().lift_to_global(&opaque_defn.substs).unwrap(), }; let old = self.tables .concrete_existential_types .insert(def_id, new); if let Some(old) = old { if old.concrete_type != definition_ty || old.substs != opaque_defn.substs { span_bug!( span, "visit_opaque_types tried to write  different types for the same existential type: {:?}, {:?}, {:?}, {:?}", def_id, definition_ty, opaque_defn, old, ); </del> <ins> if let Some(substs) = self.tcx().lift_to_global(&opaque_defn.substs) { let new = ty::ResolvedOpaqueTy { concrete_type: definition_ty, substs, }; let old = self.tables .concrete_existential_types .insert(def_id, new); if let Some(old) = old { if old.concrete_type != definition_ty || old.substs != opaque_defn.substs { span_bug!( span, "visit_opaque_types tried to write  different types for the same existential type: {:?}, {:?}, {:?}, {:?}", def_id, definition_ty, opaque_defn, old, ); } </ins> } <ins> } else { self.tcx().sess.delay_span_bug( span, "cannot lift `opaque_defn` substs to global type context", ); </ins> } } }

<ins> trait Bug { type Item: Bug; const FUN: fn() -> Self::Item; } impl Bug for &() { existential type Item: Bug; //~ ERROR existential types are unstable //~^ ERROR the trait bound `(): Bug` is not satisfied //~^^ ERROR could not find defining uses const FUN: fn() -> Self::Item = || (); } fn main() {} </ins>

<ins> error[E0658]: existential types are unstable --> $DIR/issue-60371.rs:8:5 | LL |     existential type Item: Bug; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/34511 = help: add #![feature(existential_type)] to the crate attributes to enable error[E0277]: the trait bound `(): Bug` is not satisfied --> $DIR/issue-60371.rs:8:5 | LL |     existential type Item: Bug; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Bug` is not implemented for `()` | = help: the following implementations were found: <&() as Bug> = note: the return type of a function must have a statically known size error: could not find defining uses --> $DIR/issue-60371.rs:8:5 | LL |     existential type Item: Bug; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 3 previous errors Some errors have detailed explanations: E0277, E0658. For more information about an error, try `rustc --explain E0277`. </ins>
Change:
since
It is hitting the here: So I'm not quite sure why the error isn't being emitted yet.
It appears to be hitting this line of code which is cancelling the diagnostic:
this appears to be a stable-to-beta regression ()
triage: P-high. Assigning to self.
We need to change to not consider desugarings coming from loops as external. If that has regressions in our test suite, then we can add a new desugaring kind to differentiate between different parts of the for loop desugaring and target it further, but I do not expect that to be needed.
I've opened with a fix, based on comment.

Discussion:
use errors::{DiagnosticBuilder, DiagnosticId}; use std::{hash, ptr}; use syntax::ast; <del> use syntax::source_map::{MultiSpan, ExpnFormat}; </del> <ins> use syntax::source_map::{MultiSpan, ExpnFormat, CompilerDesugaringKind}; </ins> use syntax::early_buffered_lints::BufferedEarlyLintId; use syntax::edition::Edition; use syntax::symbol::{Symbol, sym};

}; match info.format { <del> ExpnFormat::MacroAttribute(..) => return true, // definitely a plugin ExpnFormat::CompilerDesugaring(_) => return true, // well, it's "external" ExpnFormat::MacroBang(..) => {} // check below } let def_site = match info.def_site { Some(span) => span, // no span for the def_site means it's an external macro None => return true, }; </del> <ins> ExpnFormat::MacroAttribute(..) => true, // definitely a plugin ExpnFormat::CompilerDesugaring(CompilerDesugaringKind::ForLoop) => false, ExpnFormat::CompilerDesugaring(_) => true, // well, it's "external" ExpnFormat::MacroBang(..) => { let def_site = match info.def_site { Some(span) => span, // no span for the def_site means it's an external macro None => return true, }; </ins> <del> match sess.source_map().span_to_snippet(def_site) { Ok(code) => !code.starts_with("macro_rules"), // no snippet = external macro or compiler-builtin expansion Err(_) => true, </del> <ins> match sess.source_map().span_to_snippet(def_site) { Ok(code) => !code.starts_with("macro_rules"), // no snippet = external macro or compiler-builtin expansion Err(_) => true, } } </ins> } }

fn main() { let x: u8 = 256; //~^ error: literal out of range for `u8` <ins> for _ in 0..256u8 {} //~^ error: range endpoint is out of range for `u8` </ins> }

| = note: #[deny(overflowing_literals)] on by default <del> error: aborting due to previous error </del> <ins> error: range endpoint is out of range for `u8` --> $DIR/deny-overflowing-literals.rs:5:14 | LL |     for _ in 0..256u8 {} |              ^^^^^^^^ help: use an inclusive range instead: `0..=255u8` error: aborting due to 2 previous errors </ins>

fn main() { for _ in unimplemented!() as Void {} //~^ ERROR unreachable pattern <ins> //~^^ ERROR unreachable pattern </ins> }

LL | #![deny(unreachable_patterns)] |         ^^^^^^^^^^^^^^^^^^^^ <del> error: aborting due to previous error </del> <ins> error: unreachable pattern --> $DIR/unreachable-loop-patterns.rs:20:14 | LL |     for _ in unimplemented!() as Void {} |              ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors </ins>
Change:
Code: Error: Rustc version: rustc 1.36.0-nightly ( 2019-05-02)
modify labels: A-async-await and T-compiler.
I wonder if this is related to the drop order fix desugaring?
Oops, looks like it is. Thanks for the fix.

Discussion:
// Check if this is a ident pattern, if so, we can optimize and avoid adding a // `let <pat> = __argN;` statement, instead just adding a `let <pat> = <pat>;` // statement. <del> let (ident, is_simple_pattern) = match input.pat.node { PatKind::Ident(_, ident, _) => (ident, true), _ => (ident, false), </del> <ins> let (binding_mode, ident, is_simple_pattern) = match input.pat.node { PatKind::Ident(binding_mode, ident, _) => (binding_mode, ident, true), _ => (BindingMode::ByValue(Mutability::Immutable), ident, false), </ins> }; // Construct an argument representing `__argN: <ty>` to replace the argument of the

let move_local = Local { pat: P(Pat { id, <del> node: PatKind::Ident( BindingMode::ByValue(Mutability::Immutable), ident, None, ), </del> <ins> node: PatKind::Ident(binding_mode, ident, None), </ins> span, }), // We explicitly do not specify the type for this statement. When the user's

<ins> // edition:2018 // run-pass #![feature(async_await)] async fn foo(n: u32, mut vec: Vec<u32>) { vec.push(n); } fn main() {} </ins>
Change:
Adding some with unbalanced parens in some file in the rust directory makes fail with the following error and backtrace: Which is rather unhelpful.
Looking at means, that should be (or similar) If that wording is okay, I would go and file a PR
Rather than panicking, it would be better to throw an error (e.g. using ). (I think would read slightly better.)
Note that there are other cases where there is an error message like: It seems like we should get the same here too. Edit: Come to think of it, this one might be coming from the compiler.
We could just ignore s with unbalanced parentheses in tidy, as they'll be picked up during compilation. In that case, removing the and adding a comment to that effect should be enough.

Discussion:
succeeds_non_ident && preceeds_whitespace_and_paren }); <del> cfgs.map(|i| { </del> <ins> cfgs.flat_map(|i| { </ins> let mut depth = 0; let contents_from = &contents[i..]; for (j, byte) in contents_from.bytes().enumerate() {

b')' => { depth -= 1; if depth == 0 { <del> return (i, &contents_from[..=j]); </del> <ins> return Some((i, &contents_from[..=j])); </ins> } } _ => { } } } <del> unreachable!() </del> <ins> // if the parentheses are unbalanced just ignore this cfg -- it'll be caught when attempting // to run the compiler, and there's no real reason to lint it separately here None </ins> }).collect() }
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Miri-side fix at which is blocked on
Also blocked on
triage: P-medium
This was fixes a while ago. But now miri broke again and no new issue was opened? Cc
I was about to post the following here(a few minutes before you commented, RalfJung) when my system , so here it is after a re-run(hence it took only a few seconds instead of 34mins):
The fix is in progress at Building Miri takes 34min for you? oO wow.
ah no, that was the output from building rust.
Blocked on and

Discussion:
"env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)", "hex 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", <ins> "num-traits 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-workspace-hack 1.0.0", "rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)",

<del> Subproject commit 0c85dbf3df0f545133dca24eccfc9f0f6107c7f8 </del> <ins> Subproject commit e1a0f66373a1a185334a6e3be24e94161e3b4a43 </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
I was wondering why I got even though I compiled rust with in , however I got no errors during any compile&install step.
Well, I'm still getting with this : I basically used the following to compile: ok, a more up to date one:
ah looks like it's my bad for using which apparently is required for to have any effect, now I get which is a lot better! I gotta admit, I didn't expect it to be so from reading this:

Discussion:
<del> Subproject commit 2ed0b3bfa05c796c6645ed1814cd372e73f45c66 </del> <ins> Subproject commit fc96aa036884183ddc68d2659f4633e6f138b4e0 </ins>