High priority resolutions for associated variants by petrochenkov · Pull Request #57501 · rust-lang/rust

petrochenkov · 2019-01-10T22:00:24Z

In #56225 variants were assigned lowest priority during name resolution to avoid crater run and potential breakage.

This PR changes the rules to give variants highest priority instead.
Some motivation:

If variants (and their constructors) are treated as associated items, then they are obviously inherent associated items since they don't come from traits.
Inherent associated items have higher priority during resolution than associated items from traits.
The reason is that there is a way to disambiguate in favor of trait items (<Type as Trait>::Ambiguous), but there's no way to disambiguate in favor of inherent items, so they become unusable in case of ambiguities if they have low priority.
It's technically problematic to fallback from associated types to anything until lazy normalization (?) is implemented.

Crater found some regressions from this change, but they are all in type positions, e.g.

fnf() -> Self::Ambiguos{ ...}// Variant `Ambiguous` or associated type `Ambiguous`?

, so variants are not usable there right now, but they may become usable in the future if rust-lang/rfcs#2593 is accepted.
This PR keeps code like this successfully resolving, but introduces a future-compatibility lint ambiguous_associated_items that recommends rewriting it as <Self as Trait>::Ambiguous.

petrochenkov · 2019-01-10T22:00:59Z

@bors try

bors · 2019-01-10T22:01:12Z

⌛ Trying commit dcaebe0 with merge 5f78915...

[WIP] High priority resolutions for associated variants cc #56225 (comment)

petrochenkov · 2019-01-10T22:01:14Z

cc @alexreg

alexreg

Looks reasonable to me, apart from the little things I mentioned above.

bors · 2019-01-11T00:09:54Z

☀️ Test successful - checks-travis
State: approved= try=True

petrochenkov · 2019-01-11T00:35:24Z

@craterbot run start=master#6ecad338381cc3b8d56e2df22e5971a598eddd6c end=try#5f789154f114767b2d0cb9c5b6c592cb3a635e6f mode=check-only

craterbot · 2019-01-11T00:35:26Z

👌 Experiment pr-57501 created and queued.
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2019-01-11T00:35:28Z

🚧 Experiment pr-57501 is now running on agent aws-1.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2019-01-12T08:29:35Z

🎉 Experiment pr-57501 is completed!
📊 15 regressed and 0 fixed (50551 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

alexreg · 2019-01-12T17:17:12Z

@petrochenkov Looks like there are some legitimate regressions... not too many, thankfully, and no big crates. Maybe you want to open issues/PRs on them then get this PR in ASAP? This error will make backwards-compatibility for a variants-as-types implementation a lot easier too.

petrochenkov · 2019-01-12T18:32:58Z

All the regressions are from variants used in type positions where no true ambiguity exists until variant types are implemented.
It's also good that the number of root regressions is small despite hundreds of non-root regressions.

So, I think we can keep the old behavior and emit a future-compatibility warning in type positions, and just give variants high priority in other contexts.

alexreg · 2019-01-12T21:01:18Z

Sounds reasonable. I'll leave you to do that. Feel free to r? me when you're ready. (I should have rights now.)

Centril · 2019-01-12T23:38:13Z

r? @alexreg

petrochenkov · 2019-01-15T22:26:50Z

Updated.

bors · 2019-01-16T21:09:59Z

📌 Commit 01d0ae9 has been approved by alexreg

High priority resolutions for associated variants In rust-lang#56225 variants were assigned lowest priority during name resolution to avoid crater run and potential breakage. This PR changes the rules to give variants highest priority instead. Some motivation: - If variants (and their constructors) are treated as associated items, then they are obviously *inherent* associated items since they don't come from traits. - Inherent associated items have higher priority during resolution than associated items from traits. - The reason is that there is a way to disambiguate in favor of trait items (`<Type as Trait>::Ambiguous`), but there's no way to disambiguate in favor of inherent items, so they became unusable in case of ambiguities if they have low priority. - It's technically problematic to fallback from associated types to anything until lazy normalization (?) is implemented. Crater found some regressions from this change, but they are all in type positions, e.g. ```rust fn f() -> Self::Ambiguos { ... } // Variant `Ambiguous` or associated type `Ambiguous`? ``` , so variants are not usable there right now, but they may become usable in the future if rust-lang/rfcs#2593 is accepted. This PR keeps code like this successfully resolving, but introduces a future-compatibility lint `ambiguous_associated_items` that recommends rewriting it as `<Self as Trait>::Ambiguous`.

@ghost

Rollup of 10 pull requests Successful merges: - #57268 (Add a target option "merge-functions", and a corresponding -Z flag (works around #57356)) - #57476 (Move glob map use to query and get rid of CrateAnalysis) - #57501 (High priority resolutions for associated variants) - #57573 (Querify `entry_fn`) - #57610 (Fix nested `?` matchers) - #57634 (Remove an unused function argument) - #57653 (Make the contribution doc reference the guide more) - #57666 (Generalize `huge-enum.rs` test and expected stderr for more cross platform cases) - #57698 (Fix typo bug in DepGraph::try_mark_green().) - #57746 (Update README.md) Failed merges: r? @ghost

I think gluon was blacklisted due the problem in rust-lang#157 but that has since been fixed in the crate itself so gluon now compiles (verified by running crater locally). Found because I started getting the warning from rust-lang/rust#57501 in gluon_vm.

Re-add gluon* to the crater list I think gluon was blacklisted due the problem in #157 but that has since been fixed in the crate itself so gluon now compiles (verified by running crater locally). Found because I started getting the warning from rust-lang/rust#57501 in gluon_vm.

rust-highfive assigned davidtwco Jan 10, 2019

This comment has been minimized.
Sign in to view

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 10, 2019

petrochenkov added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 10, 2019

bors added a commit that referenced this pull request Jan 10, 2019
Auto merge of#57501- petrochenkov:highvar, r=<try>
5f78915
[WIP] High priority resolutions for associated variants cc #56225 (comment)

alexreg approved these changes Jan 10, 2019
View reviewed changes

Comment threadsrc/librustc/lint/builtin.rs Outdated
Comment threadsrc/librustc_typeck/lib.rs Outdated

Centril reviewed Jan 11, 2019
View reviewed changes

Comment threadsrc/test/ui/feature-gates/feature-gate-type_alias_enum_variants.rs

craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Jan 12, 2019

petrochenkov 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 Jan 12, 2019

rust-highfive unassigned davidtwco Jan 12, 2019

petrochenkov force-pushed the highvar branch from dcaebe0 to 6d9a8f5Compare January 14, 2019 23:24

petrochenkov mentioned this pull request Jan 15, 2019
Tracking issue for future-incompatbility lint ambiguous_associated_items#57644
Open
3 tasks

petrochenkov force-pushed the highvar branch from 6d9a8f5 to 83b6742Compare January 15, 2019 22:22

petrochenkov changed the title ~~[WIP] High priority resolutions for associated variants~~High priority resolutions for associated variantsJan 15, 2019

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 16, 2019

Centril mentioned this pull request Jan 17, 2019
Rollup of 19 pull requests #57687
Closed

Centril mentioned this pull request Jan 17, 2019
Rollup of 19 pull requests #57688
Closed

Centril mentioned this pull request Jan 17, 2019
Rollup of 18 pull requests #57690
Closed

Centril mentioned this pull request Jan 18, 2019
Rollup of 22 pull requests #57727
Closed

Centril mentioned this pull request Jan 18, 2019
Rollup of 21 pull requests #57732
Closed

Centril mentioned this pull request Jan 19, 2019
Rollup of 10 pull requests #57752
Merged

bors merged commit 01d0ae9 into rust-lang:masterJan 19, 2019

Centril mentioned this pull request Jan 26, 2019
Tracking issue for RFC 2338, "Type alias enum variants" #49683
Closed
4 tasks

Marwes mentioned this pull request Jan 28, 2019
Re-add gluon* to the crater list rust-lang/crater#396
Merged

Centril mentioned this pull request Apr 17, 2019
Make deprecation lint ambiguous_associated_items deny-by-default #59928
Merged

petrochenkov deleted the highvar branch June 5, 2019 16:28

Centril mentioned this pull request Jun 9, 2019
Stabilize type_alias_enum_variants in Rust 1.37.0 #61682
Merged

clubby789 mentioned this pull request Nov 3, 2023
Enum variants shadow associated constants with no warning #117558
Closed

Uh oh!

Uh oh!

Conversation

petrochenkov commented Jan 10, 2019• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

petrochenkov commented Jan 10, 2019

Uh oh!

bors commented Jan 10, 2019

Uh oh!

petrochenkov commented Jan 10, 2019

Uh oh!

alexreg left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

bors commented Jan 11, 2019

Uh oh!

petrochenkov commented Jan 11, 2019

Uh oh!

craterbot commented Jan 11, 2019

Uh oh!

craterbot commented Jan 11, 2019

Uh oh!

Uh oh!

craterbot commented Jan 12, 2019

Uh oh!

alexreg commented Jan 12, 2019

Uh oh!

petrochenkov commented Jan 12, 2019

Uh oh!

alexreg commented Jan 12, 2019

Uh oh!

Centril commented Jan 12, 2019

Uh oh!

petrochenkov commented Jan 15, 2019

Uh oh!

bors commented Jan 16, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

petrochenkov commented Jan 10, 2019•
edited
Loading