Remove `impl Foo for .. {}` in favor `auto trait Foo {}` #46480

leoyvens · 2017-12-03T22:36:12Z

The new syntax was introduced and the old one deprecated in #45247. This removes the old syntax and simplifies some code as a result. Some errors that were possible with the old syntax no longer make sense. WF checking is moved to an ast validation.

There is some conflict with #46455, nothing serious. I guess this PR should be preferred where there is a conflict.

leoyvens · 2017-12-04T13:27:11Z

Got error on rustdoc's error index test, it's not parsing auto trait. It seems the bootstrap rustdoc was not updated yet?

kennytm · 2017-12-04T16:55:58Z

@leodasvacas Try to add a # fn main() {} at the end of the E0198 test. It seems rustdoc wraps a fn main() { … } around the code body. It also shows auto trait cannot be declared inside a function 🤔

https://play.rust-lang.org/?gist=5e9637830e8e6cb05b3f48a8e7bc5cf7&version=nightly

leoyvens · 2017-12-04T18:28:05Z

@kennytm Nailed it as usual, fixed it.

kennytm · 2017-12-04T18:52:45Z

src/libsyntax/parse/parser.rs

        // Our goal here is to parse an arbitrary path `a::b::c` but not something that starts
        // like a path (1 token), but it fact not a path.
        // `union::b::c` - path, `union U { ... }` - not a path.
        // `crate::b::c` - path, `crate struct S;` - not a path.
        } else if self.token.is_path_start() &&
                  !self.token.is_qpath_start() &&
                  !self.is_union_item() &&
-                  !self.is_crate_vis() {
+                  !self.is_crate_vis() && 


kennytm · 2017-12-04T18:53:08Z

src/libsyntax/parse/parser.rs

+        (self.token.is_keyword(keywords::Auto)
+            && self.look_ahead(1, |t| t.is_keyword(keywords::Trait)))
+        || // unsafe auto trait
+        (self.token.is_keyword(keywords::Unsafe) && 


Trailing whitespace

[00:03:11] tidy error: /checkout/src/libsyntax/parse/parser.rs:3946: trailing whitespace [00:03:11] tidy error: /checkout/src/libsyntax/parse/parser.rs:4060: trailing whitespace

petrochenkov · 2017-12-04T21:45:08Z

src/librustc_passes/ast_validation.rs

-                        self.err_handler().span_err(item.span,
-                                                    "auto traits cannot have generics");
+                        struct_span_err!(self.session, item.span, E0567,
+                                        "Auto traits cannot have type parameters").emit();


"Auto" -> "auto", error messages are not normally capitalized.
Also "type parameters" -> "generic parameters" and the condition a few lines above is incorrect, it should use !generics.is_parameterized(), because lifetime parameters are disallowed as well (they are currently rejected on impls for ..).

petrochenkov · 2017-12-04T21:45:26Z

src/librustc_passes/ast_validation.rs

-                        self.err_handler().span_err(item.span,
-                                                    "auto traits cannot have super traits");
+                        struct_span_err!(self.session, item.span, E0568,
+                                        "Auto traits cannot have predicates").emit();


The message was better before, IMO.

Should I use the new error code and the old error message?

Yes, why not.

petrochenkov · 2017-12-04T21:52:02Z

src/librustc_typeck/diagnostics.rs

    E0533, // `{}` does not name a unit variant, unit struct or a constant
 //  E0563, // cannot determine a type for this `impl Trait`: {} // removed in 6383de15
    E0564, // only named lifetimes are allowed in `impl Trait`,
           // but `{}` was found in the type `{}`
-    E0567, // auto traits can not have type parameters
-    E0568, // auto-traits can not have predicates,


Could you comment out the obsoleted error codes instead of removing them?

Tidy is merciless, it gives me duplicate error codes even if it's commented out.

Ah, right, they are not removed, just moved to AST validation.

petrochenkov · 2017-12-04T21:58:42Z

src/libsyntax/parse/parser.rs

@@ -6167,7 +6150,8 @@ impl<'a> Parser<'a> {
            let is_auto = if self.eat_keyword(keywords::Trait) {
                IsAuto::No
            } else {
-                self.eat_auto_trait();
+                self.eat_keyword(keywords::Auto);


Rule of thumb: eat_keyword shouldn't be used unless you use the returned result.
expect_keyword or simply bump would be better here.

petrochenkov · 2017-12-04T22:11:31Z

LGTM, modulo comments.
I think this should be landed before #46455.

The only question is - is it too soon to remove this or not?
Should we wait a few more weeks until the new auto trait syntax hits a stable release?
I'm nominating this so lang team could briefly discuss this and confirm "yep, let's remove this" (or not).
Also pinging a couple of people from the Servo/nightly ecosystem @dtolnay @SimonSapin

SimonSapin · 2017-12-04T22:20:59Z

I general we only deprecate or remove stuff once the replacement has reached the stable channel. If a project (even using unstable features) builds without warnings on all three release channels, it should be possible to keep it that way.

bors · 2017-12-07T21:08:33Z

☔ The latest upstream changes (presumably #46532) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2017-12-14T23:38:36Z

☔ The latest upstream changes (presumably #45047) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2017-12-19T04:25:16Z

☔ The latest upstream changes (presumably #45525) made this pull request unmergeable. Please resolve the merge conflicts.

nikomatsakis · 2017-12-20T21:27:21Z

@SimonSapin

I general we only deprecate or remove stuff once the replacement has reached the stable channel. If a project (even using unstable features) builds without warnings on all three release channels, it should be possible to keep it that way.

Can you say a bit more about this? Are you imagining that e.g. the unstable syntax is removed with #[cfg]?

SimonSapin · 2017-12-20T21:31:55Z

Uh, what I wrote doesn’t make sense. A project that uses unstable features cannot build on beta or stable. I was thinking of deprecating stable features. Never mind me :)

bors · 2017-12-21T11:01:00Z

☔ The latest upstream changes (presumably #46754) made this pull request unmergeable. Please resolve the merge conflicts.

hanna-kruppe · 2018-01-06T14:55:21Z

You can blame crossbeam if you want (I wouldn't, this particular breakage is only obvious in hindsight -- perfectly competent programmers could have missed it, and indeed did). That doesn't change the fact that countless transitive dependencies of crossbeam would stop compiling on stable for no good reason -- there's no soundness bug and no gross negligence on crossbeam's part, and preventing the breakage isn't even difficult AFAICT. Breaking all this code and forcing it to update would be user-hostile IMO.

bluss · 2018-01-06T14:58:52Z

@rkruppe What about splitting the deprecation so that it functionally stops working, but it still parses (and emits some kind of warning?)

hanna-kruppe · 2018-01-06T15:02:53Z

@bluss That's pretty much what I suggested earlier, just without the warning. I don't see a big need for a warning -- it can just error if the old syntax remains after cfg stripping, and be silently stripped otherwise. But that's a minor difference. The important part is that the old syntax still parses but emits an error soon after cfg stripping.

petrochenkov · 2018-01-06T15:06:34Z

Ha, this is an interesting issue.
It looks like we can't remove any old syntax from the parser if stable crates can use

#[cfg(nightly)]
old_syntax

In this case we need to keep minimal support for any old syntax in the parser and AST (e.g. ItemKind::Obsolete(ObsoleteKind)) and report errors a bit later, at least after configuration (in AST validation, for example).

However, the larger effect seems pretty scary - we can't experiment with any new features in rustc if they require parser support because we'll may have to keep this support forever.

dtolnay · 2018-01-06T15:17:58Z

However, the larger effect seems pretty scary - we can't experiment with any new features in rustc if they require parser support because we'll may have to keep this support forever.

Lazily parsing item bodies would mitigate this to some extent right?

#[cfg(unstable)]
mod future {
    ~wacky FUTURE _syntax!

    impl RemovedSyntax for .. {}
}

If the braced module body is parsed after cfg stripping, this should be okay. We already support this because it is what happens for out-of-line modules #[cfg(unstable)] mod future;.

hanna-kruppe · 2018-01-06T15:24:23Z

However, the larger effect seems pretty scary - we can't experiment with any new features in rustc if they require parser support because we'll may have to keep this support forever.

Yeah, quite unfortunate. There is one mitigating factor, though: Any such features introduced now or in the future will have the same problem (parser error even if cfg'd out) on all previous releases. Therefore, it's reasonably possible that a crate author that makes the same mistake the crossbeam authors made will get bug reports from users on old stable releases, alerting them of the problem. impl Trait for .. {} was grandfathered in from before 1.0 so it didn't benefit from this.

We could declare such changes "acceptable breakage" and start recommending crates use macros for conditional use of nightly-only syntax features. If enough crates follow this guideline (aided by the mitigating factor described above), or the feature was never in widespread use anyway, we could sometimes get away with just removing parser support. But crossbeam is big enough that we really shouldn't break it even if that had been long-standing policy. It's still possible that any given feature winds up in a popular crate that cfg-gated it improperly, but it hopefully limits the amount of obsolete syntax the parser needs to accumulate support for.

petrochenkov · 2018-01-06T15:40:40Z

@dtolnay
Hiding the unstable syntax in an out-of-line module or in a macro would work right now, without adding lazy parsing of in-line modules, but it didn't help crossbeam that used impl for .. without any lazily parseable "container".
So it's probably something that needs to be "fixed" by teaching in the first place (and using CI with older rustc versions), as @rkruppe described in #46480 (comment).

leoyvens · 2018-01-06T22:29:27Z

I agree the current impact of breakage here is not acceptable. I'll update this patch to have the minimum necessary support for the deprecated syntax. @petrochenkov is it viable to support this only in the parser but not in the AST?

petrochenkov · 2018-01-06T22:42:38Z

@leodasvacas

is it viable to support this only in the parser but not in the AST?

The impl for .. item should leave at least some trace, otherwise you won't be able to report an error after cfg expansion.
Keeping it in AST should be the simplest solution.

bors · 2018-01-07T03:43:19Z

☔ The latest upstream changes (presumably #47156) made this pull request unmergeable. Please resolve the merge conflicts.

leoyvens · 2018-01-08T16:21:51Z

@petrochenkov Alright, do we need it in HIR also, or can we error if we encounter it in lowering?

When the new versions of crossbeam get a sufficiently large share of the daily downloads in crates.io, perhaps we may reconsider completely dropping support for the old syntax.

petrochenkov · 2018-01-08T16:43:24Z

@leodasvacas

Alright, do we need it in HIR also, or can we error if we encounter it in lowering?

No, no HIR, no pretty-printing support or anything, the single purpose of it is to report an error at some point (in AST validation or during lowering to HIR), after that it's no longer necessary.

petrochenkov · 2018-01-10T15:30:54Z

@leodasvacas
Actually, could you use the name ItemKind::Err(ErrItemKind) for the new item? It's consistent with other similar "erroneous" fragments in AST and can be used for some other things in the future, not related to obsolescence.
Using and impl for TyKind::Err would be even simpler (no changes to AST).

petrochenkov · 2018-01-13T14:18:07Z

@leodasvacas
I'd like to land this PR sooner.
I can rebase it and finish the parsing stuff if you don't have time.

leoyvens · 2018-01-13T14:33:18Z

Sorry for being slow here, I'll have time next week, if you want to do it sooner you're welcome! Em 13/01/2018 12:18 PM, "Vadim Petrochenkov" <[email protected]> escreveu:

…

@leodasvacas <https://github.com/leodasvacas> I'd like to land this PR sooner. I can rebase it and finish the parsing stuff if you don't have time. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#46480 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJbXdpp0KMoSMjpm9U_k_MgTTYCcjTBJks5tKLs1gaJpZM4Qz7Pc> .

petrochenkov · 2018-01-13T18:04:29Z

Closing in favor of #47416

…henkov Remove `impl Foo for .. {}` in favor `auto trait Foo {}` Rebase of #46480 with restored parsing support.

rust-highfive assigned petrochenkov Dec 3, 2017

kennytm added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 4, 2017

kennytm reviewed Dec 4, 2017

View reviewed changes

leoyvens force-pushed the remove-impl-for-dot-dot branch from a66ff70 to f252157 Compare December 4, 2017 18:54

petrochenkov reviewed Dec 4, 2017

View reviewed changes

leoyvens force-pushed the remove-impl-for-dot-dot branch from 05dd1a9 to 52070a1 Compare December 4, 2017 23:45

kennytm removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Dec 5, 2017

petrochenkov mentioned this pull request Dec 6, 2017

syntax: Rewrite parsing of impls #46455

Merged

leoyvens force-pushed the remove-impl-for-dot-dot branch from 52070a1 to 35b18a0 Compare December 12, 2017 14:25

leoyvens force-pushed the remove-impl-for-dot-dot branch from 35b18a0 to 02fcc0a Compare December 17, 2017 21:47

leoyvens force-pushed the remove-impl-for-dot-dot branch from 02fcc0a to 6c2e1a6 Compare December 21, 2017 09:59

kennytm added I-needs-decision Issue: In need of a decision. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Jan 6, 2018

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 6, 2018

kennytm removed the I-needs-decision Issue: In need of a decision. label Jan 7, 2018

petrochenkov mentioned this pull request Jan 13, 2018

Remove impl Foo for .. {} in favor auto trait Foo {} #47416

Merged

petrochenkov closed this Jan 13, 2018

bors added a commit that referenced this pull request Jan 13, 2018

Auto merge of #47416 - petrochenkov:remove-impl-for-dot-dot, r=petroc…

cf4c3cb

…henkov Remove `impl Foo for .. {}` in favor `auto trait Foo {}` Rebase of #46480 with restored parsing support.

leoyvens mentioned this pull request Feb 8, 2018

Don't use unstable syntax without some sort of parsing guard rust-lang/api-guidelines#156

Closed

leoyvens deleted the remove-impl-for-dot-dot branch March 7, 2018 10:53

petrochenkov mentioned this pull request May 17, 2018

Crates using placement syntax behind a cfg broken #50832

Closed

petrochenkov mentioned this pull request Oct 30, 2019

Re-land early syntax feature gating (was: Some features can no longer be controlled by conditional compilation) #65860

Open

Remove impl Foo for .. {} in favor auto trait Foo {} #46480

Remove impl Foo for .. {} in favor auto trait Foo {} #46480

Conversation

leoyvens commented Dec 3, 2017 • edited by petrochenkov Loading

leoyvens commented Dec 4, 2017

kennytm commented Dec 4, 2017

leoyvens commented Dec 4, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petrochenkov Dec 4, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petrochenkov commented Dec 4, 2017

SimonSapin commented Dec 4, 2017

bors commented Dec 7, 2017

bors commented Dec 14, 2017

bors commented Dec 19, 2017

nikomatsakis commented Dec 20, 2017

SimonSapin commented Dec 20, 2017

bors commented Dec 21, 2017

hanna-kruppe commented Jan 6, 2018 • edited Loading

bluss commented Jan 6, 2018

hanna-kruppe commented Jan 6, 2018

petrochenkov commented Jan 6, 2018

dtolnay commented Jan 6, 2018

hanna-kruppe commented Jan 6, 2018

petrochenkov commented Jan 6, 2018

leoyvens commented Jan 6, 2018

petrochenkov commented Jan 6, 2018

bors commented Jan 7, 2018

leoyvens commented Jan 8, 2018

petrochenkov commented Jan 8, 2018 • edited Loading

petrochenkov commented Jan 10, 2018 • edited Loading

petrochenkov commented Jan 13, 2018

leoyvens commented Jan 13, 2018 via email

petrochenkov commented Jan 13, 2018

Remove `impl Foo for .. {}` in favor `auto trait Foo {}` #46480

Remove `impl Foo for .. {}` in favor `auto trait Foo {}` #46480

leoyvens commented Dec 3, 2017 •

edited by petrochenkov

Loading

petrochenkov Dec 4, 2017 •

edited

Loading

hanna-kruppe commented Jan 6, 2018 •

edited

Loading

petrochenkov commented Jan 8, 2018 •

edited

Loading

petrochenkov commented Jan 10, 2018 •

edited

Loading