Add internal_features lint for internal unstable features · Issue #596 · rust-lang/compiler-team (original) (raw)

Proposal

There are a lot of nightly features and it's difficult to set expectations for nightly users. We have some way of telling users about broken features (like generic_const_exprs) via the incomplete_features lint, but no way of warning people about using internal features. lang_items and let_chains are very different and it might not be obvious for a user that they are. let_chains are close to stabilization and it's reasonable for a nightly user to make use of them. lang_items are a perma unstable implementation detail that should never be used in code unless the user really knows that they want to.

Therefore I propose adding a new internal_features (the name is bikesheddable) lint, similar to incomplete_features. All features that are perma unstable (this includes lang_items, rustc_attrs, unsafe_pin_internals and more) fall under this lint. Just like with incomplete_features, Rusts soundness guarantees might not strictly hold when using internal_features (although we should of course still attempt to keep them as sound as possible for maintainability).

With this lint people can use nightly features but still get the assurance that they are only testing new features, not relying on implementation details.

The lint would be deny-by-default to require explicit opt-in.

Mentors or Reviewers

The implementation should be pretty simple as it can basically copy incomplete_features.

The most interesting work is determining which features fall under this lint. Some are obvious, some might be less obvious. It probably makes sense to ask the lang team about the feature on uncertainty.

Process

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

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

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.