jiebi/CodeConvo huggingface dataset:
Change:
From: This description of the grammar has at least two errors: It does not allow for '3f;' which is shown to be expected to be valid on -- either the or must be present according to the diagram. The signed path does not permit to be omitted, although the parser does allow this. I've gone over the lexer in libsyntax and I have not yet come across anything else that does not match the docs, but it would be good to get these in order for the benefit of those of us writing syntax highlighters for our editors, and the like. I'll have a patch up soon.

Discussion:
num_suffix : int_suffix | float_suffix ; int_suffix : 'u' int_suffix_size ? <del> | 'i' int_suffix_size ; </del> <ins> | 'i' int_suffix_size ? ; </ins> int_suffix_size : [ '8' | '1' '6' | '3' '2' | '6' '4' ] ; <del> float_suffix : [ exponent | '.' dec_lit exponent ? ] float_suffix_ty ? ; </del> <ins> float_suffix : [ exponent | '.' dec_lit exponent ? ] ? float_suffix_ty ? ; </ins> float_suffix_ty : 'f' [ '3' '2' | '6' '4' ] ; exponent : ['E' | 'e'] ['-' | '+' ] ? dec_lit ; dec_lit : [ dec_digit | '_' ] + ;
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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 compiler team prioritization.

Discussion:
<del> Subproject commit a8d90f6a57925d204efb21b3f6d9726d6674f9bd </del> <ins> Subproject commit fd0428f622feee209e6014b802f5717d48d9e978 </ins>
Change:
I'm sure that there is a more concise way to generate this error, but this produces a lint warning: () This code instantiates , but the lint disagrees:
Something small-ish-er: If we replace by , then it will change to: which is indeed correct
This is probably the most telling example: This doesn't compile (deadcode), and doesn't lint with clippy (clippy::useself, likely due to rust-lang/rust-clippy). The dead_code problem doesn't manifest if is simple or a newtype ( is OK), it needs to be a struct.
It looks like the erroneous warning arises only for struct-like enum variants that are created only by referencing via . In this example program, the only warning is for : ()
These seem to have been fixed. The above playground link has no warnings.
searched nightlies: from nightly-2020-01-26 to nightly-2020-08-03 regressed nightly: nightly-2020-05-03 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsHow is that related? But nevertheless: modify labels: E-needs-test
That bisection may be because of a bug in cargo-bisect-rustc that was fixed in the latest release; see rust-lang/cargo-bisect-rustc.

Discussion:
<ins> // check-pass // Make sure we don't have any false positives here. #![deny(dead_code)] enum X { A { _a: () }, B { _b: () }, } impl X { fn a() -> X { X::A { _a: () } } fn b() -> Self { Self::B { _b: () } } } fn main() { let (_, _) = (X::a(), X::b()); } </ins>
Change:
I was using the latest version of  and tried to store a reference without a lifetime annotated in a macro-generated error. This shouldn't (and doesn't) work, but rustc should at least throw an error instead of blowing up, right? Code sample: I expected an error of some sort about lifetimes or macros, but instead, the compiler ed: thread 'rustc' panicked at 'called on an value: DistinctSources(DistinctSources { begin: (Real(""), BytePos(0)), end: (Macros("::quickerror::quickerror"), BytePos()) })', This rustc was compiled on Gentoo from a recent . $ rustc --version --verbose rustc 1.42.0-dev ( 2020-01-21) binary: rustc commit-hash: commit-date: 2020-01-21 host: x8664-unknown-linux-gnu release: 1.42.0-dev LLVM version: 9.0 Minimal example: Backtrace:
rustc in playpen isn't the latest compiler. reopen
cc
Backtrace:
triage: P-high, assigning to . (It would be good to confirm it is indeed due to the CC'ed PR via bisection...)
Full backtrace: From a quick look it seems like might tackle this. Rebuilding a recent master to confirm.

Discussion:
!invalid }) .cloned() <del> .map(|mut substitution| { </del> <ins> .filter_map(|mut substitution| { </ins> // Assumption: all spans are in the same file, and all spans // are disjoint. Sort in ascending order. substitution.parts.sort_by_key(|part| part.span.lo()); // Find the bounding span. <del> let lo = substitution.parts.iter().map(|part| part.span.lo()).min().unwrap(); let hi = substitution.parts.iter().map(|part| part.span.hi()).max().unwrap(); </del> <ins> let lo = substitution.parts.iter().map(|part| part.span.lo()).min()?; let hi = substitution.parts.iter().map(|part| part.span.hi()).max()?; </ins> let bounding_span = Span::with_root_ctxt(lo, hi); <del> let lines = cm.span_to_lines(bounding_span).unwrap(); </del> <ins> // The different spans might belong to different contexts, if so ignore suggestion. let lines = cm.span_to_lines(bounding_span).ok()?; </ins> assert!(!lines.lines.is_empty()); // To build up the result, we do this for each span:

while buf.ends_with('n') { buf.pop(); } <del> (buf, substitution.parts, only_capitalization) </del> <ins> Some((buf, substitution.parts, only_capitalization)) </ins> }) .collect() }

LL | const MUTABLE_BEHIND_RAW: *mut i32 = &UnsafeCell::new(42) as *const _ as *mut _; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:356:17 </del> <ins> thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:357:17 </ins> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace error: internal compiler error: unexpected panic
Change:
I got an internal compiler error at commit . I dont know how to minimize it. Relevant code is: If I remove the const field and directly put the array size like below, the ICE goes away and I get the expected compilation error that [u8; 68] is not . <details<summaryBacktrace:</summary</details<details<summaryVersion info</summary</details
The ICE also goes away if I change to
Ok. I minimized it to just: It ICEs on latest nightly:
triage: P-high, assiging to self, removing nomination label
Following example fails to compile: <details<summaryError</summary</detailsEven if I add , still issue: or <details<summaryError</summary</detailsBut this works:
Also just got this; no idea how to minimize it and the trace doesn't seem useful:-
If this is referring to the field , it's defined as where is defined inside the impl as .
Inlining resolves the error, ie changing buffer's definition to .
no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

Discussion:
<ins> // Regression test for https://github.com/rust-lang/rust/issues/56445#issuecomment-629426939 // check-pass #![crate_type = "lib"] use std::marker::PhantomData; pub struct S<'a> { pub m1: PhantomData<&'a u8>, pub m2: [u8; S::size()], } impl<'a> S<'a> { pub const fn size() -> usize { 1 } pub fn new() -> Self { Self { m1: PhantomData, m2: [0; Self::size()], } } } </ins>

<ins> // check-pass pub struct A<'a>(&'a ()); impl<'a> A<'a> { const N: usize = 68; pub fn foo(&self) { let _b = [0; Self::N]; } } fn main() {} </ins>

<ins> #![feature(impl_trait_in_bindings)] #![allow(incomplete_features)] fn main() { const C: impl Copy = 0; match C { C | _ => {} //~ ERROR: opaque types cannot be used in patterns } } </ins>

<ins> error: opaque types cannot be used in patterns --> $DIR/issue-71042-opaquely-typed-constant-used-in-pattern.rs:7:9 | LL |         C | _ => {} |         ^ error: aborting due to previous error </ins>

<ins> // check-pass #![feature(type_alias_impl_trait)] pub type Successors<'a> = impl Iterator<Item = &'a ()>; pub fn f<'a>() -> Successors<'a> { None.into_iter() } pub trait Tr { type Item; } impl<'a> Tr for &'a () { type Item = Successors<'a>; } pub fn kazusa<'a>() -> <&'a () as Tr>::Item { None.into_iter() } fn main() {} </ins>
Change:
Steps to replicate: two files and in the same directory with the following content: both files the following error I note that the looks quite suspicious, since there are fewer than bytes in the source text. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Full trace:
there's a single in . You can just return if the output of is .
Are you sure that's correct? I was looking at the invalid that begins in the source file and ends in a separate virtual file. It seems like it should always be an error to record a into the such that is false. And perhaps if this were corrected, the would succeed.
That is a correct assessment, but the current state is that whenever we involve macros we can easily generate incorrect s. We shouldn't, but fixing that underlying issue is much harder than just dealing with the fallout. We have some efforts to clean up the situation around (and its gotten much better lately), but there are cases like for suggestions where we are assembling new spans from different sources and checking at generation time that they are valid would become too verbose and hide the actual logic. For now, I would just fix the stray and fix the ICE so that we can buy time.
A compiler built from that pull request no longer exhibits an ICE on this example.
Thanks for fixing it!

Discussion:
pluralize, CodeSuggestion, Diagnostic, DiagnosticId, Level, SubDiagnostic, SuggestionStyle, }; <ins> use log::*; </ins> use rustc_data_structures::fx::FxHashMap; use rustc_data_structures::sync::Lrc; use rustc_span::hygiene::{ExpnKind, MacroKind};

/// Whether the original and suggested code are visually similar enough to warrant extra wording. pub fn is_case_difference(sm: &SourceMap, suggested: &str, sp: Span) -> bool { // FIXME: this should probably be extended to also account for `FO0` → `FOO` and unicode. <del> let found = sm.span_to_snippet(sp).unwrap(); </del> <ins> let found = match sm.span_to_snippet(sp) { Ok(snippet) => snippet, Err(e) => { warn!("Invalid span {:?}. Err={:?}", sp, e); return false; } }; </ins> let ascii_confusables = &['c', 'f', 'i', 'k', 'o', 's', 'u', 'v', 'w', 'x', 'y', 'z']; // All the chars that differ in capitalization are confusable (above): let confusable = found
Change:
When running in the subdirectory, a call to with causes the following ICE: I'm not exactly sure what additional information to provide? I filed an issue with , and was forwarded here since it is an ICE.
I've minimized it a bit: It still uses external crates but the example itself is very small.
compile it with: Although is behind a feature gate it will ICE without the feature gate! modify labels: F-typealiasimpltrait ICE code:

Discussion:
return tcx.has_typeck_tables(outer_def_id); } <del> let id = tcx.hir().as_local_hir_id(def_id).unwrap(); primary_body_of(tcx, id).is_some() </del> <ins> if let Some(id) = tcx.hir().as_local_hir_id(def_id) { primary_body_of(tcx, id).is_some() } else { false } </ins> } fn used_trait_imports(tcx: TyCtxt<'_>, def_id: DefId) -> &DefIdSet {

<ins> // compile-flags: -Zsave-analysis #![feature(type_alias_impl_trait)] trait Trait {} trait Service { type Future: Trait; } struct Struct; impl Service for Struct { type Future = impl Trait; //~ ERROR: could not find defining uses } fn main() {} </ins>

<ins> error: could not find defining uses --> $DIR/issue-68621.rs:14:5 | LL |     type Future = impl Trait; |     ^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

<ins> // compile-flags: -Zsave-analysis </ins> #![feature(type_alias_impl_trait)] type Closure = impl FnOnce(); //~ ERROR: type mismatch resolving

<del> error[E0271]: type mismatch resolving `<[closure@$DIR/issue-63279.rs:6:5: 6:28] as std::ops::FnOnce<()>>::Output == ()` --> $DIR/issue-63279.rs:3:1 </del> <ins> error[E0271]: type mismatch resolving `<[closure@$DIR/issue-63279.rs:8:5: 8:28] as std::ops::FnOnce<()>>::Output == ()` --> $DIR/issue-63279.rs:5:1 </ins> | LL | type Closure = impl FnOnce(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected opaque type, found `()`

<ins> // compile-flags: -Zsave-analysis </ins> // check-pass #![feature(type_alias_impl_trait)]
Change:
I'm seeing an internal compiler error on the following input (found by ): My compiler version is: I also observe the error on , but not on .

Discussion:
.span_to_snippet(self.prev_span) .map(|s| s.ends_with(")") || s.ends_with("]")) .unwrap_or(false); <del> let right_brace_span = if has_close_delim { // it's safe to peel off one character only when it has the close delim self.prev_span.with_lo(self.prev_span.hi() - BytePos(1)) } else { self.prev_span.shrink_to_hi() }; self.struct_span_err( </del> <ins> let mut err = self.struct_span_err( </ins> self.prev_span, "macros that expand to items must be delimited with braces or followed by a semicolon", <del> ) .multipart_suggestion( "change the delimiters to curly braces", vec![ (self.prev_span.with_hi(self.prev_span.lo() + BytePos(1)), "{".to_string()), (right_brace_span, '}'.to_string()), ], Applicability::MaybeIncorrect, ) .span_suggestion( </del> <ins> ); // To avoid ICE, we shouldn't emit actual suggestions when it hasn't closing delims if has_close_delim { err.multipart_suggestion( "change the delimiters to curly braces", vec![ (self.prev_span.with_hi(self.prev_span.lo() + BytePos(1)), '{'.to_string()), (self.prev_span.with_lo(self.prev_span.hi() - BytePos(1)), '}'.to_string()), ], Applicability::MaybeIncorrect, ); } else { err.span_suggestion( self.prev_span, "change the delimiters to curly braces", " { /* items */ }".to_string(), Applicability::HasPlaceholders, ); } err.span_suggestion( </ins> self.prev_span.shrink_to_hi(), "add a semicolon", ';'.to_string(),

| help: change the delimiters to curly braces | <del> LL | y!{ LL | Ϥ} | </del> <ins> LL | y! { /* items */ } |    ^^^^^^^^^^^^^^^ </ins> help: add a semicolon | LL | Ϥ,;

| help: change the delimiters to curly braces | <del> LL | macro_rules! abc{ؼ} |                 ^ ^ </del> <ins> LL | macro_rules! abc { /* items */ } |                  ^^^^^^^^^^^^^^^ </ins> help: add a semicolon | LL | macro_rules! abc(ؼ;
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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 compiler team prioritization.

Discussion:
<del> Subproject commit fa046d2e7f14cda09d14230cc8c772e1565e0757 </del> <ins> Subproject commit c0f39cfb466202a1dbe8368ca177848083dc34cb </ins>
Change:
For example, this is clearly wrong in : But is called in other places throughout this file and I'm not immediately sure which ones are right vs wrong.
The other calls to look fine. It's just that one that's wrong (my mistake).

Discussion:
ty_param(_) => result = false, ty_opaque_closure_ptr(_) => result = true, ty_struct(did, ref substs) => { <del> result = vec::any(lookup_struct_fields(cx, did), |f| { </del> <ins> result = vec::all(lookup_struct_fields(cx, did), |f| { </ins> let fty = ty::lookup_item_type(cx, f.id); let sty = subst(cx, substs, fty.ty); type_is_pod(cx, sty)
Change:
This code causes an ICE starting from Rust 1.41.0 (stable, beta, and nightly): Error: No extra flags were . It also happens in release mode. Rust Playground is at version 1.40.0 and doesn't have the error on stable:
Another version:
cc
Bisected: ,
This should be checking before calling :
triage: P-high. Removing nomination. Assigning to self.

Discussion:
let cid = key.value; let def_id = cid.instance.def.def_id(); <del> if def_id.is_local() && tcx.typeck_tables_of(def_id).tainted_by_errors { </del> <ins> if def_id.is_local() && tcx.has_typeck_tables(def_id) && tcx.typeck_tables_of(def_id).tainted_by_errors { </ins> return Err(ErrorHandled::Reported); }

<ins> // check-pass enum _Enum { A(), } type _E = _Enum; const fn _a() -> _Enum { _E::A() } const _A: _Enum = _a(); fn main() {} </ins>
Change:
In particular panics because of failing assert in For example:
Cc I think that assert doesn't make much sense if I'm interpreting correctly, though I'm surprised it hasn't been hit before...
The current implementation seems to incorrectly assume that unwinding is not in progress when entering . Not caught before, since std is usually used without debug assertions (it definitely happens in actually existing code, what is unusual is that I am using and hence hitting the assertion). There is a similar although a separate question if following should abort or not:
Yes, the second code snippet should definitely abort - we abort on the second live panic, independent of whether it's going to be caught.

Discussion:
); return if r == 0 { <del> debug_assert!(update_panic_count(0) == 0); </del> Ok(ManuallyDrop::into_inner(data.r)) } else { update_panic_count(-1); <del> debug_assert!(update_panic_count(0) == 0); </del> Err(mem::transmute(raw::TraitObject { data: any_data as *mut _, vtable: any_vtable as *mut _,

<ins> // Checks that catch_unwind can be used if unwinding is already in progress. // Used to fail when standard library had been compiled with debug assertions, // due to incorrect assumption that a current thread is not panicking when // entering the catch_unwind. // // run-pass // ignore-wasm       no panic support // ignore-emscripten no panic support use std::panic::catch_unwind; #[derive(Default)] struct Guard; impl Drop for Guard { fn drop(&mut self) { let _ = catch_unwind(|| {}); } } fn main() { let _ = catch_unwind(|| { let _guard = Guard::default(); panic!(); }); } </ins>
Change:
If we have an attribute macro whose input contains attributes on fields of a struct-expression, those attributes all seem to disappear before the macro is invoked. The following repro compiles successfully if #[repro::repro] is removed, but fails with "error[E0062]: field  specified more than once" if the macro is present even though it does nothing. <details<summaryHere is a script that reproduces the behavior as of rustc 1.42.0-nightly ( 2020-01-30)</summary</details<details<summaryHere is the input token stream as received by the proc macro</summary</detailscc
I have a fix in The bug was in pretty printing (usually the case in these types of bugs).

Discussion:
Consistent, &fields[..], |s, field| { <ins> s.print_outer_attributes(&field.attrs); </ins> s.ibox(INDENT_UNIT); if !field.is_shorthand { s.print_ident(field.ident);

<ins> // pp-exact fn main() { } struct C { field: u8, } #[allow()] const C: C = C{ #[cfg(debug_assertions)] field: 0, #[cfg(not (debug_assertions))] field: 1,}; </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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 compiler team prioritization.

Discussion:
<del> Subproject commit c0f39cfb466202a1dbe8368ca177848083dc34cb </del> <ins> Subproject commit ea85b4c7fb9826f72bd4ab743a703a34c75a40f0 </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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 compiler team prioritization.
Fix up at

Discussion:
<del> Subproject commit 83403581bb7a2156f4752fc2d0ceef4b3ec75554 </del> <ins> Subproject commit 75417e5a660096929aa10f1072a21d6662c9c0dc </ins>
Change:
The following code snippet demonstrating or-patterns crashes the nightly compiler on the Playground as of 2-2-2020. () I understand that or-patterns are incomplete feature, thus errors are expected. But I was told to anyway (cc: It's not convenient for me to test locally right now; is it possible to get a backtrace on the Playground?
You might want to throw this into your PR () as a test case.
Would appreciate clarification here: I don't believe pattern binding with or-patterns within function arguments () is semantically different from a pattern consisting of only the variable name (). However, it's semantically valid code, and can be used as a contrived example to demonstrate exhaustive pattern matching. Which is how I found this ICE in the first place.
It's semantically equivalent, but it results in different code-paths in the compiler. I'm quite sure that will fix this though as it seems more or less like a dupe of (but different enough that a test case should maybe be ). The MIR parts of or-patterns have simply not been implemented yet, but we're pretty close.

Discussion:
<ins> // check-pass #![feature(or_patterns)] enum MyEnum { FirstCase(u8), OtherCase(u16), } fn my_fn(x @ (MyEnum::FirstCase(_) | MyEnum::OtherCase(_)): MyEnum) {} fn main() { my_fn(MyEnum::FirstCase(0)); } </ins>
Change:
Problem returns invalid span data, particularly and are set to 0, though . This happens with a completly empty file. Tested on the following cargo version: Whilst on the stable version the returned span array is empty: Steps Now you can see invalid span in file. I've already created and formatted and files with the output of different cargo versions. Here are the crutial differences and Context
Moved to rust-lang/rust, where diagnostics live. Seems to be caused by , cc
additional info: The regression is also present on the older version of nightly rustc: This was the version where I initially spotted the issue, then updated and rechecked, but it was still present in .
Probably caused by
triage: P-high. Assigning to self.

Discussion:
.span_to_lines(parts[0].span) .expect("span_to_lines failed when emitting suggestion"); <del> assert!(!lines.lines.is_empty()); </del> <ins> assert!(!lines.lines.is_empty() || parts[0].span.is_dummy()); </ins> let line_start = sm.lookup_char_pos(parts[0].span.lo()).line; draw_col_separator_no_space(&mut buffer, 1, max_line_num_len + 1);

let bounding_span = Span::with_root_ctxt(lo, hi); // The different spans might belong to different contexts, if so ignore suggestion. let lines = sm.span_to_lines(bounding_span).ok()?; <del> assert!(!lines.lines.is_empty()); </del> <ins> assert!(!lines.lines.is_empty() || bounding_span.is_dummy()); </ins> // We can't splice anything if the source is unavailable. if !sm.ensure_source_file_source_present(lines.file.clone()) {

let sf = &lines.file; let mut prev_hi = sm.lookup_char_pos(bounding_span.lo()); prev_hi.col = CharPos::from_usize(0); <del> let mut prev_line = sf.get_line(lines.lines[0].line_index); </del> <ins> let mut prev_line = lines.lines.get(0).and_then(|line0| sf.get_line(line0.line_index)); </ins> let mut buf = String::new(); for part in &substitution.parts {

let (lo, hi) = self.is_valid_span(sp)?; assert!(hi.line >= lo.line); <ins> if sp.is_dummy() { return Ok(FileLines { file: lo.file, lines: Vec::new() }); } </ins> let mut lines = Vec::with_capacity(hi.line - lo.line + 1); // The span starts partway through the first line,

// and to the end of the line. Be careful because the line // numbers in Loc are 1-based, so we subtract 1 to get 0-based // lines. <ins> // // FIXME: now that we handle DUMMY_SP up above, we should consider // asserting that the line numbers here are all indeed 1-based. </ins> let hi_line = hi.line.saturating_sub(1); for line_index in lo.line.saturating_sub(1)..hi_line { let line_len = lo.file.get_line(line_index).map(|s| s.chars().count()).unwrap_or(0);