jiebi/CodeConvo huggingface dataset:
Code change:
if (splitAt !== -1) { const implId = savedHash.slice(0, splitAt); const assocId = savedHash.slice(splitAt + 1); <del> const implElem = document.getElementById(implId); if (implElem && implElem.parentElement.tagName === "SUMMARY" && implElem.parentElement.parentElement.tagName === "DETAILS") { onEachLazy(implElem.parentElement.parentElement.querySelectorAll( </del> <ins> const implElems = document.querySelectorAll( `details > summary > section[id^="${implId}"]`, ); onEachLazy(implElems, implElem => { const numbered = /^(.+?)-([0-9]+)$/.exec(implElem.id); if (implElem.id !== implId && (!numbered || numbered[1] !== implId)) { return false; } return onEachLazy(implElem.parentElement.parentElement.querySelectorAll( </ins> `[id^="${assocId}"]`), item => { <del> const numbered = /([^-]+)-([0-9]+)/.exec(item.id); </del> <ins> const numbered = /^(.+?)-([0-9]+)$/.exec(item.id); </ins> if (item.id === assocId || (numbered && numbered[1] === assocId)) { openParentDetails(item); item.scrollIntoView();

Related discussion:
text: I spotted this in : the result links to ' which is not a valid link. Cc
cc -- I think these are supposed to be autoredirected in JS?
Okay... This happens because there's more than one and the one we want is currently named . The URL escaping is fine; the -35 is the problem.
Code change:
<del> // Regression test for an ICE: https://github.com/rust-lang/rust/issues/120884 </del> <ins> // Test that we don't ICE for coercions with type errors. </ins> // We still need to properly go through coercions between types with errors instead of // shortcutting and returning success, because we need the adjustments for building the MIR. pub fn has_error() -> TypeError {} //~^ ERROR cannot find type `TypeError` in this scope <ins> // https://github.com/rust-lang/rust/issues/120884 // Casting a function item to a data pointer in valid in HIR, but invalid in MIR. // We need an adjustment (ReifyFnPointer) to insert a cast from the function item // to a function pointer as a separate MIR statement. </ins> pub fn cast() -> *const u8 { <del> // Casting a function item to a data pointer in valid in HIR, but invalid in MIR. // We need an adjustment (ReifyFnPointer) to insert a cast from the function item // to a function pointer as a separate MIR statement. </del> has_error as *const u8 } <ins> // https://github.com/rust-lang/rust/issues/120945 // This one ICEd, because we skipped the builtin deref from `&TypeError` to `TypeError`. pub fn autoderef_source(e: &TypeError) { //~^ ERROR cannot find type `TypeError` in this scope autoderef_target(e) } pub fn autoderef_target(_: &TypeError) {} //~^ ERROR cannot find type `TypeError` in this scope </ins> fn main() {}

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'coerceborrowedpointer had no error'', 'thread 'rustc' panicked at 'coerceborrowedpointer had no error'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in there are no individual builds of the commits yet tho :sweat_smile:
I would guess cc
Code change:
use rustc_infer::infer::{self, InferCtxt, TyCtxtInferExt}; use rustc_infer::traits::util; use rustc_middle::ty::error::{ExpectedFound, TypeError}; <ins> use rustc_middle::ty::fold::BottomUpFolder; </ins> use rustc_middle::ty::util::ExplicitSelf; use rustc_middle::ty::{ self, GenericArgs, Ty, TypeFoldable, TypeFolder, TypeSuperFoldable, TypeVisitableExt,

Related discussion:
text: This is a use-after-free that compiles with 1.74.0-nightly (2023-09-13 ): cc
Code change:
let lifetime_params: Vec<(Span, ParamName)> = this.in_scope_lifetimes .iter().cloned() <del> .map(|ident| (ident.span, ParamName::Plain(ident))) </del> <ins> .map(|name| (name.ident().span, name)) </ins> .chain(this.lifetimes_to_define.iter().cloned()) .collect(); <ins> debug!("lower_async_fn_ret_ty: in_scope_lifetimes={:#?}", this.in_scope_lifetimes); debug!("lower_async_fn_ret_ty: lifetimes_to_define={:#?}", this.lifetimes_to_define); debug!("lower_async_fn_ret_ty: lifetime_params={:#?}", lifetime_params); </ins> let generic_params = lifetime_params .iter().cloned()

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).
Code change:
plug_infer_with_placeholders(infcx, universe, (impl1_header.impl_args, impl2_header.impl_args)); <ins> // FIXME(with_negative_coherence): the infcx has constraints from equating // the impl headers. We should use these constraints as assumptions, not as // requirements, when proving the negated where clauses below. drop(equate_obligations); drop(infcx.take_registered_region_obligations()); drop(infcx.take_and_reset_region_constraints()); </ins> util::elaborate(tcx, tcx.predicates_of(impl2_def_id).instantiate(tcx, impl2_header.impl_args)) .any(|(clause, _)| try_prove_negated_where_clause(infcx, clause, param_env)) }

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 expected to see this happen: Compiles successfully Instead, this happened: <!-- 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. --: label A-coherence F-negative_impls requires-nightly T-compiler
I'll look into it
Code change:
// @has impl_trait/fn.func2.html // @has - '//pre[@class="rust item-decl"]' "func2<T>(" // @has - '//pre[@class="rust item-decl"]' "_x: impl Deref<Target = Option<T>> + Iterator<Item = T>," <del> // @has - '//pre[@class="rust item-decl"]' "_y: impl Iterator<Item = u8> )" </del> <ins> // @has - '//pre[@class="rust item-decl"]' "_y: impl Iterator<Item = u8>, )" </ins> // @!has - '//pre[@class="rust item-decl"]' 'where' pub use impl_trait_aux::func2;

Related discussion:
text: Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
return; } <del> let is_error = match self.level { </del> <ins> self.handler.emit_db(&self); self.cancel(); } pub fn is_error(&self) -> bool { match self.level { </ins> Level::Bug | Level::Fatal | Level::PhaseFatal |

Related discussion:
text: Minimal example: Error message (ran in playground): Tested on nightly as well ()
Related:
twice without checking the return value. Modify it to return and check where it is being called ether both calls have returned an (cancel one, emit the other, return ), wether only one was created (emit it, return ) or none has (return ).
I'll fix this, thanks for the instruction!
I would happily have a go at this, if that's ok with
Sure go for it!
have you had time to work on this? If not could I give it a go? :)
I totally thought I was going to have time, but I had a crazy week at work this week. Go ahead and give it a go :) I'll find another bug to work on when I definitely have time
It looks like the PR to fix this was merged but has a few dangling threads. There seems to be some confusion about short-circuiting functionality and the necessity of the patch and also the error count still reads 2 rather than 1. Should a new issue be opened with those issues and this issue closed?
Code change:
<ins> error[E0451]: field `0` of struct `Box` is private --> $DIR/issue-82772.rs:5:15 | LL |     let Box { 0: _, .. }: Box<()>; |               ^^^^ private field error[E0451]: field `1` of struct `Box` is private --> $DIR/issue-82772.rs:6:15 | LL |     let Box { 1: _, .. }: Box<()>; |               ^^^^ private field error[E0451]: field `1` of struct `ModPrivateStruct` is private --> $DIR/issue-82772.rs:7:28 | LL |     let ModPrivateStruct { 1: _, .. } = ModPrivateStruct::default(); |                            ^^^^ private field error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0451`. </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. -- <!-- 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
Seems to be the indicated function:
.
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Oh this is ugly x) Reading the PR, the problem is that there are two ways to match a Box: via a box-pattern or via . But we can't know which will be used based on the type only. Current code assumes box-patterns, hence the error. The PR works because luckily all the fields of are private. If you tried pattern-matching within the module that defines , you'd get crazy results like (actually wouldn't even typecheck): We'll need to figure out a real solution when we implement generalized Deref patterns...
in that case we should open a new ticket for that work, tagged something like or something.
Code change:
| LL |     semitransparent!; |                    + <ins> help: a unit struct with a similar name exists | LL |     SemiTransparent; |     ~~~~~~~~~~~~~~~ </ins> error[E0423]: expected value, found macro `opaque` --> $DIR/rustc-macro-transparency.rs:30:5 | <ins> LL |     struct Opaque; |     -------------- similarly named unit struct `Opaque` defined here ... </ins> LL |     opaque; |     ^^^^^^ not a value |

Related discussion:
text: Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should include a note suggesting the variant with the same name (but different case):
label +C-enhancement +D-newcomer-roadblock
This only doesn't Just Work because the Levenshtein thing is case sensitive, right? There is some special-casing for case-insensitive suggestions but afaict it only applies if the case-sensitive Levenshtein distance is also already low, which seems wrong at first glance.
im working on this Edit: I'm not working on this anymore because I ran out of time getting past incremental compilation / llvm errors after a rebase.
Okay, judging by , this is explicitly not supposed to work. shrug emoji Edit: Okay, maybe that test case didn't really care. The use of case-insensitive match as tie breaker for equal levenshtein distance only was introduced with afaict.
Code change:
sig.decl.has_self(), sig.decl.inputs.iter().map(|Param { ty, .. }| (None, &**ty)), &sig.decl.output, <del> ) </del> <ins> ); this.record_lifetime_params_for_async( fn_id, sig.header.asyncness.opt_return_id(), ); </ins> }, ); return;

Related discussion:
text: Example: yields <details<summaryBacktrace</summary</details
cc and
This has to do with late-bound regions and RPITITs. I have a fix, but it's probably not right nor is it cleaned up much. I'll put it up for scrutiny soon though.
Actually nvm, it was a silly little resolver bug.
label +I-ICE +C-bug
Code change:
sig.decl.has_self(), sig.decl.inputs.iter().map(|Param { ty, .. }| (None, &**ty)), &sig.decl.output, <del> ) </del> <ins> ); this.record_lifetime_params_for_async( fn_id, sig.header.asyncness.opt_return_id(), ); </ins> }, ); return;

Related discussion:
text: I'm seeing an internal compiler error on the following input (found by ):
Report from : regressed nightly: nightly-2020-02-07
It looks like caused the regression. (The error happens at but not at .) cc
The specific commit where the error starts happening is .
triage: P-high. Removing nomination. Added regression stable-to-nightly tag.
Fixed by
Code change:
<ins> // build-pass #![feature(generators)] static mut A: [i32; 5] = [1, 2, 3, 4, 5]; fn is_send_sync<T: Send + Sync>(_: T) {} fn main() { unsafe { let gen_index = static || { let u = A[{ yield; 1 }]; }; let gen_match = static || match A { i if { yield; true } => { () } _ => (), }; is_send_sync(gen_index); is_send_sync(gen_match); } } </ins>

Related discussion:
text: root: updns-0.0.6: v.
triage: P-high. Nominating for discussion.
self-assigned for investigation in short term (as in, next two or three days). However I suspect someone from will be a better choice to investigate this.
We should try to bisect this
used . Determined: searched nightlies: from nightly-2019-11-26 to nightly-2020-01-03 regressed nightly: nightly-2019-12-01 searched commits: from to  regressed commit:
is a rollup commit of the following PR's: I'm guessing this is due to PR
I'm still working on reducing this down to something that I could put into the playpen. However, one interesting thing I've found locally during my reduction: This version of the will signal an analogous compilation error: but if I lift the first argument out to a separate -binding (i.e. change it to use above, or the sub-expression out to a separate -binding (i.e. change the argument expression to use above), then the error goes away. I'll admit that I don't know all the details of how the fn-transformation works to support , but I strongly suspect that if this kind of local code change can make an error go away, then that represents a weakness somewhere (either in the fn-transformation, or in the borrowck).
Okay in the details block is a standalone version suitable for the : <details</detailsand the error it generates:
So this does seem like somewhat clear (expected?) fallout from PR : a use of a in a generator witness will be recorded as a unsafe pointer , and then is never , but the method requires that the task you give it is . I believe we can readily update the crate in question to avoid using the in the expression under the RHS of . But I do wonder whether we can/should improve the diagnostics here to try to guide the user towards such a solution ...?
I might have worded this too strongly, and/or over-reduced my example. In particular, its easy to move around the access to . But the borrow of may be trickier to deal with.
I'll have a look at addressing this with another approach I considered for . If that doesn't work out then I'll have a look at the error message.
Code change:
<ins> // build-pass #![feature(generators)] static mut A: [i32; 5] = [1, 2, 3, 4, 5]; fn is_send_sync<T: Send + Sync>(_: T) {} fn main() { unsafe { let gen_index = static || { let u = A[{ yield; 1 }]; }; let gen_match = static || match A { i if { yield; true } => { () } _ => (), }; is_send_sync(gen_index); is_send_sync(gen_match); } } </ins>

Related discussion:
text: The patch linked is enough to fix the crate in question, but I'm all for finding an in-compiler solution if we can do it soundly.
OK. I'm going to write some things up because I've changed my mind a bunch of times about how/if this can be fixed in MIR building and I don't want to keep forgetting things. Generators store values that if their value needs to be preserved across a yield. These values need to be visible for auto-traits, for example a generator may be resumed on a different thread after it yields, and so cannot be if any of theses values isn't . There are two passes that determine which values can be included in the generator: A pass that runs as part of typeck that walks the HIR to find the types of expressions and then checks for yields in the values scope (as determined by the RegionScopeTree). The types recorded here are stored in the GeneratorWitnesss type contained in the generator, which is then used for auto trait checking. This notably uses the types of expressions that HIR sees. The MIR transform that lowers the generator to a state machine. This determines the values that the generator actually stores. As a check for the compiler, we assert that any types that we capture here are included in the witness type (we don't know all auto traits, so can't check only for them). After statics no longer have a special representation in MIR. They are instead lowered to a dereference of a pointer to the given static: is lowered as if it were: Which becomes: The example above is somewhat deceptive in that the temporary that holds the pointer is used immediately after it's assigned. In this case it cannot end up in the generator since it's not live across any user code. However this isn't true in all cases, index and match expressions allow running user code while the pointer is live: In these cases MIR has to put the temporary pointer into the generator state and promptly ICEs. The obvious solution now is make type checking record the new pointer types in the generator witness in these cases. Unfortunately HIR is not a great tool for specifying "these cases". The methods that the region scope tree provides in HIR are either usually far too large (the "temporary scope") or occasionally too small (the "enclosing scope"). went for the sound but rather approximate approach, leaving us here.
Code change:
<ins> // build-pass #![feature(generators)] static mut A: [i32; 5] = [1, 2, 3, 4, 5]; fn is_send_sync<T: Send + Sync>(_: T) {} fn main() { unsafe { let gen_index = static || { let u = A[{ yield; 1 }]; }; let gen_match = static || match A { i if { yield; true } => { () } _ => (), }; is_send_sync(gen_index); is_send_sync(gen_match); } } </ins>

Related discussion:
text: One idea might be to try changing MIR building so that the temporary is never live across user code. For example, one might change the lowering as follows However working out how to do this for in a reasonable to implement way is harder. MIR actually already contains an escape hatch for values that are in the MIR but aren't in the HIR in the form of a flag (called ) on the variable. We currently use it for drop flags and boxes created by expressions. It's unclear what exactly the difference is between is. I guess one could argue that auto traits are for layout introspection and this would be further breaking that. I think that's everything for now.
Visiting from triage. were you planning to work on this further?
It's definitely tempting to take advantage of the constraints around statics to just declare these equivalent, and use the flag to get out of this. While I don't see any soundness issues around that, I also don't quite trust myself to get this right :) Can you expand on this? I'm not sure I follow.
Another solution that comes to mind relies on the fact that these pointers never need to be stored in a generator. They are consts, and the temporaries containing them shouldn't ever be mutated. We could add semantics for "const temporaries" to MIR, and never store them inside generators. The semantics would (hopefully) be simple: defined once and assigned a value that doesn't depend on any other temporaries; never mutated or borrowed mutably. We can move the statements defining them to the top of the function inside the generator transform. But that would be adding more semantics and special casing to MIR to fix a change which removed extra semantics and special casing, so I'm not sure if that's what we want :)
The argument is that the given the following auto trait we guarantee that if then there are no raw pointers directly stored in an instance of . If we make that guarantee then using internal in generators would not be OK. I would argue that we're not making such (or really any) guarantees with user defined auto traits.
Yeah, I don't think auto traits should expose layout implementation details of generators. And this really does seem like a pure implementation detail -- it doesn't have any bearing on what kinds of (unsafe) operations are allowed on a generator, like a self-reference would.