jiebi/CodeConvo huggingface dataset:
Code change:
); err } <del> infer::ReborrowUpvar(span, ref upvar_id) => { let var_name = self.tcx.hir().name(upvar_id.var_path.hir_id); let mut err = struct_span_err!( self.tcx.sess, span, E0313, "lifetime of borrowed pointer outlives lifetime of captured variable `{}`...", var_name ); note_and_explain_region( self.tcx, &mut err, "...the borrowed pointer is valid for ", sub, "...", None, ); note_and_explain_region( self.tcx, &mut err, &format!("...but `{}` is only valid for ", var_name), sup, "", None, ); err } </del> infer::RelateObjectBound(span) => { let mut err = struct_span_err!( self.tcx.sess,

Related discussion:
text: This issue is a proposal for the deprecation of error code . I opened a PR () as part of an effort to add long error explanations for error codes that didn't have one (). I chose and for my erroneous code example, I used the example from . I quickly realized, through running the example and other code that would also raise and through the CI failure message, that was not being raised. I went back to consult the issue I received the original code example from and noticed comments about not occurring anymore with . The issue was eventually labeled with . But, looking at the current contents of the file, can still be emitted even while it isn't: also doesn't have any UI tests as it is part of the error codes in . Since , is no longer actually emitted (although it is in code that it could) thanks to , I believe it should be deprecated. I would be happy to help deprecate the error code, if it is decided that it should happen. I would just need to know the proper steps to take to deprecate an error code. If there are reasons for why it is still an error code, I would love to be enlightened. claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If is not emitted anymore then it can be removed immediately. A crater run can also be done to ensure that this is the case. I'm also happy to do this if you want.
Sure, that sounds good.
Sorry just for clarification, do you want me to do the PR or you?
Code change:
self.sess.gated_spans.gate(sym::const_extern_fn, lo.to(self.token.span)); } let ext = self.parse_extern()?; <del> self.bump(); // `fn` </del> <ins> self.expect_keyword(kw::Fn)?; </ins> let header = FnHeader { unsafety,

Related discussion:
text: The following program compiles, and prints :
As pointed out by on discord , this also works on stable:
Regression introduced in 1.40.0, specifically this line:
I have a fix in
Code change:
fn collect_attr_proc_macro(&mut self, item: &'a ast::Item) { if self.in_root && item.vis.node.is_pub() { <del> self.attr_macros.push(ProcMacroDef { </del> <ins> self.macros.push(ProcMacro::Def(ProcMacroDef { </ins> span: item.span, function_name: item.ident, <del> }); </del> <ins> def_type: ProcMacroDefType::Attr })); </ins> } else { let msg = if !self.in_root { "functions tagged with `#[proc_macro_attribute]` must 

Related discussion:
text: The PR improved the situation about documenting proc macros. Thanks for that! However, I noticed a bug with it. I'm using . Running results in this: ! Looks like a simple typo or off-by-one or something like that bug. When using only and not s, everything looks good to me. CC
Oh, and also, running prints: Not sure if this warning is expected there. And not sure if related to this bug.
This is a consequence of the fact that has not yet been merged. Once it gets merged, and rust updates its Cargo submodule, this issue should go away.
It turns out that this issue was unrelated. I've opened a PR to fix it.
I see. Thanks for your work on this :)
Code change:
<ins> error: generic parameters may not be used in const operations --> $DIR/size-of-t.rs:7:30 | LL |     let _arr: [u8; size_of::<T>()]; |                              ^ cannot perform const operation using `T` | = note: type parameters may not be used in const expressions = help: use `#![feature(generic_const_exprs)]` to allow generic const expressions error: aborting due to previous error </ins>

Related discussion:
text: Example: Results in the following error: of course, is by default unless you say , so the error and the suggestion are clearly wrong. And if you do say explicitly, you get Note being suggested, which is ~not even valid syntax~ apparently valid syntax, but not something you would write. I expected to see this happen: Either this compiles cleanly Or the compiler emits a different error that makes sense <!-- 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. --: (Seems to happen on nightly too.) </details
Duplicate of
Reopening to track the error message, which is not tracked by . is just wrong.
Code change:
RelateParamBound(a, ..) => a, RelateRegionParamBound(a) => a, Reborrow(a) => a, <del> ReborrowUpvar(a, _) => a, </del> DataBorrowed(_, a) => a, ReferenceOutlivesReferent(_, a) => a, CompareImplItemObligation { span, .. } => span,

Related discussion:
text: This issue is a proposal for the deprecation of error code . I opened a PR () as part of an effort to add long error explanations for error codes that didn't have one (). I chose and for my erroneous code example, I used the example from . I quickly realized, through running the example and other code that would also raise and through the CI failure message, that was not being raised. I went back to consult the issue I received the original code example from and noticed comments about not occurring anymore with . The issue was eventually labeled with . But, looking at the current contents of the file, can still be emitted even while it isn't: also doesn't have any UI tests as it is part of the error codes in . Since , is no longer actually emitted (although it is in code that it could) thanks to , I believe it should be deprecated. I would be happy to help deprecate the error code, if it is decided that it should happen. I would just need to know the proper steps to take to deprecate an error code. If there are reasons for why it is still an error code, I would love to be enlightened. claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If is not emitted anymore then it can be removed immediately. A crater run can also be done to ensure that this is the case. I'm also happy to do this if you want.
Sure, that sounds good.
Sorry just for clarification, do you want me to do the PR or you?
Code change:
} } <ins> // This is required by the compiler to exist (e.g., it's a lang item), but it's // never actually called by the compiler.  Emscripten EH doesn't use a // personality function at all, it instead uses __cxa_find_matching_catch. // Wasm error handling would use __gxx_personality_wasm0. </ins> #[lang = "eh_personality"] unsafe extern "C" fn rust_eh_personality( <del> version: c_int, actions: uw::_Unwind_Action, exception_class: uw::_Unwind_Exception_Class, exception_object: *mut uw::_Unwind_Exception, context: *mut uw::_Unwind_Context, </del> <ins> _version: c_int, _actions: uw::_Unwind_Action, _exception_class: uw::_Unwind_Exception_Class, _exception_object: *mut uw::_Unwind_Exception, _context: *mut uw::_Unwind_Context, </ins> ) -> uw::_Unwind_Reason_Code { <del> __gxx_personality_v0(version, actions, exception_class, exception_object, context) </del> <ins> core::intrinsics::abort() </ins> } extern "C" {

Related discussion:
text: <!-- 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: Compiling with , after the emsdk is activated and emcc works, to compile properly Instead, this happened: Prints this error: I've tried adding to no avail <!-- 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<summaryBacktrace</summary<p</p</details
runs successfully
Also is broken on ubuntu with the same error message (at least windows subsystem for linux)
rustc 1.53.0-nightly ( 2021-04-24) emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 2.0.12 () Here's some info I gathered: Rust tries to . I think Rust is assuming that this symbol comes from emscripten. emscripten has a : libc++abi.a: emscripten exceptions: this is what rustc is trying to use; libc++abi-noexcept.a: no exceptions: does not compile libc++abi-except.a: wasm exceptions: experimental; in emscripten's repo shows that was never compiled into libc++abi.a by This commit looks suspicious: Prior to emscripten SDK version 2.0.10, I think has been and never did anything. Rust probably shouldn't be calling a stubbed function. seems untested if you ask me because I don't know how it could ever have worked. I successfully compiled hello world with emscripten SDK version 2.0.9. That version still has the stub.
label I-prioritize T-compiler O-wasm
thanks for the analysis. Assigning priority as discussed in the of the Prioritization Working Group. Let's find someone who can have a look at this. label -I-prioritize +P-high +I-nominated
I recall with the LLVM 11 upgrade, the compat notes mentioned which version of Emscripten to use when compiling with the target.
Code change:
} } <ins> // This is required by the compiler to exist (e.g., it's a lang item), but it's // never actually called by the compiler.  Emscripten EH doesn't use a // personality function at all, it instead uses __cxa_find_matching_catch. // Wasm error handling would use __gxx_personality_wasm0. </ins> #[lang = "eh_personality"] unsafe extern "C" fn rust_eh_personality( <del> version: c_int, actions: uw::_Unwind_Action, exception_class: uw::_Unwind_Exception_Class, exception_object: *mut uw::_Unwind_Exception, context: *mut uw::_Unwind_Context, </del> <ins> _version: c_int, _actions: uw::_Unwind_Action, _exception_class: uw::_Unwind_Exception_Class, _exception_object: *mut uw::_Unwind_Exception, _context: *mut uw::_Unwind_Context, </ins> ) -> uw::_Unwind_Reason_Code { <del> __gxx_personality_v0(version, actions, exception_class, exception_object, context) </del> <ins> core::intrinsics::abort() </ins> } extern "C" {

Related discussion:
text: Once this bug is resolved, can we add a similar note for the releases that upgrade Rust to LLVM 12?
As mentioned the panic=unwind strategy is broken on wasm32-unknown-emscripten. I recommend to switch default to panic=abort. Note that also rust std lib has to be rebuilt with panic=abort to fix the undefined symbol errors. Testing on my side showed that the problem could be fixed by changing TargetOptions on line 38 to "panicstrategy: PanicStrategy::Abort," in file. Unfortunatelly I do not have experience in preparing pull request and have no capacity to get into it now.
This issue can be solved by setting the env var which will override any flags passed to emcc. See this comment - Passing these flags using the won't work, as they are not passed to the linker. I received this error in two places, one for symbol and one for , hence the flag.
Reported this on Emscripten:
Code change:
scope 1 { debug self => _4;                // in scope 1 at $SRC_DIR/liballoc/boxed.rs:LL:COL let mut _5: &mut T;              // in scope 1 at $DIR/issue-58867-inline-as-ref-as-mut.rs:8:5: 8:15 <ins> let mut _6: &mut T;              // in scope 1 at $DIR/issue-58867-inline-as-ref-as-mut.rs:8:5: 8:15 </ins> } bb0: {

Related discussion:
text: Since InstCombine can now introduce where there was none before, without checking that the value is in fact not used afterwards. This may cause a value to be marked as uninitialized by the dataflow, but still be used in that uninitialized state. If InstCombine ran before the generator transform this would be acutely unsound and could probably be exploited directly, but other than that transform I don't think we rely on this property yet. This impacts , which does run after InstCombine and relies on the dataflow. I've observed this on , where it produces this diff: The second use of occurs despite the first move deinitializing the local. cc
Maybe we should stop making instcombine convert to ? This could be done in the pre-codegen cleanups, but for MIR it is wrong to use or on such values in general. Alternatively instcombine needs to start using dataflow to only insert moves when the site is the last use of the local.
Code change:
<ins> error[E0425]: cannot find value `a` in this scope --> $DIR/issue-92100.rs:5:10 | LL |         [a.., a] => {} |          ^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>

Related discussion:
text: <!-- 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. --error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.57.0 ( 2021-11-29) running on x8664-unknown-linux-gnu note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type bin note: some of the compiler flags provided by cargo are hidden query stack during panic: end of query stack <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
reduced:
Minimized this a tiny bit further, and I have a detailed explanation why this occurs: So this bug first starts going wrong in late resolution. Specifically, , we define the as a binding when we see the second element (ident subpattern) of the slice pattern, and then bind it later when we walk thru the (expression!) in the first slice pattern element. Essentially, since we treat as being defined here: and then resolve that as the path for we reach a situation where we expect a variable to have been defined before it has been lowered in HIR, which leads to the ICE later on, since we expect to have lowered that path element.
Wonder how difficult it would be to make have subpatterns instead of subexpressions... edit: wouldn't help, see below..
Actually, I don't think fixing this just for ranges is sufficient. I can reproduce this same issue with this: Maybe I can just delay this panic as a span bug, since we're always gonna error out anyways. I think I would ideally like to fix this by making sure we separate bindings in patterns from affecting resolution for expressions in patterns. edit: Ended up fixing it the right way.
claim
Code change:
let mut param_env = obligation.param_env; fresh_trait_pred = fresh_trait_pred.map_bound(|mut pred| { <del> param_env = param_env.with_constness(pred.constness.and(param_env.constness())); </del> <ins> pred.remap_constness(self.tcx(), &mut param_env); </ins> pred });

Related discussion:
text: <!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: print (from Debug impl) Instead, this happened: E0277, trait impl not found This was found by CI in the Ruffle Project: The issue is caused by the effective anti-bound of Drop, introduced by the manual impl of the trait, as well as the PR which introduced bounds for a number of functions in . It most recently worked on: rustc 1.59.0-nightly ( 2021-12-18) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc
Code change:
// the `type_of` of the trait's associated item. If we're using the old lowering // strategy, then just reinterpret the associated type like an opaque :^) let default_ty = if self.tcx.lower_impl_trait_in_trait_to_assoc_ty() { <del> self .tcx .type_of(alias_ty.def_id) .subst(self.tcx, alias_ty.substs) </del> <ins> self.tcx.type_of(shifted_alias_ty.def_id).subst(self.tcx, shifted_alias_ty.substs) </ins> } else { <del> self.tcx.mk_alias(ty::Opaque, alias_ty) </del> <ins> self.tcx.mk_alias(ty::Opaque, shifted_alias_ty) </ins> }; self.predicates.push( ty::Binder::bind_with_vars( <del> ty::ProjectionPredicate { projection_ty: alias_ty, term: default_ty.into(), }, </del> <ins> ty::ProjectionPredicate { projection_ty: shifted_alias_ty, term: default_ty.into() }, </ins> self.bound_vars, ) .to_predicate(self.tcx), ); <del> for bound in self.tcx.item_bounds(alias_ty.def_id).subst_iter(self.tcx, alias_ty.substs) </del> <ins> // We walk the *un-shifted* alias ty, because we're tracking the de bruijn // binder depth, and if we were to walk `shifted_alias_ty` instead, we'd // have to reset `self.depth` back to `ty::INNERMOST` or something. It's // easier to just do this. for bound in self .tcx .item_bounds(unshifted_alias_ty.def_id) .subst_iter(self.tcx, unshifted_alias_ty.substs) </ins> { bound.visit_with(self); }

Related discussion:
text: <!-- 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. --<!-- 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
probably Regression in searched nightlies: from nightly-2023-02-15 to nightly-2023-03-16 regressed nightly: nightly-2023-02-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's actually
Or at least, the logic broke because of , so the ICE message probably changed in that PR from some other message, to this one in the title.
label +S-bug-has-mcve
Code change:
pub struct Context<'a> { waker: &'a Waker, local_waker: &'a LocalWaker, <del> ext: ExtData<'a>, </del> <ins> ext: AssertUnwindSafe<ExtData<'a>>, </ins> // Ensure we future-proof against variance changes by forcing // the lifetime to be invariant (argument-position lifetimes // are contravariant while return-position lifetimes are

Related discussion:
text: https://crater-
I'll need to re-check later but this seems to bisect to somehow.
The UI test changes from that PR appear to back this up, as confusing as it is.
I'm not sure what's going on in that crate, if it built successfully by mistake, or how that PR interacts with it, so let's cc the PR author and reviewer for validation.
After , no longer implements and , because the context now contains a which doesn't implement those traits. So this is an issue with the standard library and not the crate being built. Repro: label -T-compiler +T-libs +S-has-mcve
WG-prioritization assigning priority (). Noticing this on which says that was meant to be confined on nightly. Unsure about the fallout of this regression but for now marking as critical for tracking purposes. label -I-prioritize +P-critical
Revert up:
Isn't not unwind safe?
That line was by your PR, so while what you say is technically true, talking about what "already happened" when we are traveling back and forth through time via version control may be more confusing than helpful.
That line was already there. I the line below it though. Original PR:
Apologies, I guess I can't count numbers today? Hm, so, the full error of the regression is this: Note that it's trying to make a pointer implement . And for what it's worth, stable does indeed document is . Thus unfortunately that line you pointed to, as opposed to the one I thought you were referring to, is effectively just documenting that all are , and that will include regardless of whether it is is . And confusingly, , unlike .
I have opened as an alternative.
Code change:
<ins> // Test that async fn works when nested inside of // impls with lifetime parameters. // // check-pass // edition:2018 #![feature(async_await)] struct Foo<'a>(&'a ()); impl<'a> Foo<'a> { fn test() { async fn test() {} } } fn main() { } </ins>

Related discussion:
text: The diagnostics ("use of undeclared lifetime name") are bad, but this indeed must be an error because the inner is an illegal use of the outer rather than an implicitly defined fresh lifetime.
Hm, I don't think that's quite what I'd expect: previously using in that context would be fine because there is no shadowing so to speak, that is, this compiles:
From Similarly, if a fn definition is nested inside another fn definition, it is an error to mention lifetimes from that outer definition (without binding them explicitly). This is again intended for future-proofing and clarity, and is an edge case. (In the second example there's an explicit definition that shadows the previous definition for following uses, in the first example there's no second definition, only use)
I see that this is in the RFC, but I think I more or less disagree with the reasoning given. Disallowing the use of inband lifetimes when nesting function seems arbitrary and not entirely helpful; it also makes a mechanical change from "old" to "new" more difficult because shadowing is visible only based on indent levels.
IMO it should be an error, with a helpful note like the one you get when writing . Let's not make in-band lifetimes any more confusing than they already are.
The distinction is that inband lifetime's selling point is that you don't need to declare lifetimes. If we say that, and then clarify it with "except" then I think the feature feels incomplete. Inband lifetimes confusion does not increase with permitting this, IMO.
The problem is if it's allowed, then has a different meaning than This seems unfortunate and confusing. Even unergonomic if I may say so. There's no way that the distinction between and won't be missed in a quick scan of the second one. But, like, the RFC process did decide that isn't important, so whatever.
Well, somewhat, but not really. Nothing outside of imports/definitions inherits into the inner function, unlike the impl where there is a history and multiple things which inherit (, lifetimes, generics).