Rework `feature(precise_capturing)` to represent `use<...>` as a syntactical bound #126049

compiler-errors · 2024-06-05T21:06:09Z

Reworks precise_capturing for a recent lang-team consensus.

Specifically:

The conclusion of the team is that we'll make use<..> a bound. That is, we'll support impl use<..> + Trait, impl Trait + use<..>, etc.

For now, we will support at most one such bound in a list of bounds, and semantically we'll only support these bounds in the item bounds of RPIT-like impl Trait opaque types (i.e., in the places discussed in the RFC).

Lang decision in favor of this approach:

Syntax for precise capturing: impl Trait + use<..> #125836 (comment)

Tracking:

Tracking issue for precise_capturing syntax #123432

rustbot · 2024-06-06T13:05:58Z

HIR ty lowering was modified

cc @fmease

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

compiler-errors · 2024-06-06T13:37:25Z

src/tools/rustfmt/src/types.rs

@@ -930,7 +927,7 @@ fn rewrite_bare_fn(

 fn is_generic_bounds_in_order(generic_bounds: &[ast::GenericBound]) -> bool {
    let is_trait = |b: &ast::GenericBound| match b {
-        ast::GenericBound::Outlives(..) => false,
+        ast::GenericBound::Outlives(..) | ast::GenericBound::Use(..) => false,
        ast::GenericBound::Trait(..) => true,
    };
    let is_lifetime = |b: &ast::GenericBound| !is_trait(b);


This code (and the other rustfmt tweaks) is almost certainly going to handle use<...> incorrectly. I'm somewhat concerned that the code is not going to be easy to make correct, and this is likely going to cause more churn if we stabilize use<...> without proper formatting.

this is kind of tracked in the tracking issue with the rustfmt checkbox. Do you think we need to add info to that or is it obvious for any rustfmt implementor?

I can add some more FIXMEs to make it obvious

compiler-errors · 2024-06-06T15:21:55Z

r? oli-obk

traviscross · 2024-06-06T16:20:37Z

compiler/rustc_feature/src/unstable.rs

@@ -563,7 +563,7 @@ declare_features! (
    (unstable, optimize_attribute, "1.34.0", Some(54882)),
    /// Allows postfix match `expr.match { ... }`
    (unstable, postfix_match, "1.79.0", Some(121618)),
-    /// Allows `use<'a, 'b, A, B>` in `impl use<...> Trait` for precise capture of generic args.
+    /// Allows `use<'a, 'b, A, B>` in `impl Trait + use<...>` for precise capture of generic args.
    (incomplete, precise_capturing, "1.79.0", Some(123432)),


The RFC has been accepted. This no longer needs to be marked incomplete. Not sure whether we want to handle that in this PR or separately.

Suggested change

(incomplete, precise_capturing, "1.79.0", Some(123432)),

(unstable, precise_capturing, "1.79.0", Some(123432)),

I can do it in this commit -- the only thing that needs to be done is deny it for RPITIT, but that wont cause ICEs so I wouldnt consider it incomplete

compiler/rustc_parse/src/parser/ty.rs

tests/ui/impl-trait/precise-capturing/bad-lifetimes.rs

oli-obk · 2024-06-07T09:12:04Z

compiler/rustc_ast_lowering/src/lib.rs

+                            // Ignore `use` syntax since that is not valid in objects.
+                            GenericBound::Use(..) => None,


we could emit the error here instead of in validation.

Edit Hmm I guess that would allow using it in cfged out code tho, nevermind

well we don't even parse dyn use<> currently. I will delay a bug here.

compiler/rustc_ast_lowering/src/lib.rs

oli-obk · 2024-06-07T09:16:00Z

tests/ui/impl-trait/precise-capturing/illegal-positions.rs

Test which errors are also emitted if everything is cfged out

tests/ui/impl-trait/precise-capturing/duplicated-use.rs

oli-obk · 2024-06-07T09:19:13Z

src/tools/rustfmt/src/types.rs

@@ -930,7 +927,7 @@ fn rewrite_bare_fn(

 fn is_generic_bounds_in_order(generic_bounds: &[ast::GenericBound]) -> bool {
    let is_trait = |b: &ast::GenericBound| match b {
-        ast::GenericBound::Outlives(..) => false,
+        ast::GenericBound::Outlives(..) | ast::GenericBound::Use(..) => false,
        ast::GenericBound::Trait(..) => true,
    };
    let is_lifetime = |b: &ast::GenericBound| !is_trait(b);


this is kind of tracked in the tracking issue with the rustfmt checkbox. Do you think we need to add info to that or is it obvious for any rustfmt implementor?

… in parse_precise_capturing_syntax

oli-obk · 2024-06-18T07:56:52Z

@bors r+

bors · 2024-06-18T07:56:55Z

📌 Commit 2273747 has been approved by oli-obk

It is now in the queue for this repository.

bors · 2024-06-18T09:30:42Z

⌛ Testing commit 2273747 with merge c1f62a7...

bors · 2024-06-18T11:46:28Z

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c1f62a7 to master...

rust-timer · 2024-06-18T17:01:40Z

Finished benchmarking commit (c1f62a7): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	7
Improvements ✅ (secondary)	-0.4%	[-0.6%, -0.2%]	12
All ❌✅ (primary)	-0.2%	[-0.2%, -0.2%]	7

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results (secondary -1.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.9%	[-2.2%, -1.6%]	2
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 670.725s -> 671.456s (0.11%)
Artifact size: 320.46 MiB -> 320.48 MiB (0.01%)

…=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

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 5, 2024

compiler-errors force-pushed the rework-use branch from 9ca8fb5 to 0387724 Compare June 5, 2024 21:06

This comment has been minimized.

Sign in to view

traviscross mentioned this pull request Jun 6, 2024

Tracking issue for precise_capturing syntax #123432

Closed

14 tasks

traviscross added the F-precise_capturing `#![feature(precise_capturing)]` label Jun 6, 2024

compiler-errors force-pushed the rework-use branch from 0387724 to 438b741 Compare June 6, 2024 13:03

compiler-errors marked this pull request as ready for review June 6, 2024 13:05

compiler-errors commented Jun 6, 2024

View reviewed changes

rustbot assigned oli-obk Jun 6, 2024

traviscross reviewed Jun 6, 2024

View reviewed changes

oli-obk requested changes Jun 7, 2024

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 7, 2024

compiler-errors force-pushed the rework-use branch from 438b741 to f499fd0 Compare June 17, 2024 02:07

This comment has been minimized.

Sign in to view

compiler-errors force-pushed the rework-use branch from f499fd0 to c3c1bbf Compare June 17, 2024 02:22

compiler-errors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 17, 2024

This comment has been minimized.

Sign in to view

compiler-errors force-pushed the rework-use branch from c3c1bbf to c38dabc Compare June 17, 2024 02:41

tmandry added the I-lang-nominated Nominated for discussion during a lang team meeting. label Jun 18, 2024

compiler-errors added 6 commits June 17, 2024 22:35

Make parse_seq_to_before_tokens take expected/nonexpected tokens, use…

68bd001

… in parse_precise_capturing_syntax

Rework precise capturing syntax

b1efe1a

Add tests for illegal use bound syntax

f66558d

Detect duplicates

2e03130

Fix rustfmt

bd83649

Fix other tools

579bc3c

Delay a bug and mark precise_capturing as not incomplete

2273747

compiler-errors force-pushed the rework-use branch from c38dabc to 2273747 Compare June 18, 2024 02:35

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 18, 2024

bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 18, 2024

bors merged commit c1f62a7 into rust-lang:master Jun 18, 2024
7 checks passed

rustbot added this to the 1.81.0 milestone Jun 18, 2024

This was referenced Jun 18, 2024

Improve parse item fallback #125388

Open

Represent type-level consts with new-and-improved hir::ConstArg #125915

Merged

Replace all &DiagCtxt with a DiagCtxtHandle<'_> wrapper type #126623

Merged

tmandry removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Jun 18, 2024

compiler-errors mentioned this pull request Jul 13, 2024

Stabilize opaque type precise capturing (RFC 3617) #127672

Merged

7 tasks

matthiaskrgr mentioned this pull request Sep 1, 2024

ICE: expected lifetime parameter, but found another generic parameter #129850

Closed

jieyouxu mentioned this pull request Oct 25, 2024

ICE: could not resolve DefId #132126

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rework `feature(precise_capturing)` to represent `use<...>` as a syntactical bound #126049

Rework `feature(precise_capturing)` to represent `use<...>` as a syntactical bound #126049

compiler-errors commented Jun 5, 2024 •

edited

Loading

This comment has been minimized.

rustbot commented Jun 6, 2024

compiler-errors Jun 6, 2024

oli-obk Jun 7, 2024

compiler-errors Jun 7, 2024

compiler-errors commented Jun 6, 2024

traviscross Jun 6, 2024 •

edited

Loading

compiler-errors Jun 6, 2024

oli-obk Jun 7, 2024

compiler-errors Jun 7, 2024

oli-obk Jun 7, 2024

oli-obk Jun 7, 2024

This comment has been minimized.

This comment has been minimized.

oli-obk commented Jun 18, 2024

bors commented Jun 18, 2024

bors commented Jun 18, 2024

bors commented Jun 18, 2024

rust-timer commented Jun 18, 2024

	(incomplete, precise_capturing, "1.79.0", Some(123432)),
	(unstable, precise_capturing, "1.79.0", Some(123432)),

		// Ignore `use` syntax since that is not valid in objects.
		GenericBound::Use(..) => None,

Rework feature(precise_capturing) to represent use<...> as a syntactical bound #126049

Rework feature(precise_capturing) to represent use<...> as a syntactical bound #126049

Conversation

compiler-errors commented Jun 5, 2024 • edited Loading

This comment has been minimized.

rustbot commented Jun 6, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

compiler-errors commented Jun 6, 2024

traviscross Jun 6, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment has been minimized.

This comment has been minimized.

oli-obk commented Jun 18, 2024

bors commented Jun 18, 2024

bors commented Jun 18, 2024

bors commented Jun 18, 2024

rust-timer commented Jun 18, 2024

Overall result: ✅ improvements - no action needed

Rework `feature(precise_capturing)` to represent `use<...>` as a syntactical bound #126049

Rework `feature(precise_capturing)` to represent `use<...>` as a syntactical bound #126049

compiler-errors commented Jun 5, 2024 •

edited

Loading

traviscross Jun 6, 2024 •

edited

Loading