-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compute variances for lazy type aliases #114253
Compute variances for lazy type aliases #114253
Conversation
This comment has been minimized.
This comment has been minimized.
This comment was marked as outdated.
This comment was marked as outdated.
0e5d01b
to
253495a
Compare
I'm pretty sure that all occurrences of I tried that locally and all UI tests succeeded except for
I don't think I know enough about TAITs to be able to fix point (1). @rustbot ready |
if tcx.features().lazy_type_alias && let DefKind::TyAlias = tcx.def_kind(def_id) { | ||
self.add_constraints_from_ty(current_item, ty, self.covariant); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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, ..)
you could dump the variance ( 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 |
253495a
to
1abe10a
Compare
1abe10a
to
33faad6
Compare
This comment has been minimized.
This comment has been minimized.
33faad6
to
16e3b80
Compare
This comment has been minimized.
This comment has been minimized.
16e3b80
to
6f5d855
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this test affected? It has neither opaque types nor the lazy type alias feature gate
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 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. |
@bors r+ |
…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`
Fixes #114221.
CC @oli-obk
r? types