allow `incomplete_features` in UI tests

[cyrgani]

Proposal

The UI test suite already allows several lints by default, such as unused lints or internal_features, because a lot of tests would trigger them and distract from the actual purpose of the test. However, the incomplete_features lint is not yet allowed. This has two drawbacks:

1. PRs that mark a feature as "no longer incomplete" need to update a lot of test files to no longer contain #![expect(incomplete_features)] or //~ WARN the feature ... is incomplete, which is annoying (example: stop marking deref_patterns as an incomplete feature rust#153053)
2. There are quite a few tests that are marked as check/build/run-pass that still have a .stderr file that contains nothing more than the warning: the feature ... is incomplete and may not be safe to use and/or cause compiler crashes warning.

Therefore, I propose to also allow incomplete_features for all UI tests by default and only add #![warn(incomplete_features)] to tests that are specifically about emitting the warning for a feature.

Mentors or Reviewers

I am willing to make a PR that allows the lint for tests/ui and updates the affected test files.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Note

Concerns (0 active)

• dont-forget-in-main-feature-gate-test resolved in this comment

Managed by @rustbot—see help for details.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[jieyouxu]

The overall idea seems to make sense, I'll register a specific concern re. discoverability.
@rustbot second

[jieyouxu]

@rustbot concern dont-forget-in-main-feature-gate-test

Whatever mechanism implemented, we probably want to make sure that it's visible in the main feature gate test 🤔 Maybe:

• UI test mode default to -Aincomplete-features
• tests/ui/feature-gates/* main feature gate tests override with //@ compile-flags: -Wincomplete-features? Maybe implicitly, but always feel a bit iffy when a test folder under a test suite has special behavior 🤔

Ideally we also want to enforce that it is indeed -Wincomplete-features for the main feature gates, because if it's not enforced it's really easy to miss IMO.

I would like to see this discussed / have an intended approach in the proposal before resolving this concern.

[jieyouxu]

@fmease raised a good point

Moreover, forgetting to gate a feature is a critical situation while forgetting to mark a feature incomplete isn't world shattering. Furthermore, if we forgot to mark a feature incomplete (that's the potential failure point), none of these "feature incompleteness" tests would fail anyway.

@rustbot resolve dont-forget-in-main-feature-gate-test