Compute variances for lazy type aliases by fmease · Pull Request #114253 · rust-lang/rust

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

CC @oli-obk
r? types

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

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

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 Fixesrust-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 fixesrust-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 253495aCompare July 30, 2023 19:35

fmease commented Jul 30, 2023
View reviewed changes

Comment threadcompiler/rustc_hir_analysis/src/variance/constraints.rs Outdated

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 1abe10aCompare 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 33faad6Compare 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 16e3b80Compare 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 6f5d855Compare 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 ofrust-lang#114253- fmease:compute-variances-for-lazy-…
056587b
…ty-aliases, r=oli-obk Compute variances for lazy type aliases Fixesrust-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:masterAug 4, 2023

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 checked type aliases #112792
Open
6 tasks

fmease mentioned this pull request Apr 24, 2025
Free type aliases should not require all generic parameters to be used #140230
Closed

Navigation Menu

Uh oh!

Uh oh!

Compute variances for lazy type aliases - #114253

Compute variances for lazy type aliases#114253
bors merged 2 commits into
rust-lang:masterfrom
fmease:compute-variances-for-lazy-ty-aliases

fmease commented Jul 30, 2023•
edited
Loading

Uh oh!

This comment has been minimized.

This comment was marked as outdated.

Uh oh!

fmease commented Jul 30, 2023•
edited
Loading

Uh oh!

oli-obkAug 1, 2023

Uh oh!

oli-obk commented Aug 1, 2023

Uh oh!

This comment has been minimized.

This comment has been minimized.

oli-obkAug 3, 2023

Uh oh!

fmease commented Aug 3, 2023

Uh oh!

oli-obk commented Aug 3, 2023

Uh oh!

bors commented Aug 3, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Uh oh!

Conversation

fmease commented Jul 30, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment was marked as outdated.

Uh oh!

fmease commented Jul 30, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oli-obkAug 1, 2023

Choose a reason for hiding this comment

Uh oh!

oli-obk commented Aug 1, 2023

Uh oh!

This comment has been minimized.

This comment has been minimized.

oli-obkAug 3, 2023

Choose a reason for hiding this comment

Uh oh!

fmease commented Aug 3, 2023

Uh oh!

oli-obk commented Aug 3, 2023

Uh oh!

bors commented Aug 3, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

fmease commented Jul 30, 2023•
edited
Loading

fmease commented Jul 30, 2023•
edited
Loading