jiebi/CodeConvo huggingface dataset:
Code change:
When using zipped iterators in a certain section of code, I hit an ICE. I've attached the project source -- sorry I could not produce a minimum example though I tried. Also, it's closed source, though I own it so can choose to provide the snapshot. Symptoms: Normally using zipped iterators doesn't cause an ICE, but in this case it is consistent (clean build, using , and ). Not zipping the iterators, and using prevents the ICE from occurring. This code fails to compile: This code compiles: Compilation error message: : 1.39 (stable): 1.40 (nightly): Backtrace: <details<summary1.39 stable</summary</details<details<summary1.40 nightly</summary</detailsInvestigation: Steps to reproduce: and run Relevant source file: Interestingly, using on the iterator on the ICE-ing code allows it to compile: Also interestingly, using the version within without also causes the ICE, so it's not the zipping that's causing it, but rather something to do with the being a reference rather than an owned value.
Seems to be an issue with Crash on stable, beta, nightly
regression from stable-to-stable 38.0 "worked"
A reduction would be good :)
I'm on it.
You want a MCVE? I give you a MCVE! modify labels: -E-needs-mcve +E-needs-bisection
Reduced:
regression between ...
cc
is the one to blame .
triage: P-high. Removing nomination label.

Related discussion:
text: <ins> // #66353: ICE when trying to recover from incorrect associated type trait _Func<T> { fn func(_: Self); } trait _A { type AssocT; } fn main() { _Func::< <() as _A>::AssocT >::func(()); //~^ ERROR the trait bound `(): _A` is not satisfied //~| ERROR the trait bound `(): _Func<_>` is not satisfied } </ins>
Code change:
When using zipped iterators in a certain section of code, I hit an ICE. I've attached the project source -- sorry I could not produce a minimum example though I tried. Also, it's closed source, though I own it so can choose to provide the snapshot. Symptoms: Normally using zipped iterators doesn't cause an ICE, but in this case it is consistent (clean build, using , and ). Not zipping the iterators, and using prevents the ICE from occurring. This code fails to compile: This code compiles: Compilation error message: : 1.39 (stable): 1.40 (nightly): Backtrace: <details<summary1.39 stable</summary</details<details<summary1.40 nightly</summary</detailsInvestigation: Steps to reproduce: and run Relevant source file: Interestingly, using on the iterator on the ICE-ing code allows it to compile: Also interestingly, using the version within without also causes the ICE, so it's not the zipping that's causing it, but rather something to do with the being a reference rather than an owned value.
Seems to be an issue with Crash on stable, beta, nightly
regression from stable-to-stable 38.0 "worked"
A reduction would be good :)
I'm on it.
You want a MCVE? I give you a MCVE! modify labels: -E-needs-mcve +E-needs-bisection
Reduced:
regression between ...
cc
is the one to blame .
triage: P-high. Removing nomination label.

Related discussion:
text: <ins> error[E0277]: the trait bound `(): _A` is not satisfied --> $DIR/issue-66353.rs:12:14 | LL |     _Func::< <() as _A>::AssocT >::func(()); |              ^^^^^^^^^^^^^^^^^^ the trait `_A` is not implemented for `()` error[E0277]: the trait bound `(): _Func<_>` is not satisfied --> $DIR/issue-66353.rs:12:41 | LL |     fn func(_: Self); |     ----------------- required by `_Func::func` ... LL |     _Func::< <() as _A>::AssocT >::func(()); |                                         ^^ the trait `_Func<_>` is not implemented for `()` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>
Code change:
For example: This gives you a warning that should be snake case in the match arm. But at that point you don't really have much choice about it. Variable name warnings should be where the variable is named, and it isn't really named there. (Maybe there's some syntax like but who is going to bother with that?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please provide a working example without next time. It makes it easier to see what's going on here. Let's assume this one: You could instead write and have full control over the names of the binding and that's why the compiler is complaining. You are right in the way, that we should lint the original issue. I'm not sure how the the suggestion goes in terms of machine applicability and renaming of further instances of this variable. Let's see what the future will bring :)
Direct repro link: Current warning: Seems like a diagnostics fix to change the help to
We discussed this in the lang team meeting, and we agree with the proposal here. We shouldn't warn twice over the same field name; we should only warn about the definition, and not again when you match it. Note, in particular, that it seems like a relatively common pattern to disable these lints only in a module written by bindgen or otherwise written to match some external spec/API, but leave them enabled in the rest of your code. So, :+1: to not linting for field puns on field names that don't match the recommended style. (We should still lint when not punning, if you define a new local name that doesn't match the recommended style.)
Hi, I'd like to take this one. Just to make sure I'm understanding this right: We want to warn on identifier used to define the field name in the struct itself, and not on the match binding. Is that correct?
We definitely want to warn on the struct definition. My understanding is that we don't want to warn on the binding when you didn't actually write the binding ("for field puns"). So we don't warn on but would warn on (and definitely on ).
That makes a lot of sense. Thanks! claim
Right, exactly. I would suggest starting by writing some (failing) test cases for the desired behavior including warning output. I would be happy to review that step and confirm.
I've put up a PR with the failing test case. How's this look? Are there any other cases I should test?

Related discussion:
text: } fn check_pat(&mut self, cx: &LateContext<'_, '_>, p: &hir::Pat<'_>) { <del> if let &PatKind::Binding(_, _, ident, _) = &p.kind { </del> <ins> if let &PatKind::Binding(_, hid, ident, _) = &p.kind { if let hir::Node::Pat(parent_pat) = cx.tcx.hir().get(cx.tcx.hir().get_parent_node(hid)) { if let PatKind::Struct(_, field_pats, _) = &parent_pat.kind { for field in field_pats.iter() { if field.ident != ident { // Only check if a new name has been introduced, to avoid warning // on both the struct definition and this pattern. self.check_snake_case(cx, "variable", &ident); } } return; } } </ins> self.check_snake_case(cx, "variable", &ident); } }
Code change:
This works; let's consider adding a test for it since it's a bit of a special case. Reported to be working in by
do you mind if I add this? My laptop is no longer broken ^^ so I can actually get some work done without disappearing for a week at a time. I put this in a file called and ran , is that about the right approach?
It is, but I'd recommend using to make it go faster. Also use to just test that file. Also, I'd rename the test to not suggest ... something like .
I ran about an hour ago and that worked fine (although it took a while ^^). However, since then I updated nightly and I'm now getting compile errors when building stage 1: What am I doing wrong? Full error: (cross posted from https://rust-)

Related discussion:
text: <ins> // check-pass #![feature(const_if_match)] enum E { A, B, C } const fn f(e: E) -> usize { match e { _ => 0 } } fn main() { const X: usize = f(E::C); assert_eq!(X, 0); assert_eq!(f(E::A), 0); } </ins>
Code change:
I'm trying to build my crate on nightly, and I'm getting a compiler panic. I bisected several nightly builds to try and narrow down when the problem started. The last known good nightly was , and the first failing was The panic also occurs in . The crates causing the panic are available here:
cc
triage: P-high, removing nomination label.
Minimal repro:
As some info, I've narrowed down the offending commit to –– most likely the changes in .

Related discussion:
text: variant_index: VariantIdx, dest: PlaceTy<'tcx, M::PointerTag>, ) -> InterpResult<'tcx> { <del> let variant_scalar = Scalar::from_u32(variant_index.as_u32()).into(); </del> <ins> // Layout computation excludes uninhabited variants from consideration // therefore there's no way to represent those variants in the given layout. if dest.layout.for_variant(self, variant_index).abi.is_uninhabited() { throw_ub!(Unreachable); } </ins> match dest.layout.variants { layout::Variants::Single { index } => { <del> if index != variant_index { throw_ub!(InvalidDiscriminant(variant_scalar)); } </del> <ins> assert_eq!(index, variant_index); </ins> } layout::Variants::Multiple { discr_kind: layout::DiscriminantKind::Tag,
Code change:
I'm trying to build my crate on nightly, and I'm getting a compiler panic. I bisected several nightly builds to try and narrow down when the problem started. The last known good nightly was , and the first failing was The panic also occurs in . The crates causing the panic are available here:
cc
triage: P-high, removing nomination label.
Minimal repro:
As some info, I've narrowed down the offending commit to –– most likely the changes in .

Related discussion:
text: discr_index, .. } => { <del> if !dest.layout.ty.variant_range(*self.tcx).unwrap().contains(&variant_index) { throw_ub!(InvalidDiscriminant(variant_scalar)); } </del> <ins> // No need to validate that the discriminant here because the // `TyLayout::for_variant()` call earlier already checks the variant is valid. </ins> let discr_val = dest.layout.ty.discriminant_for_variant(*self.tcx, variant_index).unwrap().val;
Code change:
I'm trying to build my crate on nightly, and I'm getting a compiler panic. I bisected several nightly builds to try and narrow down when the problem started. The last known good nightly was , and the first failing was The panic also occurs in . The crates causing the panic are available here:
cc
triage: P-high, removing nomination label.
Minimal repro:
As some info, I've narrowed down the offending commit to –– most likely the changes in .

Related discussion:
text: discr_index, .. } => { <del> if !variant_index.as_usize() < dest.layout.ty.ty_adt_def().unwrap().variants.len() { throw_ub!(InvalidDiscriminant(variant_scalar)); } </del> <ins> // No need to validate that the discriminant here because the // `TyLayout::for_variant()` call earlier already checks the variant is valid. </ins> if variant_index != dataful_variant { let variants_start = niche_variants.start().as_u32(); let variant_index_relative = variant_index.as_u32()
Code change:
I'm trying to build my crate on nightly, and I'm getting a compiler panic. I bisected several nightly builds to try and narrow down when the problem started. The last known good nightly was , and the first failing was The panic also occurs in . The crates causing the panic are available here:
cc
triage: P-high, removing nomination label.
Minimal repro:
As some info, I've narrowed down the offending commit to –– most likely the changes in .

Related discussion:
text: <ins> // build-pass // compile-flags: --crate-type lib // Regression test for ICE which occurred when const propagating an enum with three variants // one of which is uninhabited. pub enum ApiError {} #[allow(dead_code)] pub struct TokioError { b: bool, } pub enum Error { Api { source: ApiError, }, Ethereum, Tokio { source: TokioError, }, } struct Api; impl IntoError<Error> for Api { type Source = ApiError; fn into_error(self, error: Self::Source) -> Error { Error::Api { source: (|v| v)(error), } } } pub trait IntoError<E> { /// The underlying error type Source; /// Combine the information to produce the error fn into_error(self, source: Self::Source) -> E; } </ins>
Code change:
I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.

Related discussion:
text: <ins> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </ins>
Code change:
I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.

Related discussion:
text: <ins> // edition:2018 use std::sync::{Arc, Mutex}; pub async fn f(_: ()) {} pub async fn run() { let x: Arc<Mutex<()>> = unimplemented!(); f(*x.lock().unwrap()).await; } </ins>
Code change:
I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.

Related discussion:
text: <ins> // aux-build: issue_67893.rs // edition:2018 // dont-check-compiler-stderr // FIXME(#71222): Add above flag because of the difference of stderrs on some env. extern crate issue_67893; fn g(_: impl Send) {} fn main() { g(issue_67893::run()) //~^ ERROR: `std::sync::MutexGuard<'_, ()>` cannot be sent between threads safely } </ins>
Code change:
I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.

Related discussion:
text: <ins> #![feature(intrinsics)] extern "C" { pub static FOO: extern "rust-intrinsic" fn(); } fn main() { FOO() //~ ERROR: use of extern static is unsafe } </ins>
Code change:
I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.

Related discussion:
text: <ins> error[E0133]: use of extern static is unsafe and requires unsafe function or block --> $DIR/issue-28575.rs:8:5 | LL |     FOO() |     ^^^ use of extern static | = note: extern statics are not controlled by the Rust type system: invalid data, aliasing violations or data races will cause undefined behavior error: aborting due to previous error For more information about this error, try `rustc --explain E0133`. </ins>
Code change:
I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.

Related discussion:
text: <ins> pub static TEST_STR: &'static str = "Hello world"; </ins>
Code change:
I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.

Related discussion:
text: <ins> // aux-build: issue_24843.rs // check-pass extern crate issue_24843; static _TEST_STR_2: &'static str = &issue_24843::TEST_STR; fn main() {} </ins>
Code 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.

Related discussion:
text: "rand 0.7.0", "rustc-workspace-hack", "rustc_version", <ins> "serde", </ins> "shell-escape", "vergen", ]
Code 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.

Related discussion:
text: <del> Subproject commit a0ba079b6af0f8c07c33dd8af72a51c997e58967 </del> <ins> Subproject commit 048af409232fc2d7f8fbe5469080dc8bb702c498 </ins>
Code change:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.

Related discussion:
text: None => return Ok(()), }; <ins> // Render the replacements for each suggestion let suggestions = suggestion.splice_lines(&**sm); if suggestions.is_empty() { // Suggestions coming from macros can have malformed spans. This is a heavy handed // approach to avoid ICEs by ignoring the suggestion outright. return Ok(()); } </ins> let mut buffer = StyledBuffer::new(); // Render the suggestion message
Code change:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.

Related discussion:
text: Some(Style::HeaderMsg), ); <del> // Render the replacements for each suggestion let suggestions = suggestion.splice_lines(&**sm); </del> let mut row_num = 2; let mut notice_capitalization = false; for (complete, parts, only_capitalization) in suggestions.iter().take(MAX_SUGGESTIONS) {
Code change:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.

Related discussion:
text: let show_underline = !(parts.len() == 1 && parts[0].snippet.trim() == complete.trim()) && complete.lines().count() == 1; <del> let lines = sm.span_to_lines(parts[0].span).unwrap(); </del> <ins> let lines = sm .span_to_lines(parts[0].span) .expect("span_to_lines failed when emitting suggestion"); </ins> assert!(!lines.lines.is_empty());