Implement `use<>` formatting in rustfmt #126754

compiler-errors · 2024-06-20T17:55:19Z

This PR implements formatting for precise-capturing use<> syntax as proposed in #126753.

The syntax is implemented as-if the use<> bound were a trait bound but with the use keyword as its path segment identifier.

I opted to develop this in the rust-lang/rust tree since I'm not certain when the next rustfmt subtree sync is going to be, and I'd rather not block landing nightly support for use<> on something I have no control over. If @rust-lang/rustfmt would rather I move this PR over to that repository, then I would at least like to know when the next rustfmt->rust subtree sync is going to be, since stabilizing precise_capturing without formatting will be disruptive.

This implementation is otherwise rather straightforward.

Tracking:

Tracking issue for precise_capturing syntax #123432

rustbot · 2024-06-20T17:55:27Z

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2024-06-20T17:55:28Z

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

compiler-errors · 2024-06-20T17:55:37Z

r? @calebcartwright or @ytmimi

compiler-errors · 2024-06-20T18:47:19Z

CI failure looks unrelated.

calebcartwright · 2024-06-21T04:14:29Z

then I would at least like to know when the next rustfmt->rust subtree sync is going to be, since stabilizing precise_capturing without formatting will be disruptive.

Anticipating tomorrow (June 21st), depending on how the topic discussed in zulip shakes out timing wise

if this needs to land first that's fine, but may knock the sync back by a couple hours/days if this lands first (git subtree can be very fussy)

calebcartwright

lgtm and npm ci issues seem highly unrelated indeed 😆

feel free to r=me if this needs to get in before the sync, though even if the implementation goes ahead in this repo it would be nice if we could have bors land the subtree sync PR first and then this after, as we can't rebase on syncs

compiler-errors · 2024-06-21T04:23:20Z

I'll wait until after the next rustfmt->rust subtree sync, then land this PR on rust. I'm happy to wait a few days -- there's not that much urgency here.

Then this PR can get merged back into rustfmt's repo at your own pace with the next rust->rustfmt subtree sync. Don't want to cause any pains around this next rustfmt->rust sync.

compiler-errors · 2024-06-23T14:58:12Z

OK this is ready and looks like the merge went through (#126842).

@bors r=calebcartwright

bors · 2024-06-23T14:58:14Z

📌 Commit a426d6f has been approved by calebcartwright

It is now in the queue for this repository.

…ebcartwright Implement `use<>` formatting in rustfmt This PR implements formatting for precise-capturing `use<>` syntax as proposed in rust-lang#126753. The syntax is implemented as-if the `use<>` bound were a trait bound but with the `use` keyword as its path segment identifier. I opted to develop this in the rust-lang/rust tree since I'm not certain when the next rustfmt subtree sync is going to be, and I'd rather not block landing nightly support for `use<>` on something I have no control over. If `@rust-lang/rustfmt` would rather I move this PR over to that repository, then I would at least like to know when the next rustfmt->rust subtree sync is going to be, since stabilizing `precise_capturing` without formatting will be disruptive. This implementation is otherwise rather straightforward. Tracking: - rust-lang#123432

…kingjubilee Rollup of 9 pull requests Successful merges: - rust-lang#126177 (Add hard error and migration lint for unsafe attrs) - rust-lang#126298 (Promote loongarch64-unknown-linux-musl to Tier 2 with host tools) - rust-lang#126455 (For [E0308]: mismatched types, when expr is in an arm's body, not add semicolon ';' at the end of it.) - rust-lang#126754 (Implement `use<>` formatting in rustfmt) - rust-lang#126807 (std::unix::fs: copy simplification for apple.) - rust-lang#126845 (Weekly `cargo update`) - rust-lang#126849 (Fix 32-bit Arm reg classes by hierarchically sorting them) - rust-lang#126854 (std::unix::os::home_dir: fallback's optimisation.) - rust-lang#126861 (Migrate `run-make/invalid-library` to `rmake.rs`) r? `@ghost` `@rustbot` modify labels: rollup

…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#126177 (Add hard error and migration lint for unsafe attrs) - rust-lang#126298 (Promote loongarch64-unknown-linux-musl to Tier 2 with host tools) - rust-lang#126455 (For [E0308]: mismatched types, when expr is in an arm's body, not add semicolon ';' at the end of it.) - rust-lang#126754 (Implement `use<>` formatting in rustfmt) - rust-lang#126807 (std::unix::fs: copy simplification for apple.) - rust-lang#126845 (Weekly `cargo update`) - rust-lang#126849 (Fix 32-bit Arm reg classes by hierarchically sorting them) - rust-lang#126854 (std::unix::os::home_dir: fallback's optimisation.) - rust-lang#126888 (Remove stray println from rustfmt's `rewrite_static`) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#126754 - compiler-errors:use-rustfmt, r=calebcartwright Implement `use<>` formatting in rustfmt This PR implements formatting for precise-capturing `use<>` syntax as proposed in rust-lang#126753. The syntax is implemented as-if the `use<>` bound were a trait bound but with the `use` keyword as its path segment identifier. I opted to develop this in the rust-lang/rust tree since I'm not certain when the next rustfmt subtree sync is going to be, and I'd rather not block landing nightly support for `use<>` on something I have no control over. If ``@rust-lang/rustfmt`` would rather I move this PR over to that repository, then I would at least like to know when the next rustfmt->rust subtree sync is going to be, since stabilizing `precise_capturing` without formatting will be disruptive. This implementation is otherwise rather straightforward. Tracking: - rust-lang#123432

@Kobzol

Update Rust toolchain from nightly-2024-06-24 to nightly-2024-06-25 without any other source changes. This is an automatically generated pull request. If any of the CI checks fail, manual intervention is required. In such a case, review the changes at https://github.com/rust-lang/rust from rust-lang@bcf94de up to rust-lang@6b0f4b5. The log for this commit range is: rust-lang@6b0f4b5ec3 Auto merge of rust-lang#126914 - compiler-errors:rollup-zx0hchm, r=compiler-errors rust-lang@16bd6e25e1 Rollup merge of rust-lang#126911 - oli-obk:do_not_count_errors, r=compiler-errors rust-lang@59c258f51f Rollup merge of rust-lang#126909 - onur-ozkan:add-kobzol, r=matthiaskrgr rust-lang@85eb835a14 Rollup merge of rust-lang#126904 - GrigorenkoPV:nonzero-fixme, r=joboet rust-lang@a7721a0373 Rollup merge of rust-lang#126899 - GrigorenkoPV:suggest-const-block, r=davidtwco rust-lang@9ce2a070b3 Rollup merge of rust-lang#126682 - Zalathar:coverage-attr, r=lcnr rust-lang@49bdf460a2 Rollup merge of rust-lang#126673 - oli-obk:dont_rely_on_err_reporting, r=compiler-errors rust-lang@46e43984d1 Rollup merge of rust-lang#126413 - matthiaskrgr:crshmsg, r=oli-obk rust-lang@ed460d2eaa Rollup merge of rust-lang#125575 - dingxiangfei2009:derive-smart-ptr, r=davidtwco rust-lang@c77dc28f87 Rollup merge of rust-lang#125082 - kpreid:const-uninit, r=dtolnay rust-lang@faa28be2f1 Rollup merge of rust-lang#124712 - Enselic:deprecate-inline-threshold, r=pnkfelix rust-lang@00e5f5886a Rollup merge of rust-lang#124460 - long-long-float:show-notice-about-enum-with-debug, r=pnkfelix rust-lang@d8d5732456 Auto merge of rust-lang#126784 - scottmcm:smaller-terminator, r=compiler-errors rust-lang@13fca73f49 Replace `MaybeUninit::uninit_array()` with array repeat expression. rust-lang@5a3e2a4e92 Auto merge of rust-lang#126523 - joboet:the_great_big_tls_refactor, r=Mark-Simulacrum rust-lang@45261ff2ec add @Kobzol to bootstrap team for triagebot rust-lang@84474a25a4 Small fixme in core now that NonZero is generic rust-lang@50a02ed789 std: fix wasm builds rust-lang@8fc6b3de19 Separate the mir body lifetime from the other lifetimes rust-lang@1c4d0ced58 Separate the lifetimes of the `BorrowckInferCtxt` from the other borrowed items rust-lang@d371d17496 Auto merge of rust-lang#126900 - matthiaskrgr:rollup-24ah97b, r=matthiaskrgr rust-lang@8ffb5f936a compiletest: make the crash test error message abit more informative rust-lang@a80ee9159b Rollup merge of rust-lang#126882 - estebank:multiline-order, r=WaffleLapkin rust-lang@8bfde609e2 Rollup merge of rust-lang#126414 - ChrisDenton:target-known, r=Nilstrieb rust-lang@94b9ea417d Rollup merge of rust-lang#126213 - zachs18:atomicbool-u8-i8-from-ptr-alignment, r=Nilstrieb rust-lang@9d24ecc37b Rollup merge of rust-lang#125241 - Veykril:tool-rust-analyzer, r=davidtwco rust-lang@ba5ec1fc5c Suggest inline const blocks for array initialization rust-lang@06c072f158 Auto merge of rust-lang#126788 - GuillaumeGomez:migrate-rustdoc-tests-syntax, r=fmease,oli-obk rust-lang@1852141219 coverage: Bless coverage attribute tests rust-lang@b7c057c9b2 coverage: Always error on `#[coverage(..)]` in unexpected places rust-lang@a000fa8b54 coverage: Tighten validation of `#[coverage(off)]` and `#[coverage(on)]` rust-lang@b5dfeba0e1 coverage: Forbid multiple `#[coverage(..)]` attributes rust-lang@6909feab8e Allow numbers in rustdoc tests commands rust-lang@4e258bb4c3 Fix tidy issue for rustdoc tests commands rust-lang@51fedf65ff Remove commands duplication between `compiletest` and `tests/rustdoc` rust-lang@1b67035579 Update `tests/rustdoc` to new test syntax rust-lang@d3ec92e16e Move `tests/rustdoc` testsuite to `//@` syntax rust-lang@2c243d9570 Auto merge of rust-lang#126891 - matthiaskrgr:rollup-p6dl1gk, r=matthiaskrgr rust-lang@b94d2754b5 Rollup merge of rust-lang#126888 - compiler-errors:oops-debug-printing, r=dtolnay rust-lang@9892b3e9fe Rollup merge of rust-lang#126854 - devnexen:std_unix_os_fallback_upd, r=Mark-Simulacrum rust-lang@3108dfaced Rollup merge of rust-lang#126849 - workingjubilee:correctly-classify-arm-low-dregs, r=Amanieu rust-lang@dcace866f0 Rollup merge of rust-lang#126845 - rust-lang:cargo_update, r=Mark-Simulacrum rust-lang@21850f5bd8 Rollup merge of rust-lang#126807 - devnexen:copy_file_macos_simpl, r=Mark-Simulacrum rust-lang@b24e3df0df Rollup merge of rust-lang#126754 - compiler-errors:use-rustfmt, r=calebcartwright rust-lang@ad0531ae0d Rollup merge of rust-lang#126455 - surechen:fix_126222, r=estebank rust-lang@7babf99ea9 Rollup merge of rust-lang#126298 - heiher:loongarch64-musl-ci, r=Mark-Simulacrum rust-lang@9a591ea1ce Rollup merge of rust-lang#126177 - carbotaniuman:unsafe_attr_errors, r=jieyouxu rust-lang@25446c25fc Remove stray println from rustfmt rust-lang@d49994b060 Auto merge of rust-lang#126023 - amandasystems:you-dropped-this-again, r=nikomatsakis rust-lang@a23917cfd0 Add hard error and migration lint for unsafe attrs rust-lang@284437d434 Special case when a code line only has multiline span starts rust-lang@f1be59fa72 SmartPointer derive-macro rust-lang@a426d6fdf0 Implement use<> formatting in rustfmt rust-lang@16fef40896 Promote loongarch64-unknown-linux-musl to Tier 2 with host tools rust-lang@03d73fa6ba ci: Add support for dist-loongarch64-musl rust-lang@fc50acae90 fix build rust-lang@bd9ce3e074 std::unix::os::home_dir: fallback's optimisation. rust-lang@0d8f734172 compiler: Fix arm32 asm issues by hierarchically sorting reg classes rust-lang@e8b5ba1111 For [E0308]: mismatched types, when expr is in an arm's body, not add semicolon ';' at the end of it. rust-lang@990535723d cargo update rust-lang@b28efb11af Save 2 pointers in `TerminatorKind` (96 → 80 bytes) rust-lang@65530ba100 std::unix::fs: copy simplification for apple. rust-lang@339015920d Add `rust_analyzer` as a predefined tool rust-lang@3f2f8438b4 Ensure we don't accidentally succeed when we want to report an error rust-lang@32f9b8bf76 std: rename module for clarity rust-lang@35f050b8da std: update TLS module documentation rust-lang@b2f29edc81 std: use the `c_int` from `core::ffi` instead of `libc` rust-lang@d70f071392 std: simplify `#[cfg]`s for TLS rust-lang@d630f5da7a Show notice about "never used" for enum rust-lang@f3facf1175 std: refactor the TLS implementation rust-lang@f5f067bf9d Deprecate no-op codegen option `-Cinline-threshold=...` rust-lang@651ff643ae Fix typo in `-Cno-stack-check` deprecation warning rust-lang@3af624272a rustc_codegen_ssa: Remove unused ModuleConfig::inline_threshold rust-lang@34e6ea1446 Tier 2 std support must always be known rust-lang@2d4cb7aa5a Update docs for AtomicU8/I8. rust-lang@7885c7b7b2 Update safety docs for AtomicBool::from_ptr. rust-lang@7b5b7a7010 Remove confusing `use_polonius` flag and do less cloning Co-authored-by: tautschnig <1144736+tautschnig@users.noreply.github.com>

…=spastorino Stabilize opaque type precise capturing (RFC 3617) This PR partially stabilizes opaque type *precise capturing*, which was specified in [RFC 3617](rust-lang/rfcs#3617), and whose syntax was amended by FCP in [rust-lang#125836](rust-lang#125836). This feature, as stabilized here, gives us a way to explicitly specify the generic lifetime parameters that an RPIT-like opaque type captures. This solves the problem of overcapturing, for lifetime parameters in these opaque types, and will allow the Lifetime Capture Rules 2024 ([RFC 3498](rust-lang/rfcs#3498)) to be fully stabilized for RPIT in Rust 2024. ### What are we stabilizing? This PR stabilizes the use of a `use<'a, T>` bound in return-position impl Trait opaque types. Such a bound fully specifies the set of generic parameters captured by the RPIT opaque type, entirely overriding the implicit default behavior. E.g.: ```rust fn does_not_capture<'a, 'b>() -> impl Sized + use<'a> {} // ~~~~~~~~~~~~~~~~~~~~ // This RPIT opaque type does not capture `'b`. ``` The way we would suggest thinking of `impl Trait` types *without* an explicit `use<..>` bound is that the `use<..>` bound has been *elided*, and that the bound is filled in automatically by the compiler according to the edition-specific capture rules. All non-`'static` lifetime parameters, named (i.e. non-APIT) type parameters, and const parameters in scope are valid to name, including an elided lifetime if such a lifetime would also be valid in an outlives bound, e.g.: ```rust fn elided(x: &u8) -> impl Sized + use<'_> { x } ``` Lifetimes must be listed before type and const parameters, but otherwise the ordering is not relevant to the `use<..>` bound. Captured parameters may not be duplicated. For now, only one `use<..>` bound may appear in a bounds list. It may appear anywhere within the bounds list. ### How does this differ from the RFC? This stabilization differs from the RFC in one respect: the RFC originally specified `use<'a, T>` as syntactically part of the RPIT type itself, e.g.: ```rust fn capture<'a>() -> impl use<'a> Sized {} ``` However, settling on the final syntax was left as an open question. T-lang later decided via FCP in [rust-lang#125836](rust-lang#125836) to treat `use<..>` as a syntactic bound instead, e.g.: ```rust fn capture<'a>() -> impl Sized + use<'a> {} ``` ### What aren't we stabilizing? The key goal of this PR is to stabilize the parts of *precise capturing* that are needed to enable the migration to Rust 2024. There are some capabilities of *precise capturing* that the RFC specifies but that we're not stabilizing here, as these require further work on the type system. We hope to lift these limitations later. The limitations that are part of this PR were specified in the [RFC's stabilization strategy](https://rust-lang.github.io/rfcs/3617-precise-capturing.html#stabilization-strategy). #### Not capturing type or const parameters The RFC addresses the overcapturing of type and const parameters; that is, it allows for them to not be captured in opaque types. We're not stabilizing that in this PR. Since all in scope generic type and const parameters are implicitly captured in all editions, this is not needed for the migration to Rust 2024. For now, when using `use<..>`, all in scope type and const parameters must be nameable (i.e., APIT cannot be used) and included as arguments. For example, this is an error because `T` is in scope and not included as an argument: ```rust fn test<T>() -> impl Sized + use<> {} //~^ ERROR `impl Trait` must mention all type parameters in scope in `use<...>` ``` This is due to certain current limitations in the type system related to how generic parameters are represented as captured (i.e. bivariance) and how inference operates. We hope to relax this in the future, and this stabilization is forward compatible with doing so. #### Precise capturing for return-position impl Trait **in trait** (RPITIT) The RFC specifies precise capturing for RPITIT. We're not stabilizing that in this PR. Since RPITIT already adheres to the Lifetime Capture Rules 2024, this isn't needed for the migration to Rust 2024. The effect of this is that the anonymous associated types created by RPITITs must continue to capture all of the lifetime parameters in scope, e.g.: ```rust trait Foo<'a> { fn test() -> impl Sized + use<Self>; //~^ ERROR `use<...>` precise capturing syntax is currently not allowed in return-position `impl Trait` in traits } ``` To allow this involves a meaningful amount of type system work related to adding variance to GATs or reworking how generics are represented in RPITITs. We plan to do this work separately from the stabilization. See: - rust-lang#124029 Supporting precise capturing for RPITIT will also require us to implement a new algorithm for detecting refining capture behavior. This may involve looking through type parameters to detect cases where the impl Trait type in an implementation captures fewer lifetimes than the corresponding RPITIT in the trait definition, e.g.: ```rust trait Foo { fn rpit() -> impl Sized + use<Self>; } impl<'a> Foo for &'a () { // This is "refining" due to not capturing `'a` which // is implied by the trait's `use<Self>`. fn rpit() -> impl Sized + use<>; // This is not "refining". fn rpit() -> impl Sized + use<'a>; } ``` This stabilization is forward compatible with adding support for this later. ### The technical details This bound is purely syntactical and does not lower to a [`Clause`](https://doc.rust-lang.org/1.79.0/nightly-rustc/rustc_middle/ty/type.ClauseKind.html) in the type system. For the purposes of the type system (and for the types team's curiosity regarding this stabilization), we have no current need to represent this as a `ClauseKind`. Since opaques already capture a variable set of lifetimes depending on edition and their syntactical position (e.g. RPIT vs RPITIT), a `use<..>` bound is just a way to explicitly rather than implicitly specify that set of lifetimes, and this only affects opaque type lowering from AST to HIR. ### FCP plan While there's much discussion of the type system here, the feature in this PR is implemented internally as a transformation that happens before lowering to the type system layer. We already support impl Trait types partially capturing the in scope lifetimes; we just currently only expose that implicitly. So, in my (errs's) view as a types team member, there's nothing for types to weigh in on here with respect to the implementation being stabilized, and I'd suggest a lang-only proposed FCP (though we'll of course CC the team below). ### Authorship and acknowledgments This stabilization report was coauthored by compiler-errors and TC. TC would like to acknowledge the outstanding and speedy work that compiler-errors has done to make this feature happen. compiler-errors thanks TC for authoring the RFC, for all of his involvement in this feature's development, and pushing the Rust 2024 edition forward. ### Open items We're doing some things in parallel here. In signaling the intention to stabilize, we want to uncover any latent issues so we can be sure they get addressed. We want to give the maximum time for discussion here to happen by starting it while other remaining miscellaneous work proceeds. That work includes: - [x] Look into `syn` support. - dtolnay/syn#1677 - dtolnay/syn#1707 - [x] Look into `rustfmt` support. - rust-lang#126754 - [x] Look into `rust-analyzer` support. - rust-lang/rust-analyzer#17598 - rust-lang/rust-analyzer#17676 - [x] Look into `rustdoc` support. - rust-lang#127228 - rust-lang#127632 - rust-lang#127658 - [x] Suggest this feature to RfL (a known nightly user). - [x] Add a chapter to the edition guide. - rust-lang/edition-guide#316 - [x] Update the Reference. - rust-lang/reference#1577 ### (Selected) implementation history * rust-lang/rfcs#3498 * rust-lang/rfcs#3617 * rust-lang#123468 * rust-lang#125836 * rust-lang#126049 * rust-lang#126753 Closes rust-lang#123432. cc `@rust-lang/lang` `@rust-lang/types` `@rustbot` labels +T-lang +I-lang-nominated +A-impl-trait +F-precise_capturing Tracking: - rust-lang#123432 ---- For the compiler reviewer, I'll leave some inline comments about diagnostics fallout :^) r? compiler

Stabilize opaque type precise capturing (RFC 3617) This PR partially stabilizes opaque type *precise capturing*, which was specified in [RFC 3617](rust-lang/rfcs#3617), and whose syntax was amended by FCP in [#125836](rust-lang/rust#125836). This feature, as stabilized here, gives us a way to explicitly specify the generic lifetime parameters that an RPIT-like opaque type captures. This solves the problem of overcapturing, for lifetime parameters in these opaque types, and will allow the Lifetime Capture Rules 2024 ([RFC 3498](rust-lang/rfcs#3498)) to be fully stabilized for RPIT in Rust 2024. ### What are we stabilizing? This PR stabilizes the use of a `use<'a, T>` bound in return-position impl Trait opaque types. Such a bound fully specifies the set of generic parameters captured by the RPIT opaque type, entirely overriding the implicit default behavior. E.g.: ```rust fn does_not_capture<'a, 'b>() -> impl Sized + use<'a> {} // ~~~~~~~~~~~~~~~~~~~~ // This RPIT opaque type does not capture `'b`. ``` The way we would suggest thinking of `impl Trait` types *without* an explicit `use<..>` bound is that the `use<..>` bound has been *elided*, and that the bound is filled in automatically by the compiler according to the edition-specific capture rules. All non-`'static` lifetime parameters, named (i.e. non-APIT) type parameters, and const parameters in scope are valid to name, including an elided lifetime if such a lifetime would also be valid in an outlives bound, e.g.: ```rust fn elided(x: &u8) -> impl Sized + use<'_> { x } ``` Lifetimes must be listed before type and const parameters, but otherwise the ordering is not relevant to the `use<..>` bound. Captured parameters may not be duplicated. For now, only one `use<..>` bound may appear in a bounds list. It may appear anywhere within the bounds list. ### How does this differ from the RFC? This stabilization differs from the RFC in one respect: the RFC originally specified `use<'a, T>` as syntactically part of the RPIT type itself, e.g.: ```rust fn capture<'a>() -> impl use<'a> Sized {} ``` However, settling on the final syntax was left as an open question. T-lang later decided via FCP in [#125836](rust-lang/rust#125836) to treat `use<..>` as a syntactic bound instead, e.g.: ```rust fn capture<'a>() -> impl Sized + use<'a> {} ``` ### What aren't we stabilizing? The key goal of this PR is to stabilize the parts of *precise capturing* that are needed to enable the migration to Rust 2024. There are some capabilities of *precise capturing* that the RFC specifies but that we're not stabilizing here, as these require further work on the type system. We hope to lift these limitations later. The limitations that are part of this PR were specified in the [RFC's stabilization strategy](https://rust-lang.github.io/rfcs/3617-precise-capturing.html#stabilization-strategy). #### Not capturing type or const parameters The RFC addresses the overcapturing of type and const parameters; that is, it allows for them to not be captured in opaque types. We're not stabilizing that in this PR. Since all in scope generic type and const parameters are implicitly captured in all editions, this is not needed for the migration to Rust 2024. For now, when using `use<..>`, all in scope type and const parameters must be nameable (i.e., APIT cannot be used) and included as arguments. For example, this is an error because `T` is in scope and not included as an argument: ```rust fn test<T>() -> impl Sized + use<> {} //~^ ERROR `impl Trait` must mention all type parameters in scope in `use<...>` ``` This is due to certain current limitations in the type system related to how generic parameters are represented as captured (i.e. bivariance) and how inference operates. We hope to relax this in the future, and this stabilization is forward compatible with doing so. #### Precise capturing for return-position impl Trait **in trait** (RPITIT) The RFC specifies precise capturing for RPITIT. We're not stabilizing that in this PR. Since RPITIT already adheres to the Lifetime Capture Rules 2024, this isn't needed for the migration to Rust 2024. The effect of this is that the anonymous associated types created by RPITITs must continue to capture all of the lifetime parameters in scope, e.g.: ```rust trait Foo<'a> { fn test() -> impl Sized + use<Self>; //~^ ERROR `use<...>` precise capturing syntax is currently not allowed in return-position `impl Trait` in traits } ``` To allow this involves a meaningful amount of type system work related to adding variance to GATs or reworking how generics are represented in RPITITs. We plan to do this work separately from the stabilization. See: - rust-lang/rust#124029 Supporting precise capturing for RPITIT will also require us to implement a new algorithm for detecting refining capture behavior. This may involve looking through type parameters to detect cases where the impl Trait type in an implementation captures fewer lifetimes than the corresponding RPITIT in the trait definition, e.g.: ```rust trait Foo { fn rpit() -> impl Sized + use<Self>; } impl<'a> Foo for &'a () { // This is "refining" due to not capturing `'a` which // is implied by the trait's `use<Self>`. fn rpit() -> impl Sized + use<>; // This is not "refining". fn rpit() -> impl Sized + use<'a>; } ``` This stabilization is forward compatible with adding support for this later. ### The technical details This bound is purely syntactical and does not lower to a [`Clause`](https://doc.rust-lang.org/1.79.0/nightly-rustc/rustc_middle/ty/type.ClauseKind.html) in the type system. For the purposes of the type system (and for the types team's curiosity regarding this stabilization), we have no current need to represent this as a `ClauseKind`. Since opaques already capture a variable set of lifetimes depending on edition and their syntactical position (e.g. RPIT vs RPITIT), a `use<..>` bound is just a way to explicitly rather than implicitly specify that set of lifetimes, and this only affects opaque type lowering from AST to HIR. ### FCP plan While there's much discussion of the type system here, the feature in this PR is implemented internally as a transformation that happens before lowering to the type system layer. We already support impl Trait types partially capturing the in scope lifetimes; we just currently only expose that implicitly. So, in my (errs's) view as a types team member, there's nothing for types to weigh in on here with respect to the implementation being stabilized, and I'd suggest a lang-only proposed FCP (though we'll of course CC the team below). ### Authorship and acknowledgments This stabilization report was coauthored by compiler-errors and TC. TC would like to acknowledge the outstanding and speedy work that compiler-errors has done to make this feature happen. compiler-errors thanks TC for authoring the RFC, for all of his involvement in this feature's development, and pushing the Rust 2024 edition forward. ### Open items We're doing some things in parallel here. In signaling the intention to stabilize, we want to uncover any latent issues so we can be sure they get addressed. We want to give the maximum time for discussion here to happen by starting it while other remaining miscellaneous work proceeds. That work includes: - [x] Look into `syn` support. - dtolnay/syn#1677 - dtolnay/syn#1707 - [x] Look into `rustfmt` support. - rust-lang/rust#126754 - [x] Look into `rust-analyzer` support. - rust-lang/rust-analyzer#17598 - rust-lang/rust-analyzer#17676 - [x] Look into `rustdoc` support. - rust-lang/rust#127228 - rust-lang/rust#127632 - rust-lang/rust#127658 - [x] Suggest this feature to RfL (a known nightly user). - [x] Add a chapter to the edition guide. - rust-lang/edition-guide#316 - [x] Update the Reference. - rust-lang/reference#1577 ### (Selected) implementation history * rust-lang/rfcs#3498 * rust-lang/rfcs#3617 * rust-lang/rust#123468 * rust-lang/rust#125836 * rust-lang/rust#126049 * rust-lang/rust#126753 Closes #123432. cc `@rust-lang/lang` `@rust-lang/types` `@rustbot` labels +T-lang +I-lang-nominated +A-impl-trait +F-precise_capturing Tracking: - rust-lang/rust#123432 ---- For the compiler reviewer, I'll leave some inline comments about diagnostics fallout :^) r? compiler

…ebcartwright Implement `use<>` formatting in rustfmt This PR implements formatting for precise-capturing `use<>` syntax as proposed in rust-lang#126753. The syntax is implemented as-if the `use<>` bound were a trait bound but with the `use` keyword as its path segment identifier. I opted to develop this in the rust-lang/rust tree since I'm not certain when the next rustfmt subtree sync is going to be, and I'd rather not block landing nightly support for `use<>` on something I have no control over. If ``@rust-lang/rustfmt`` would rather I move this PR over to that repository, then I would at least like to know when the next rustfmt->rust subtree sync is going to be, since stabilizing `precise_capturing` without formatting will be disruptive. This implementation is otherwise rather straightforward. Tracking: - rust-lang#123432

rustbot assigned Mark-Simulacrum Jun 20, 2024

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 20, 2024

rustbot assigned calebcartwright and unassigned Mark-Simulacrum Jun 20, 2024

This comment has been minimized.

Sign in to view

traviscross mentioned this pull request Jun 20, 2024

Tracking issue for precise_capturing syntax #123432

Closed

14 tasks

calebcartwright approved these changes Jun 21, 2024

View reviewed changes

Implement use<> formatting in rustfmt

a426d6f

compiler-errors force-pushed the use-rustfmt branch from 52dd81e to a426d6f Compare June 23, 2024 14:57

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 23, 2024

workingjubilee mentioned this pull request Jun 24, 2024

Rollup of 9 pull requests #126886

Closed

matthiaskrgr mentioned this pull request Jun 24, 2024

Rollup of 9 pull requests #126891

Merged

bors merged commit b24e3df into rust-lang:master Jun 24, 2024
6 checks passed

rustbot added this to the 1.81.0 milestone Jun 24, 2024

compiler-errors mentioned this pull request Jun 25, 2024

subtree-push 2024-06-24 rust-lang/rustfmt#6217

Merged

traviscross mentioned this pull request Jul 15, 2024

Stabilize opaque type precise capturing (RFC 3617) #127672

Merged

7 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement `use<>` formatting in rustfmt #126754

Implement `use<>` formatting in rustfmt #126754

compiler-errors commented Jun 20, 2024

rustbot commented Jun 20, 2024

rustbot commented Jun 20, 2024

compiler-errors commented Jun 20, 2024

This comment has been minimized.

compiler-errors commented Jun 20, 2024

calebcartwright commented Jun 21, 2024

calebcartwright left a comment

compiler-errors commented Jun 21, 2024 •

edited

Loading

compiler-errors commented Jun 23, 2024

bors commented Jun 23, 2024

Implement use<> formatting in rustfmt #126754

Implement use<> formatting in rustfmt #126754

Conversation

compiler-errors commented Jun 20, 2024

rustbot commented Jun 20, 2024

rustbot commented Jun 20, 2024

compiler-errors commented Jun 20, 2024

This comment has been minimized.

compiler-errors commented Jun 20, 2024

calebcartwright commented Jun 21, 2024

calebcartwright left a comment

Choose a reason for hiding this comment

compiler-errors commented Jun 21, 2024 • edited Loading

compiler-errors commented Jun 23, 2024

bors commented Jun 23, 2024

Implement `use<>` formatting in rustfmt #126754

Implement `use<>` formatting in rustfmt #126754

compiler-errors commented Jun 21, 2024 •

edited

Loading