Compute variances for lazy type aliases #114253

fmease · 2023-07-30T14:27:41Z

CC @oli-obk
r? types

compiler/rustc_hir_analysis/src/variance/constraints.rs

fmease · 2023-07-30T19:47:58Z

I'm pretty sure that all occurrences of tcx.features().lazy_type_alias in this patch should actually be tcx.features().lazy_type_alias || tcx.type_of(def_id).subst_identity().has_opaque_types() to consolidate (lazy) type aliases and TAITs.

I tried that locally and all UI tests succeeded except for

a single TAIT test, namely type-alias-impl-trait/obligation_ice.rs (pass → fail): For some reason, the type parameter A on type alias I gets flagged as unused / bivariant leading to an error. Maybe it has something to do with the way variances are computed for opaques (I does contain one).
several inherent associated type tests (pass / fail → cycle error): Since their currently implementation is makeshift & fragile, the breakage isn't that noteworthy I'd say.

I don't think I know enough about TAITs to be able to fix point (1).

@rustbot ready

oli-obk · 2023-08-01T07:33:34Z

compiler/rustc_hir_analysis/src/variance/constraints.rs

+                if tcx.features().lazy_type_alias && let DefKind::TyAlias = tcx.def_kind(def_id) {
+                    self.add_constraints_from_ty(current_item, ty, self.covariant);


Leave a comment explaining that we need to check the DefKind, because type_of(def_id) returns the type behind the alias, not ty::Alias(ty::Weak, ..)

oli-obk · 2023-08-01T07:43:03Z

a single TAIT test, namely type-alias-impl-trait/obligation_ice.rs (pass → fail): For some reason, the type parameter A on type alias I gets flagged as unused / bivariant leading to an error. Maybe it has something to do with the way variances are computed for opaques (I does contain one).

you could dump the variance (RUSTC_LOG=[crate_variances]) and the hidden type (RUSTC_LOG=[type_of]) to collect some more information on this. It seems like the right approach that you're doing.

Note that that test's RPIT equivalent does not compile (https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b00a68250b843d20bfa300f35fc7c29c) without also adding a where 'b: 'a bound to the function. So something is fishy here anyway

oli-obk · 2023-08-03T07:31:27Z

tests/rustdoc-json/type/inherent_associated_type_bound.rs

why is this test affected? It has neither opaque types nor the lazy type alias feature gate

fmease · 2023-08-03T09:20:09Z

Note that inherent associated types bound to type aliases now lead to cycle errors as previously touched upon. In the relevant UI tests I've replaced type aliases with functions wherever possible.

Superficially the cycles are caused by the added type_of calls in variances_of but more fundamentally the current implementation of inherent associated types (written by me) is prone to such errors since selection (which tries to acquire a (normalized) ParamEnv) happens in astconv.

I'm pretty sure those regressions are unavoidable at the present time. I plan on attempting an IAT rewrite at some point of which I'm not sure if it will pan out or not.

oli-obk · 2023-08-03T09:57:24Z

@bors r+

bors · 2023-08-03T09:57:26Z

📌 Commit 6f5d855 has been approved by oli-obk

It is now in the queue for this repository.

…ty-aliases, r=oli-obk Compute variances for lazy type aliases Fixes rust-lang#114221. CC `@oli-obk` r? types

…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#114022 (Perform OpaqueCast field projection on HIR, too.) - rust-lang#114253 (Compute variances for lazy type aliases) - rust-lang#114355 (resolve before canonicalization in new solver, ICE if unresolved) - rust-lang#114427 (Handle non-utf8 rpaths (fix FIXME)) - rust-lang#114440 (bootstrap: config: fix version comparison bug) r? `@ghost` `@rustbot` modify labels: rollup

…e-specific, r=oli-obk Store the laziness of type aliases in their `DefKind` Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not. With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*: Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates. As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions. --- This fixes rust-lang#114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](rust-lang#114253 (comment))) as outlined above. Now it does hold. `@rustbot` label F-lazy_type_alias r? `@oli-obk`

…c, r=oli-obk Store the laziness of type aliases in their `DefKind` Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not. With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*: Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates. As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions. --- This fixes #114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](rust-lang/rust#114253 (comment))) as outlined above. Now it does hold. `@rustbot` label F-lazy_type_alias r? `@oli-obk`

rustbot assigned jackh726 Jul 30, 2023

This comment has been minimized.

Sign in to view

fmease marked this pull request as draft July 30, 2023 16:49

This comment was marked as outdated.

Sign in to view

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 Jul 30, 2023

fmease force-pushed the compute-variances-for-lazy-ty-aliases branch from 0e5d01b to 253495a Compare July 30, 2023 19:35

fmease commented Jul 30, 2023

View reviewed changes

compiler/rustc_hir_analysis/src/variance/constraints.rs Outdated Show resolved Hide resolved

rustbot 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 Jul 30, 2023

fmease marked this pull request as ready for review July 30, 2023 19:48

oli-obk reviewed Aug 1, 2023

View reviewed changes

fmease marked this pull request as draft August 1, 2023 16:17

fmease force-pushed the compute-variances-for-lazy-ty-aliases branch from 253495a to 1abe10a Compare August 2, 2023 09:39

fmease marked this pull request as ready for review August 2, 2023 09:40

fmease force-pushed the compute-variances-for-lazy-ty-aliases branch from 1abe10a to 33faad6 Compare August 2, 2023 09:53

This comment has been minimized.

Sign in to view

fmease mentioned this pull request Aug 2, 2023

Rollup of 5 pull requests #114366

Closed

fmease force-pushed the compute-variances-for-lazy-ty-aliases branch from 33faad6 to 16e3b80 Compare August 2, 2023 23:05

This comment has been minimized.

Sign in to view

Compute variances for lazy type aliases

263a0de

Handle inherent associated types fallout

6f5d855

fmease force-pushed the compute-variances-for-lazy-ty-aliases branch from 16e3b80 to 6f5d855 Compare August 3, 2023 00:19

rustbot added the A-rustdoc-json Area: Rustdoc JSON backend label Aug 3, 2023

oli-obk reviewed Aug 3, 2023

View reviewed changes

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 Aug 3, 2023

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Aug 3, 2023

Rollup merge of rust-lang#114253 - fmease:compute-variances-for-lazy-…

056587b

…ty-aliases, r=oli-obk Compute variances for lazy type aliases Fixes rust-lang#114221. CC `@oli-obk` r? types

This was referenced Aug 3, 2023

Rollup of 7 pull requests #114436

Closed

Rollup of 5 pull requests #114451

Merged

bors merged commit 5ea536b into rust-lang:master Aug 4, 2023
11 checks passed

rustbot added this to the 1.73.0 milestone Aug 4, 2023

fmease deleted the compute-variances-for-lazy-ty-aliases branch August 4, 2023 10:59

matthiaskrgr mentioned this pull request Aug 4, 2023

ICE: lazy type alias: IOOB compiler/rustc_hir_analysis/src/variance/constraints.rs #114468

Closed

fmease mentioned this pull request Aug 6, 2023

Make the laziness of type aliases dependent on the defining crate #114566

Merged

GuillaumeGomez mentioned this pull request Oct 5, 2023

Tracking issue for lazy type aliases #112792

Open

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Compute variances for lazy type aliases #114253

Compute variances for lazy type aliases #114253

fmease commented Jul 30, 2023 •

edited

Loading

This comment has been minimized.

This comment was marked as outdated.

fmease commented Jul 30, 2023 •

edited

Loading

oli-obk Aug 1, 2023

oli-obk commented Aug 1, 2023

This comment has been minimized.

This comment has been minimized.

oli-obk Aug 3, 2023

fmease commented Aug 3, 2023

oli-obk commented Aug 3, 2023

bors commented Aug 3, 2023

		if tcx.features().lazy_type_alias && let DefKind::TyAlias = tcx.def_kind(def_id) {
		self.add_constraints_from_ty(current_item, ty, self.covariant);

Compute variances for lazy type aliases #114253

Compute variances for lazy type aliases #114253

Conversation

fmease commented Jul 30, 2023 • edited Loading

This comment has been minimized.

This comment was marked as outdated.

fmease commented Jul 30, 2023 • edited Loading

oli-obk Aug 1, 2023

Choose a reason for hiding this comment

oli-obk commented Aug 1, 2023

This comment has been minimized.

This comment has been minimized.

oli-obk Aug 3, 2023

Choose a reason for hiding this comment

fmease commented Aug 3, 2023

oli-obk commented Aug 3, 2023

bors commented Aug 3, 2023

fmease commented Jul 30, 2023 •

edited

Loading

fmease commented Jul 30, 2023 •

edited

Loading