jiebi/CodeConvo huggingface dataset:
Code change:
<ins> -include ../tools.mk # Test output to be four # The original error only occurred when printing, not when comparing using assert! all: $(RUSTC) foo.rs -O [ `$(call RUN,foo)` = "4" ] </ins>

Related discussion:
text: I got this while trying to implement something similar to a FromStr trait and tried to rely on a lot of inferencing when calling it. I can try to extract a standalone example if needed.
This ICE is also producible by trying to refer to an associated type that's never defined. is accepted by the compiler when it clearly should not be - what on earth is ? The following and code cases the same ICE. Here's the stack trace:
Code change:
<ins> -include ../tools.mk # Test output to be four # The original error only occurred when printing, not when comparing using assert! all: $(RUSTC) foo.rs -O [ `$(call RUN,foo)` = "4" ] </ins>

Related discussion:
text: I get the ICE below when I compile this fragment of code: The above structs are defined here: The above fragment is part of That crate depends on And that crate requires erlang-17.4 to be installed.
A minimal program to demonstrate the crash is...
Code change:
<ins> -include ../tools.mk # Test output to be four # The original error only occurred when printing, not when comparing using assert! all: $(RUSTC) foo.rs -O [ `$(call RUN,foo)` = "4" ] </ins>

Related discussion:
text: compile with opt-level = 2 (works fine with opt-level=0)
strange. the program looks legit to me.
this works for me now, as of
This prints on all opt levels for me at .
Code change:
<ins> // build-pass // edition:2018 static mut A: [i32; 5] = [1, 2, 3, 4, 5]; fn is_send_sync<T: Send + Sync>(_: T) {} async fn fun() { let u = unsafe { A[async { 1 }.await] }; unsafe { match A { i if async { true }.await => (), _ => (), } } } fn main() { let index_block = async { let u = unsafe { A[async { 1 }.await] }; }; let match_block = async { unsafe { match A { i if async { true }.await => (), _ => (), } } }; is_send_sync(index_block); is_send_sync(match_block); is_send_sync(fun()); } </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 // edition:2018 static mut A: [i32; 5] = [1, 2, 3, 4, 5]; fn is_send_sync<T: Send + Sync>(_: T) {} async fn fun() { let u = unsafe { A[async { 1 }.await] }; unsafe { match A { i if async { true }.await => (), _ => (), } } } fn main() { let index_block = async { let u = unsafe { A[async { 1 }.await] }; }; let match_block = async { unsafe { match A { i if async { true }.await => (), _ => (), } } }; is_send_sync(index_block); is_send_sync(match_block); is_send_sync(fun()); } </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 // edition:2018 static mut A: [i32; 5] = [1, 2, 3, 4, 5]; fn is_send_sync<T: Send + Sync>(_: T) {} async fn fun() { let u = unsafe { A[async { 1 }.await] }; unsafe { match A { i if async { true }.await => (), _ => (), } } } fn main() { let index_block = async { let u = unsafe { A[async { 1 }.await] }; }; let match_block = async { unsafe { match A { i if async { true }.await => (), _ => (), } } }; is_send_sync(index_block); is_send_sync(match_block); is_send_sync(fun()); } </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.
Code change:
<ins> // build-pass // edition:2018 static mut A: [i32; 5] = [1, 2, 3, 4, 5]; fn is_send_sync<T: Send + Sync>(_: T) {} async fn fun() { let u = unsafe { A[async { 1 }.await] }; unsafe { match A { i if async { true }.await => (), _ => (), } } } fn main() { let index_block = async { let u = unsafe { A[async { 1 }.await] }; }; let match_block = async { unsafe { match A { i if async { true }.await => (), _ => (), } } }; is_send_sync(index_block); is_send_sync(match_block); is_send_sync(fun()); } </ins>

Related discussion:
text: cc
So, I've been putting off commenting here to let these ideas sit, but let me leave a comment. I think I've reached a conclusion. TL;DR. I think we should mark these types as internal, but I think there are some better options for fixing this in the medium term, and this interaction should be taken into account as part of the "MIR 2.0" effort to rework places. Auto traits weren't really intended as a tool for probing layout, but rather semantic considerations. This is why traits like can be implemented by users. So I don't really think that auto traits give any sort of guarantee about their layout. Rather, this question is about is simply "what are the constituent types exposed by a generator", and this should correspond to the types that user code can directly access. The raw pointers here are not directly accessible. The values that are accessible are the "live values" that the user's code may later use -- and of course the code currently makes the constituent types be a superset of those, based on the AST structure. Of course, the real root cause of this error is a simplifying change to the definition of in MIR. It used to be that a Place had this grammar: but now we changed to just , which is why we are required to introduce the new temporary (and that holds the address of the ). As we've been talking about this change, I've been saying that we should be considering the older definition of as the one that is used by various analyses (and in particular by borrow check). This particular transformation of removing statics doesn't affect borrow check, but we failed to take into account the fact that the set of live variables can effect the definition of what is live in a generator. In particular, compiling for some expression requires a temporary unless corresponds to a place -- those places used to include statics like , but they no longer do. But I think that for analysis purposes, it should appear as if they do. We could fix this in two ways. We could write some code motion / duplication that takes temporaries like that are live across a yield and creates a fresh variable after the yield. The idea would be to make them never* live across a yield.
Code change:
<ins> // build-pass // edition:2018 static mut A: [i32; 5] = [1, 2, 3, 4, 5]; fn is_send_sync<T: Send + Sync>(_: T) {} async fn fun() { let u = unsafe { A[async { 1 }.await] }; unsafe { match A { i if async { true }.await => (), _ => (), } } } fn main() { let index_block = async { let u = unsafe { A[async { 1 }.await] }; }; let match_block = async { unsafe { match A { i if async { true }.await => (), _ => (), } } }; is_send_sync(index_block); is_send_sync(match_block); is_send_sync(fun()); } </ins>

Related discussion:
text: We can do this because that operation is a compile-time constant, really, and thus the value doesn't need to be live across a yield. This might be worth doing as a size optimization regardless. Secondly, some of the proposals we've been kicking around for going further with simplifying include the idea of a distinct sort of temporaries that explicitly represent a "partially constructed that hasn't been used by the user". The idea was to allow borrowck (and other analyses) to trivially reconstruct the . We might want to add this interaction with auto-traits into the consideration for that design, and maybe it takes us some place (e.g., these special temporaries are not considered live for the purposes of auto traits). Having written out both of those options, though, I sort of lean towards the first, at least for this specific issue.
I think these references and raw pointers created by MIR construction should be marked as . They are not visible at the language level. They can be viewed as just prefetching the address of a static, so the compiler could pick any type it likes for it (, , , some compiler internal type) so it must not affect auto trait inference. Drop flags are ignored for similar reasons. You cannot use an auto trait like this to detect them: So I think that should be reverted and the temporary static references should be marked as .
Note: opened instituting this change and I r+'d it, since fixing the regression seems pretty important and time is of the essence; there is general consensus here on the thread; this is only restoring older behavior. In particular, there were some suggestions that this might be a lang team issue; I think there is some 'intersection' and I don't want the perception that I'm trying to shortcircuit discussion. That said, I also think this is primarily a compiler team matter, since it's a deviation from the old behavior, and further this deviation was caused by altering the MIR away from the "natural, Rust-based" definition and towards a lower-level definition.
Code change:
static G: fn() = aux::G; static H: &(dyn Fn() + Sync) = aux::H; static I: fn() = aux::I; <ins> static K: fn() -> fn() = aux::K; </ins> fn v() -> *const u32 { V

Related discussion:
text: Regression in ( cc modify labels: +regression-from-stable-to-stable -regression-untriaged
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Beta backport accepted as per compiler team . A backport PR will be authored by the release team at the end of the current development cycle. label +beta-accepted
Code change:
) } <ins> fn is_glob_import(tcx: TyCtxt<'_>, import_id: LocalDefId) -> bool { if let Some(node) = tcx.opt_hir_node_by_def_id(import_id) && let hir::Node::Item(item) = node && let hir::ItemKind::Use(_, use_kind) = item.kind { use_kind == hir::UseKind::Glob } else { false } } </ins> fn generate_item_with_correct_attrs( cx: &mut DocContext<'_>, kind: ItemKind,

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: ! Instead, this happened: ! This is issue from First screenshot is of and second is of
Probably , it shouldn't have affected glob re-exports but maybe did (cc
Taking a look.
Same issue with a simple reexport:
That's what was meant to do, it wasn't meant to affect globs though.
I think there is another issue with how it's handled because nothing is listed on the item itself too: !
Ok so it's the expected output for a non-glob reexport. I wrote the fix for glob reexports, just need to add tests.
Latest nightly fixed the issue for but it didn't fix the issue for . In latest nightly below example doesn't work its last working version was also .
Noted. Sending a fix for it as well. :)
Fixed in
Code change:
f: F) { let prev_owner = self.current_dep_node_owner; let prev_signature_dep_index = self.current_signature_dep_index; <del> let prev_full_dep_index = self.current_signature_dep_index; </del> <ins> let prev_full_dep_index = self.current_full_dep_index; </ins> let prev_in_body = self.currently_in_body; let def_path_hash = self.definitions.def_path_hash(dep_node_owner);

Related discussion:
text: Found via rust-icci: https://travis- The commit history of the regex crate contains on changeset that only adds a comment which in turn leads to the body of a function being moved. This results in the update of the source location pointed to by a potential overflow panic message. This message is not updated properly in incremental mode: I have not found out yet why the change is not detected. HIR fingerprinting has special treatment of operations that can trigger overflows: There must be some kind of mismatch between when HIR fingerprinting thinks that an operation can panic and when we actually emit panic messages. This is another span-related papercut cc
Full IR files for reference:
Code change:
#[cfg(unix, test)] mod test { use core::prelude::*; <ins> use core::os; </ins> // FIXME(#2119): the outer attribute should be #[cfg(unix, test)], then // these redundant #[cfg(test)] blocks can be removed #[cfg(test)] #[cfg(test)] <del> use back::rpath::{get_install_prefix_rpath}; </del> <ins> use back::rpath::{get_absolute_rpath, get_install_prefix_rpath}; </ins> use back::rpath::{get_relative_to, get_rpath_relative_to_output}; use back::rpath::{minimize_rpaths, rpaths_to_flags}; use driver::session;

Related discussion:
text: These are configured something like
I am not sure why this happens off hand, but when bootstrapping the non-build-triple compilers artifacts are copied from e.g. to .
Code change:
<ins> // Regression test for #97405. // In `good_generic_fn` the param `T` ends up in the substs of closures/generators, // but we should be able to prove `<Gen<T> as Iterator>::Item: 'static` without // requiring `T: 'static` // edition:2018 // check-fail fn opaque<F>(_: F) -> impl Iterator { b"".iter() } fn assert_static<T: 'static>(_: T) {} fn good_generic_fn<T>() { // Previously, proving `<OpaqueTy<type_of(async {})> as Iterator>::Item: 'static` // used to require `T: 'static`. assert_static(opaque(async {}).next()); assert_static(opaque(|| {}).next()); assert_static(opaque(opaque(async {}).next()).next()); } // This should fail because `T` ends up in the upvars of the closure. fn bad_generic_fn<T: Copy>(t: T) { assert_static(opaque(async move { t; }).next()); //~^ ERROR the associated type `<impl Iterator as Iterator>::Item` may not live long enough assert_static(opaque(move || { t; }).next()); //~^ ERROR the associated type `<impl Iterator as Iterator>::Item` may not live long enough assert_static(opaque(opaque(async move { t; }).next()).next()); //~^ ERROR the associated type `<impl Iterator as Iterator>::Item` may not live long enough } fn main() {} </ins>

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: Both asserts don't pass. Adding bound on makes it compile. We are requiring all the for closures and generators to outlive here: This is wrong and inconsistent with the logic in <!-- 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. --Build using the Nightly version: 1.63.0-nightly (2022-05-24 ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details label T-compiler A-lifetimes A-closures A-generators claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.
Code change:
<ins> error: conflicting implementations of trait `FnMarker` for type `fn(&_)` --> $DIR/negative-coherence-placeholder-region-constraints-on-unification.rs:21:1 | LL | impl<T: ?Sized + Marker> FnMarker for fn(T) {} | ------------------------------------------- first implementation here LL | impl<T: ?Sized> FnMarker for fn(&T) {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `fn(&_)` | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #56105 <https://github.com/rust-lang/rust/issues/56105> = note: this behavior recently changed as a result of a bug fix; see rust-lang/rust#56105 for details note: the lint level is defined here --> $DIR/negative-coherence-placeholder-region-constraints-on-unification.rs:4:11 | LL | #![forbid(coherence_leak_check)] |           ^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

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:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait A { type Output; fn a(&self) -> <Self as A>::X; //~^ ERROR: use of undeclared associated type `A::X` } impl A for u32 { type Output = u32; fn a(&self) -> u32 { 0 } } fn main() { let a: u32 = 0; let b: u32 = a.a(); } </ins>

Related discussion:
text: Mm, we have "method macros" but now there are other things that can go in a trait.
Seems to be fixed by , but I don't see tests for it specifically, so I guess this needs tests.