provide suggestion for incorrect deprecated syntax

[euclio]

Fixes #48271.

r? @estebank

[estebank]

I'd r+, but I'm worried about anyone out there incorrectly using deprecated, as it is usable by 3rd party crates since 1.9.0.

I'll do a crater run to make sure we don't blow anything up, otherwise happy with the change. If there's lots of usage in the wild, this will have to be changed to be a deprecation lint (like #55373).

@bors try

[bors]

⌛ Trying commit d4aea02 with merge bad365140e1e8233b42b21af70a407f14ce5fec5...

[bors]

💥 Test timed out

[estebank]

@craterbot run start=master#adbfec229ce07ff4b2a7bf2d6dec2d13cb224980 end=try#bad365140e1e8233b42b21af70a407f14ce5fec5 mode=check-only

[craterbot]

👌 Experiment pr-56896 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]

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

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

[craterbot]

🎉 Experiment pr-56896 is completed!
📊 205 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

[estebank]

@euclio It seems like we'll have to turn it into a warning or (ideally) lint, and reach out to arc-swap to fix their use of deprecated.

[vorner]

Sorry for the problems :-|. I've released a fix for that.

But going through the crater report randomly, it seems there are other ones too.

[estebank]

@vorner no need to apologize, if we didn't want you to write the attribute that way we should have made it a hard error :)

@euclio do you think you'll be able to turn this into a lint? That way we can merge it as allow by default, and a few releases down the line enable it as warn and finally deny by default.

[Centril]

Hmm... Even tho it wasn't mandated by an RFC, given that #[deprecated = "foobar"] is already supported in the language, I think It'd rather have this fixed in rustdoc instead of removing #[deprecated = "foobar"] from the language. It seems harmless to support and it reduces churn in libraries.

cc @rust-lang/lang @rust-lang/libs

[cramertj]

Not only is it harmless, I think this is the only reasonable option-- lots of code has used #[deprecated = "...."] today without knowing that it was the "incorrect" way of writing that code. Starting to error on that code would be a breaking change for essentially no reason (this isn't unsound, difficult to support, etc. and it doesn't interact poorly with other language features AFAIK), which seems like a violation of our backwards-compatibility guarantees.

(note: not all code is checked by crater, either-- this change would break several crates inside of Fuchsia that were previously using #[deprecated = ...], and received no warning)

[euclio]

I would prefer going with a future-incompat lint here instead of deviating from the RFC. deprecated = "1.2.3" seems just as reasonable to me syntactically and that would be incorrectly interpreted as the note if we begin to accept that syntax. Furthermore, It's trivial to fix this with cargo fix during the warning period.

As an aside, attribute parsing is extremely lax in various places in the compiler. I think that we should require stricter parsing tests for stabilization of new attributes to avoid this situation in the future.

[estebank]

@Centril I would still like to add it as a lint, so that individual projects can require the newer syntax at will. I don't think we could change this to deny-by-default until the next epoch.

[Centril]

@Centril I would still like to add it as a lint, so that individual projects can require the newer syntax at will.

I would be OK with an allow-by-default lint or to do it in clippy; The FCP is for not erroring.

I don't think we could change this to deny-by-default until the next epoch.

I don't think we should change it even in Rust 2021.

[euclio]

To be clear, I don't think we should error either. I'm arguing for a warn-by-default future-incompat lint.

[Centril]

@euclio

To be clear, I don't think we should error either. I'm arguing for a warn-by-default future-incompat lint.

A warn-by-default C-future-compatibility lint would mean that we intend to eventually make it a hard error.

[euclio]

Yes, that would be my intention. Likely in the next edition.

[Centril]

Right; what I'm saying is that I don't think we should make it an error ever because the churn doesn't seem worth it and doing it in an edition would make it even more complicated than supporting it. :)

[euclio]

Either way I'd rather warn and fix it automatically via cargo fix than accept the incorrect syntax with an allow-by-default lint that is likely to be left undiscovered, since this is clearly a bug in the implementation.

[Centril]

@euclio My preference is that #[deprecated = "abc" should just be synonymous with #[deprecated(note = "abc")] and if it isn't, then that's the direction in which we should fix things. In other words, it's no longer incorrect syntax, but an alternative, correct syntax.

[euclio]

I understand, but I'd prefer to stick with the syntax specified in the RFC. I'll defer to the Lang team's decision, however.

[vorner]

If I may add my humble 2 cents, there's something good on „one correct way to do things“ so if the #[deprecated = "note"] is somehow discouraged, I'd personally prefer that to be warn-by-default (and maybe leave it as that forever ‒ there are lints that never plan to become hard errors, like dead-code or deprecated items in the standard library).

[joshtriplett]

I'd be happy with keeping the deprecated syntax for deprecated, and treating it as the note, as long as we have a warn-by-default lint for the very specific case where the value looks like a semver.

[Centril]

@joshtriplett That seems fine to me tho I wonder if it will arise in practice?

[bors]

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

[euclio]

How does this fit in with #57321 and the ill_formed_attribute_input lint? As I said before, I'm personally against deviating from the RFC so I would prefer to make this part of that lint. However, if the lang team instead wants to accept #[deprecated = "note"] then I can implement that instead. I'm just looking for consensus.

[nikomatsakis]

Discussed briefly in the @rust-lang/lang meeting today. All present agreed that we might as well "retcon" the #[deprecated = "foo"] syntax as a shorthand for #[deprecated(note = "foo")], given that it is in widespread use.

[euclio]

Ok, I'll close this PR and open an implementation of the "retcon" within a few days, then. Thanks for the input, everyone!