stop marking deref_patterns as an incomplete feature

[cyrgani]

This PR removes the incomplete_feature warning for deref_patterns. The reason given for this in the tracking issue (#87121) was

Per policy, the incomplete_feature is supposed to stay on until the feature has an accepted RFC. We're slowly working on writing up that RFC so it'll take some more time unfortunately.

I don't know of any compiler crashes it causes today. The feature should be pretty usable.

However, I could not find any evidence of such a policy. The lint documentation for incomplete_features also only mentions features that are more likely to cause errors.
There are also many other features without an RFC that are not considered incomplete, e.g. macro_metavar_expr_concat, negative_impls or yeet_expr.
The feature does not cause any known ICEs either.

The concrete motivation is to use this feature to replace box_patterns in the compiler and pave the way towards removing that legacy feature.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[rustbot]

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 68 candidates
• Random selection from 13 candidates

[jackh726]

This is indeed more or less current policy. This should get an RFC before being marked as incomplete.

[fee1-dead]

If we look at the diagnostic emitted by incomplete_feature:

warning: the feature `deref_patterns` is incomplete and may not be safe to use and/or cause compiler crashes
--> src/lib.rs:1:12
|
1 | #![feature(deref_patterns)]
| ^^^^^^^^^^^^^^
|
= note: see issue #87121 <https://github.com/rust-lang/rust/issues/87121> for more information
= note: `#[warn(incomplete_features)]` on by default

This paints me as a status that moreso reflects the state of the feature in the compiler rather than the language. Given that my memory of incomplete_feature as primarily being used to warn users of unsoundness, ICEs, lack of proper support, etc, I would approve this PR given that deref_patterns appears to have matured and not cause unsoundness/ICEs at present.

cc @Nadrieril who made that comment originally.

@bors r+ rollup

[rust-bors]

📌 Commit 06b0bd2 has been approved by fee1-dead

It is now in the queue for this repository.

[Nadrieril]

@bors r-

The policy is here: https://lang-team.rust-lang.org/how_to/experiment.html :

The feature gate should be marked as ‘experimental’, so that users get warnings if they try to use it. This flag has to stay until an RFC is accepted, even if the implementation is in good shape.

I consider it important to keep the warning, because this feature may be replaced by something different depending on how the Field Projections work pans out.

[Nadrieril]

It's a known annoyance that we use the same "incomplete feature" lint to mark both features that aren't fully implemented and features that aren't yet approved by the lang team, but for now that's the lint we have.

[fee1-dead]

/shrug

const traits doesn't have incomplete status either, and it also doesn't have an RFC. The wording on the diagnostic does not match what the lang team prescribes. Someone should do Something I suppose, and change the warnings for these kinds of features from the current wording to one that is like "this feature does not have an accepted RFC", with note "this feature could be majorly changed or outright removed"

[Nadrieril]

I consider it important to keep the warning

Arguably "this is a nightly feature" could be enough of a deterrent. I think the lint is a not-super-thorough attempt at signaling to users how risky it is to be making use of that feature in their code.

And, well, for deref patterns I think we're in "not too risky" territory. I wouldn't remove the feature except to replace it with something similar; the overall ergonomics is completely something we want in the language in some form. So maybe it's fair to remove the lint...

[Nadrieril]

There are also many other features without an RFC that are not considered incomplete, e.g. macro_metavar_expr_concat, negative_impls or yeet_expr.

const traits doesn't have incomplete status either

Am I the only one respecting that policy x)

[Nadrieril]

Alright I've convinced myself, thanks for the PR @cyrgani

@bors r=fee1-dead,Nadrieril

[rust-bors]

📌 Commit 06b0bd2 has been approved by fee1-dead,Nadrieril

It is now in the queue for this repository.

[m-hugo]

The policy is here: https://lang-team.rust-lang.org/how_to/experiment.html :

The feature gate should be marked as ‘experimental’, so that users get warnings if they try to use it. This flag has to stay until an RFC is accepted, even if the implementation is in good shape.

I consider it important to keep the warning, because this feature may be replaced by something different depending on how the Field Projections work pans out.

is ‘experimental’ and 'incomplete_feature' even the same thing?

[Nadrieril]

It's how I've seen this piece of documentation interpreted over the years. We don't really have anything else that looks like "marking a feature gate as experimental". But I agree it would be better to have one such thing, insofar as we do want to continue having this policy.