jiebi/CodeConvo huggingface dataset:
Change:
}; } } <ins> fn check_pat_post(&mut self, _cx: &EarlyContext<'_>, pat: &ast::Pat) { if let Some(node_id) = self.node_id { if pat.id == node_id { self.node_id = None } } } </ins> } declare_lint! {

Discussion:
The parameter is a hack (to fix ) that should be refactored. The idea is that the state should be contained in instead. This should be straightforward to fix. the parameter from (You'll also need to update the signature of in . a method with an identical signature below it. the condition from an early lint pass for at the end. a field to in (Look at for an example of a lint with fields.) You'll also need to initialise it with here: should be replaced with an assignment of the new field in to : should be early-exited if the field is . a implementation to and reset the field to if the pattern ID matches the field ID. sure the UI tests still pass with no changes.
hi I'm happy to take care of this one if it's not taken already.
go ahead! Let me know if you have any questions or problems with the implementation! :)
Change:
<ins> // check-pass const _: fn(&String) = |s| { &*s as &str; }; fn main() {} </ins>

Discussion:
Compiles in stable rust (1.64) as well as in beta. But in nightly, we get this compilation error: playground link: 64, and beta current nightly
searched nightlies: from nightly-2022-08-01 to nightly-2022-10-24 regressed nightly: nightly-2022-09-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Seems like closures pick the constness of their parent when they should always be notconst
Change:
| LL | #![deny(unused_qualifications)] |         ^^^^^^^^^^^^^^^^^^^^^ <ins> help: replace it with the unqualified path | LL |     bar(); |     ~~~ </ins> error: aborting due to previous error

Discussion:
In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .
Change:
} Entry::Occupied(mut entry) => { debug!(" - composing on top of {:?}", entry.get()); <del> match (&entry.get()[..], &adj[..]) { // Applying any adjustment on top of a NeverToAny // is a valid NeverToAny adjustment, because it can't // be reached. (&[Adjustment { kind: Adjust::NeverToAny, .. }], _) => return, </del> <ins> match (&mut entry.get_mut()[..], &adj[..]) { </ins> ( <del> &[ </del> <ins> [Adjustment { kind: Adjust::NeverToAny, target }], &[.., Adjustment { target: new_target, .. }], ) => { // NeverToAny coercion can target any type, so instead of adding a new // adjustment on top we can change the target. // // This is required for things like `a == a` (where `a: !`) to produce // valid MIR -- we need borrow adjustment from things like `==` to change // the type to `&!` (or `&()` depending on the fallback). This might be // relevant even in unreachable code. *target = new_target; } ( &mut [ </ins> Adjustment { kind: Adjust::Deref(_), .. }, Adjustment { kind: Adjust::Borrow(AutoBorrow::Ref(..)), .. }, ],

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: broken MIR in DefId(0:20 ~ o[fbbd]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move 23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !): NoSolution', 'error: internal compiler error: broken MIR in DefId(0:20 ~ o[fbbd]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move 23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !): NoSolution' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: error: internal compiler error: broken MIR in DefId(0:20 ~ mvce[954a]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move _23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !

): NoSolution --
Regression in nightly-2023-05-23 commit[0] 2023-05-21: Auto merge of - MU001999:fix/issue-, r=cjgillot commit[1] 2023-05-21: Auto merge of - Zoxc:query-structs-trim, r=cjgillot commit[2] 2023-05-22: Auto merge of - lukas-code:strike, r=notriddle commit[3] 2023-05-22: Auto merge of - the8472:filter-map-chunk, r=thomcc commit[4] 2023-05-22: Auto merge of - matthiaskrgr:rollup-qd4b2vu, r=matthiaskrgr commit[5] 2023-05-22: Auto merge of - Jules-Bertholet:document-pin-layout, r=thomcc commit[6] 2023-05-22: Auto merge of - compiler-errors:triple-check, r=Nilstrieb commit[7] 2023-05-22: Auto merge of - marc0246:arc-new-uninit-bloat, r=thomcc commit[8] 2023-05-22: Auto merge of - lcnr:recursion-depth, r=matthewjasper commit[9] 2023-05-22: Auto merge of - Dylan-DPC:rollup-7jqydzg, r=Dylan-DPC ERROR: no CI builds available between and within last 167 days cc
Minimized:
Minimized even more: (I independently found the same bug while running crater with the fallback being )
Change:
type AssocAlias = Priv3; } <del> impl <Priv as PrivTr>::AssocAlias { //~ ERROR no base type found for inherent implementation </del> <ins> impl <Priv as PrivTr>::AssocAlias { //~^ ERROR no nominal type found for inherent implementation </ins> pub fn f(arg: Priv) {} // OK } }

Discussion:
] To : This should probably use the covered/local terminology from instead of "base type" to avoid the problematic overlap with subtyping/inheritance terminology.
] ] ] (Not really [C-bug], but it was the closest of the template options.)
Just fyi, you can do modify labels to -C-bug +A-diagnostics +C-enhancement +D-newcomer-roadblock which will let you apply most labels yourself. .
Error: Label D-newcomer-roadblock can only be set by Rust team members Please let know if you're having trouble with this bot.
... Oh, unless that happens.
A second attempt :stuckouttongue: modify labels to -C-bug +A-diagnostics +C-enhancement
In the reference, we use the term "nominal type". The error code explanation should also mention unions and trait objects ( is valid). If the person use or , it should also hint at removing the reference and putting them on in the associated items. Not sure if I should open a new issue for that one or not though.
Change:
} } <ins> #[stable(feature = "str_parse_error2", since = "1.8.0")] impl Error for string::ParseError { fn description(&self) -> &str { match *self {} } } </ins> // copied from any.rs impl Error + 'static { /// Returns true if the boxed type is the same as `T`

Discussion:
subj
Tagging as as should be a pretty good first bug to tackle for libstd!
Going to give this a shot! One question, given that is sort of a non-error (at least according to ), will returning/writing "parse error" be enough to satisfy and ?
ok! Yeah it should be fine to just ensure that something semi-reasonable comes out, it's more likely the case that just having these traits implemented is useful rather than ensuring the implementations themselves are useful :)
Since it's a void enum, you can use the same implementation as clone does in fact: It handles the enum exhaustively (as match forces you to) and makes sure all possible cases (zero cases) are handled. !
PR is up!
Change:
/// /// Don't read this flag directly, call `is_tainted_by_errors()` /// and `set_tainted_by_errors()`. <del> tainted_by_errors_flag: Cell<bool>, </del> <ins> tainted_by_errors: Cell<Option<ErrorGuaranteed>>, </ins> /// Track how many errors were reported when this infcx is created. /// If the number of errors increases, that's also a sign (line /// `tainted_by_errors`) to avoid reporting certain kinds of errors. <del> // FIXME(matthewjasper) Merge into `tainted_by_errors_flag` </del> <ins> // FIXME(matthewjasper) Merge into `tainted_by_errors` </ins> err_count_on_creation: usize, /// This flag is true while there is an active snapshot.

Discussion:
should be to guarantee that we emit an error when that flag is set. This is already done for of other types in rustc. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
renamed to to keep consistent.
Change:
<ins> // Regression test for #108072: do not ICE upon unmet trait alias constraint #![feature(trait_alias)] trait IteratorAlias = Iterator; fn f(_: impl IteratorAlias) {} fn main() { f(()) //~ `()` is not an iterator } </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-01-01 to nightly-2023-02-15 regressed nightly: nightly-2023-02-07 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsOf that rollup, looks most likely responsible to me. cc
claim
Ah, I had assumed that was infallible (at least in this context), but apparently not. So prior to calling this, the function should verify that it has the right kind, and if not, bail out (). Ideally it would resolve the trait alias too, but there's enough existing corner-cases which aren't handled that it isn't a big deal.
Actually, I think the problem arises earlier, when building derived obligations for trait aliases: they shouldn't be s at all. I have a fix, about to push.
Change:
| LL | pub const async fn x() {} |           ^^^^^ expected identifier, found keyword <del> | help: you can escape reserved keywords to use them as identifiers | LL | pub const r#async fn x() {} |           ^^^^^^^ </del> error: expected `:`, found keyword `fn` --> $DIR/no-const-async.rs:5:17

Discussion:
Right now the raw ident suggestion when using a reserved keyword somewhere where it is not allowed is context free, leading to misleading output: The parser should perform some lookahead to see if it could actually continue parsing if a raw identifier had been supplied in its place and if so, only then suggest raw idents.
Or we shouldn't suggest using raw identifiers if we cannot do that easily and reliably.
Change:
.label = declared `#[non_exhaustive]` here .help = consider a manual implementation of `Default` <ins> builtin_macros_non_generic_pointee = the `#[pointee]` attribute may only be used on generic parameters </ins> builtin_macros_non_unit_default = the `#[default]` attribute may only be used on unit enum variants .help = consider a manual implementation of `Default`

Discussion:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.
Change:
Reloc: RelocMode, Level: CodeGenOptLevel, EnableSegstk: bool, <del> UseSoftFP: bool) -> TargetMachineRef; </del> <ins> UseSoftFP: bool, NoFramePointerElim: bool) -> TargetMachineRef; </ins> pub fn LLVMRustDisposeTargetMachine(T: TargetMachineRef); pub fn LLVMRustAddAnalysisPasses(T: TargetMachineRef, PM: PassManagerRef,

Discussion:
We currently build C++ code and Rust with frame pointers on, though we don't actually use them for anything (intended for GC). This is overhead that C and C++ don't usually have so it would be nice to turn on elimination.
I think we'll need them for gc, fwiw
on Linux x86_64 we should be using the DWARFv3 Call Frame Information for walking the stack, although I have no idea if we're emitting it correctly right now (likely on OS X and FreeBSD too). We might be, because gdb uses it and seems to work.
We'll leave it off until we have solutions for GC, which will probably end up being platform specific. libunwind should make it easy on linux and freebsd.
Reopening because this caused a regression in , so reverted in
Change:
// Check call signature compatibility. // Normally, this shouldn't be required, but trait normalization failure can create a // validation ICE. <del> let terminator = caller_body[callsite.block].terminator.as_ref().unwrap(); let TerminatorKind::Call { args, destination, .. } = &terminator.kind else { bug!() }; let destination_ty = destination.ty(&caller_body.local_decls, self.tcx).ty; </del> let output_type = callee_body.return_ty(); if !util::is_subtype(self.tcx, self.param_env, output_type, destination_ty) { trace!(?output_type, ?destination_ty);

Discussion:
Inlining introduces unsized temporaries. This is problematic since unsized temporaries fail to uphold alignment requirements as described in . For example:
The unsized locals alignment issue itself was fixed in .
Change:
<ins> //@ check-pass //@ edition: 2021 // Make sure that we infer the args of an async closure even if it's passed to // a function that requires the async closure implement `Fn*` but does *not* have // a `Future` bound on the return type. #![feature(async_closure)] use std::future::Future; trait TryStream { type Ok; type Err; } trait TryFuture { type Ok; type Err; } impl<F, T, E> TryFuture for F where F: Future<Output = Result<T, E>> { type Ok = T; type Err = E; } trait TryStreamExt: TryStream { fn try_for_each<F, Fut>(&self, f: F) where F: FnMut(Self::Ok) -> Fut, Fut: TryFuture<Ok = (), Err = Self::Err>; } impl<S> TryStreamExt for S where S: TryStream { fn try_for_each<F, Fut>(&self, f: F) where F: FnMut(Self::Ok) -> Fut, Fut: TryFuture<Ok = (), Err = Self::Err>, { } } fn test(stream: impl TryStream<Ok = &'static str, Err = ()>) { stream.try_for_each(async |s| { s.trim(); // Make sure we know the type of `s` at this point. Ok(()) }); } fn main() {} </ins>

Discussion:
I'm writing this as a continuation of While the problem from first message in issue seems to be fixed, there are still cases when this fails. One of examples is when using instead of , when closure is expected to return : I expected to see this happen: All options used to work in past versions of rust Instead, this happened: Without explicit type hint it fails It most recently worked on: Not 100% sure, some explanations have been made in original issue
This is because the signature of  is: We only extract an async closure bound from cases where there is bound on the trait, which is not. There isn't even a supertrait bound that constrains the output type. I also do not expect this to ever be fixed, because that would require overly complicating the closure signature inference algorithm in ways that make me quite uncomfortable[^1][^2]. The correct solution is to rework the futures crate to have first-class async closure support, so for now I'd recommend just ascribing your type names. Sorry! [^1]: Firstly, this would break if another blanket implementation for were ever . [^2]: Secondly, the combinator shouldn't really be using bounds either -- it should be using bounds.
Alternatively, would fix this when paired with a slight adjustment to the closure signature inference that I'd be happy to make, but it seems like that PR is blocked.
Change:
use rustc_infer::infer::error_reporting::TypeAnnotationNeeded::E0282; use rustc_middle::ty::adjustment::{Adjust, Adjustment, PointerCoercion}; use rustc_middle::ty::fold::{TypeFoldable, TypeFolder, TypeSuperFoldable}; <del> use rustc_middle::ty::visit::{TypeSuperVisitable, TypeVisitable, TypeVisitableExt}; </del> <ins> use rustc_middle::ty::visit::TypeVisitableExt; </ins> use rustc_middle::ty::{self, Ty, TyCtxt}; use rustc_span::symbol::sym; use rustc_span::Span; use std::mem; <del> use std::ops::ControlFlow; </del> /////////////////////////////////////////////////////////////////////////// // Entry point

Discussion:
<!-- 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 to see this happen: compile error that said the return type is wrong. Instead, this happened: compiled without error <!-- 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. --:
cc

edit: minimized see for more details <!-- 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 to see this happen: Compilation should fail, because different generator types should be generated by calling , meaning and should not share the same type . Instead, compilation passes, and occurs during runtime: More context: <!-- 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<summaryNo Backtrace from running it</summary<p</p</details
label +F-typealiasimpl_trait +I-unsound +T-compiler
Only possible with unstable feature label -I-prioritize
it would be good to have an example which does not depend on external crates or macros here.
slightly minimized completely minimized: + incorrectly ignoring recursive definitions, writing a clean MVCE rn
constrains to , which gets ignored because of I am not totally sure how this all interacts, would have to look at the code, but it feels like the same root cause as
Change:
<ins> // edition: 2021 use std::{ future::Future, pin::Pin, task::{Context, Poll, Waker}, }; pub struct StructAsync<F: Fn() -> Pin<Box<dyn Future<Output = ()>>>> { pub callback: F, } impl<F> Future for StructAsync<F> where F: Fn() -> Pin<Box<dyn Future<Output = ()>>>, { type Output = (); fn poll(self: Pin<&mut Self>, _cx: &mut Context<'_>) -> Poll<Self::Output> { Poll::Pending } } async fn callback() {} struct Runtime; fn waker() -> &'static Waker { todo!() } impl Runtime { #[track_caller] pub fn block_on<F: Future>(&self, mut future: F) -> F::Output { loop { unsafe { Pin::new_unchecked(&mut future).poll(&mut Context::from_waker(waker())); } } } } fn main() { Runtime.block_on(async { StructAsync { callback }.await; //~^ ERROR expected `fn() -> impl Future<Output = ()> {callback}` to be a fn item that returns `Pin<Box<(dyn Future<Output = ()> + 'static)>>`, but it returns `impl Future<Output = ()>` //~| ERROR expected `fn() -> impl Future<Output = ()> {callback}` to be a fn item that returns `Pin<Box<(dyn Future<Output = ()> + 'static)>>`, but it returns `impl Future<Output = ()>` //~| ERROR expected `fn() -> impl Future<Output = ()> {callback}` to be a fn item that returns `Pin<Box<(dyn Future<Output = ()> + 'static)>>`, but it returns `impl Future<Output = ()>` }); } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Hello, I was trying differents things with Future and callbacks - to be more precise, I am trying to store an asynchronous callback inside an asynchronous struct. In my attempts, I found an unexpected compiler crash - I have taken the care to create a minimal reproducible example, which you can see, and test for yourself - note that the crash occurs both on the latest "stable" and "nightly" versions: <!-- 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<summary<strongBacktrace</strong</summary<p</p</details<!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Just to add this also ICEs on current latest beta version: 1.62.0-beta.7 (2022-06-26 )
And to further add, it does not ICE on stable. label: +regression-from-stable-to-beta
Apologies, as mentioned in the OP it does ICE on stable too (but, at least on the Playground, only when running not just building; same as for other channels). label: -I-prioritize -regression-from-stable-to-beta
This no longer ICEs
claim For the test
Change:
// us to improve in typeck so we do that now. match tcx.sess.diagnostic().steal_diagnostic(span, StashKey::ItemNoType) { Some(mut err) => { <del> // The parser provided a sub-optimal `HasPlaceholders` suggestion for the type. // We are typeck and have the real type, so remove that and suggest the actual type. err.suggestions.clear(); // Suggesting unnameable types won't help. let mut mk_nameable = MakeNameable::new(tcx); let ty = mk_nameable.fold_ty(ty); let sugg_ty = if mk_nameable.success { Some(ty) } else { None }; if let Some(sugg_ty) = sugg_ty { err.span_suggestion( span, &format!("provide a type for the {item}", item = kind), format!("{}: {}", item_ident, sugg_ty), Applicability::MachineApplicable, ); } else { err.span_note( tcx.hir().body(body_id).value.span, &format!("however, the inferred type `{}` cannot be named", ty.to_string()), ); </del> <ins> if !ty.references_error() { // The parser provided a sub-optimal `HasPlaceholders` suggestion for the type. // We are typeck and have the real type, so remove that and suggest the actual type. err.suggestions.clear(); // Suggesting unnameable types won't help. let mut mk_nameable = MakeNameable::new(tcx); let ty = mk_nameable.fold_ty(ty); let sugg_ty = if mk_nameable.success { Some(ty) } else { None }; if let Some(sugg_ty) = sugg_ty { err.span_suggestion( span, &format!("provide a type for the {item}", item = kind), format!("{}: {}", item_ident, sugg_ty), Applicability::MachineApplicable, ); } else { err.span_note( tcx.hir().body(body_id).value.span, &format!("however, the inferred type `{}` cannot be named", ty.to_string()), ); } </ins> } <del> err.emit_unless(ty.references_error()); </del> <ins> err.emit(); </ins> } None => { let mut diag = bad_placeholder_type(tcx, vec![span], kind);

Discussion:
Reproducible with stable and nightly compilers. : : Maybe this is a duplicated of but I'm not sure as the example there is more complex. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.52.0. The error in 1.51.0 wasn't so great either though, but at least it didn't ICE:
Regression in nightly-2021-03-08 (too long ago to get build artifacts per commit). That's the commit range .... Possibly related to an interaction between (which seems to have landed in that commit range) and dtorck?
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high