jiebi/CodeConvo huggingface dataset:
Change:
I was playing with a dev server config and forgot to put python in , leading to a confusing error message: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: change src/tools/x to have a better error in this case. note you'll have to manually reinstall it once that's done; we don't currently have an upgrade path for that tool which is one of the reasons we're planning to use shell scripts in
claim
claim

Discussion:
} else if python2 { PYTHON2 } else { <del> // We would have returned early if we found that python is installed ... // maybe this should panic with an error instead? PYTHON </del> <ins> // Python was not found on path, so exit eprintln!("Unable to find python in your PATH. Please check it is installed."); process::exit(1); </ins> } }
Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected the length of the iterator. Instead, panic: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryMy first suspicion would be the sizehint() on the iterator. It also happens in no_std. </summary<pStacktrace: </p</details
This is pretty unfortunate. This type should not implement , but it has for a few stable versions now :( See also (the original tracking issue) and (the PR that it)
Nominating for discussion whether the stabilization should be reverted, the crater run should be expedited and perhaps beta-backported.
I would prefer stabilization to be reverted as there is additional book-keeping required to implement .
We discussed this briefly in the libs-api meeting last week. Reverting it seems okay, even though it's technically a breaking change. It seems like nothing relies on it, as they would have gotten panics anyway. The crater run seems to confirm that.
Thanks for getting the fix for this merged everybody.

Discussion:
} } #[stable(feature = "inherent_ascii_escape", since = "1.60.0")] <del> impl<'a> iter::ExactSizeIterator for EscapeAscii<'a> {} #[stable(feature = "inherent_ascii_escape", since = "1.60.0")] </del> impl<'a> iter::FusedIterator for EscapeAscii<'a> {} #[stable(feature = "inherent_ascii_escape", since = "1.60.0")] impl<'a> fmt::Display for EscapeAscii<'a> {
Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should inform the user that and are mutually exclusive and suggest the user remove the . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Discussion:
Applicability::MaybeIncorrect, ) .emit(); <ins> } else if self.eat_keyword(kw::Let) { let span = self.prev_token.span; self.struct_span_err(const_span.to(span), "`const` and `let` are mutually exclusive") .span_suggestion( const_span.to(span), "remove `let`", "const", Applicability::MaybeIncorrect, ) .emit(); </ins> } }

/// Parses a local variable declaration. fn parse_local(&mut self, attrs: AttrVec) -> PResult<'a, P<Local>> { let lo = self.prev_token.span; <ins> if self.token.is_keyword(kw::Const) && self.look_ahead(1, |t| t.is_ident()) { self.struct_span_err( lo.to(self.token.span), "`const` and `let` are mutually exclusive", ) .span_suggestion( lo.to(self.token.span), "remove `let`", "const", Applicability::MaybeIncorrect, ) .emit(); self.bump(); } </ins> let (pat, colon) = self.parse_pat_before_ty(None, RecoverComma::Yes, "`let` bindings")?; let (err, ty) = if colon {

<ins> // run-rustfix fn main() { const _FOO: i32 = 123; //~^ ERROR const` and `let` are mutually exclusive const _BAR: i32 = 123; //~^ ERROR `const` and `let` are mutually exclusive } </ins>

<ins> // run-rustfix fn main() { const let _FOO: i32 = 123; //~^ ERROR const` and `let` are mutually exclusive let const _BAR: i32 = 123; //~^ ERROR `const` and `let` are mutually exclusive } </ins>

<ins> error: `const` and `let` are mutually exclusive --> $DIR/issue-99910-const-let-mutually-exclusive.rs:4:5 | LL |     const let _FOO: i32 = 123; |     ^^^^^^^^^ help: remove `let`: `const` error: `const` and `let` are mutually exclusive --> $DIR/issue-99910-const-let-mutually-exclusive.rs:6:5 | LL |     let const _BAR: i32 = 123; |     ^^^^^^^^^ help: remove `let`: `const` error: aborting due to 2 previous errors </ins>
Change:
Recently I played with the newly stabilized (tracker for issue , stabilized in Rust 1.64 ) and found that in some cases it gives . Below is a minimal example. It compiles fine with or , but does not compile with . It also compiles if you replace with nested . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
Thank you for you report, but this is probably a duplicate of
Can confirm this no longer ICEs on most recent nightly:
label +E-needs-test
Yeah likely this was fixed by . I wonder if it's worth adding a test for this, or it can just be closed as a dupe of .
We just hit this during the Clippy sync in The offending code was this: Pulling the if line out of the chain fixed the issue, see , so this works:
your issue is different, can you file a bug for it? This issue does not reproduce any more on latest nightly, it should be closed (or a test for it before closure, but had tests already.
Hmm, I can do this, but I think that is actually the same issue. While the above reproducer might be fixed, the fix doesn't seem to generally apply. The above code produced the exact same ICE/error message as posted in this issue.
I think this might be some MIR optimization gone wrong, maybe caused by wrong codegen, but your issue requires optimizations to be turned on, it can't just be reproduced by . The original ICE was also reproducible by (as well as with -O, as well as with both params), I've just verified using . I would thus recommend you file a new issue, but your choice. Some additional info to your issue, this is a reproducer: Interestingly, the issue is a regression, as it didn't ICE on . Edit: I very much appreciate the notion of not wanting to file multiple issues, after all this very issue is a dupe, but the clippy bug is separate.
This isn't because of MIR opts, it only happens under because storage markers, which are needed to get this ICE, are only emitted in optimized builds.
is this storage markers emitting only in release a new feature? Because I can reproduce the ICE with the original reproducer from this issue's author, with and and no flag whatsoever.

Discussion:
<ins> // compile-flags: -Zvalidate-mir -C opt-level=3 // build-pass #![feature(let_chains)] struct TupleIter<T, I: Iterator<Item = T>> { inner: I, } impl<T, I: Iterator<Item = T>> Iterator for TupleIter<T, I> { type Item = (T, T, T); fn next(&mut self) -> Option<Self::Item> { let inner = &mut self.inner; if let Some(first) = inner.next() && let Some(second) = inner.next() && let Some(third) = inner.next() { Some((first, second, third)) } else { None } } } fn main() { let vec: Vec<u8> = Vec::new(); let mut tup_iter = TupleIter { inner: vec.into_iter(), }; tup_iter.next(); } </ins>
Change:
This code: compiles on stable but not on nightly. Error: I bisected it to and then refined it; reverting fixes the issue. This is the cause for
ping since you're the author of the commit
WG-prioritization assigning priority (). label -I-prioritize +P-critical
note: there's a fix in ready for review

Discussion:
continue; } <del> let missing = match source { PathSource::Trait(..) | PathSource::TraitItem(..) | PathSource::Type => true, </del> <ins> let node_ids = self.r.next_node_ids(expected_lifetimes); self.record_lifetime_res( segment_id, LifetimeRes::ElidedAnchor { start: node_ids.start, end: node_ids.end }, LifetimeElisionCandidate::Ignore, ); let inferred = match source { PathSource::Trait(..) | PathSource::TraitItem(..) | PathSource::Type => false, </ins> PathSource::Expr(..) | PathSource::Pat | PathSource::Struct <del> | PathSource::TupleStruct(..) => false, </del> <ins> | PathSource::TupleStruct(..) => true, </ins> }; <del> if !missing && !segment.has_generic_args { </del> <ins> if inferred { // Do not create a parameter for patterns and expressions: type checking can infer // the appropriate lifetime for us. for id in node_ids { self.record_lifetime_res( id, LifetimeRes::Infer, LifetimeElisionCandidate::Named, ); } </ins> continue; }

}; let ident = Ident::new(kw::UnderscoreLifetime, elided_lifetime_span); <del> let node_ids = self.r.next_node_ids(expected_lifetimes); self.record_lifetime_res( segment_id, LifetimeRes::ElidedAnchor { start: node_ids.start, end: node_ids.end }, LifetimeElisionCandidate::Ignore, ); if !missing { // Do not create a parameter for patterns and expressions. for id in node_ids { self.record_lifetime_res( id, LifetimeRes::Infer, LifetimeElisionCandidate::Named, ); } continue; } </del> let missing_lifetime = MissingLifetime { id: node_ids.start, span: elided_lifetime_span,

<ins> // check-pass struct Sqlite {} trait HasArguments<'q> { type Arguments; } impl<'q> HasArguments<'q> for Sqlite { type Arguments = std::marker::PhantomData<&'q ()>; } fn foo() { let _ = <Sqlite as HasArguments>::Arguments::default(); } fn main() {} </ins>