High priority resolutions for associated variants #57501

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.

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.

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.

src/librustc/lint/builtin.rs

src/librustc_typeck/lib.rs

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

src/test/ui/feature-gates/feature-gate-type_alias_enum_variants.rs

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

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

src/librustc/lint/builtin.rs Outdated Show resolved Hide resolved

src/librustc_typeck/lib.rs Outdated Show resolved Hide resolved

Centril reviewed Jan 11, 2019

View reviewed changes

src/test/ui/feature-gates/feature-gate-type_alias_enum_variants.rs Outdated Show resolved Hide resolved

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 assigned alexreg and unassigned davidtwco Jan 12, 2019

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

petrochenkov mentioned this pull request Jan 15, 2019

Tracking issue for ambiguous_associated_items compatibility lint #57644

Open

3 tasks

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

petrochenkov changed the title ~~[WIP] High priority resolutions for associated variants~~ High priority resolutions for associated variants Jan 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:master Jan 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

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

High priority resolutions for associated variants #57501

High priority resolutions for associated variants #57501

petrochenkov commented Jan 10, 2019 •

edited

Loading

This comment has been minimized.

petrochenkov commented Jan 10, 2019

bors commented Jan 10, 2019

petrochenkov commented Jan 10, 2019

alexreg left a comment

bors commented Jan 11, 2019

petrochenkov commented Jan 11, 2019

craterbot commented Jan 11, 2019

craterbot commented Jan 11, 2019

craterbot commented Jan 12, 2019

alexreg commented Jan 12, 2019

petrochenkov commented Jan 12, 2019

alexreg commented Jan 12, 2019

Centril commented Jan 12, 2019

bors commented Jan 16, 2019

High priority resolutions for associated variants #57501

High priority resolutions for associated variants #57501

Conversation

petrochenkov commented Jan 10, 2019 • edited Loading

This comment has been minimized.

petrochenkov commented Jan 10, 2019

bors commented Jan 10, 2019

petrochenkov commented Jan 10, 2019

alexreg left a comment

Choose a reason for hiding this comment

bors commented Jan 11, 2019

petrochenkov commented Jan 11, 2019

craterbot commented Jan 11, 2019

craterbot commented Jan 11, 2019

craterbot commented Jan 12, 2019

alexreg commented Jan 12, 2019

petrochenkov commented Jan 12, 2019

alexreg commented Jan 12, 2019

Centril commented Jan 12, 2019

bors commented Jan 16, 2019

petrochenkov commented Jan 10, 2019 •

edited

Loading