compiler-team
compiler-team copied to clipboard
rust-lang
Re-add most early unstable syntax gates as future-compat lints
(This has both T-lang and T-compiler implications; if this would be better as a T-lang proposal it can be moved. However, it is my general understanding that the lack of these gates is considered a bug and not a stable language guarantee.)
Proposal
Many unstable syntaxes (e.g. box $expr, macro, try) are currently considered syntax-stable (playground) and can be present in syntax-checked-only contexts (i.e. passed to active/noninert attributes that don't reemit the syntax e.g. #[cfg(FALSE)]) despite being unstable.
Early gates were added for most unstable syntaxes in rust-lang/rust#65742, but were reverted in rust-lang/rust#66004 due to this (intentionally) regressing the ability to #[cfg]-gate unstable syntax (originally reported in rust-lang/rust$65860).
This proposal is to reintroduce these early gates, but as future-compatibility warning lints rather than hard errors, in order to warn against potential breakage from adjustments of unstable syntax (and discourage attribute proc macros from relying on the syntax availability) without just outright removing the ability to cfg-gate unstable syntax without indirection to a separate file which is cfg-gate-include!d.
Alternatively, a separate future-compatibility-like lint group/mechanism can be introduced for unstable syntax to refine future-compatibility's
warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
to something potentially more appropriate along the lines of
warning: this is unstable syntax provisionally accepted by the compiler; it may be changed or removed causing a hard error in a future release!
The emission of the early lint should be suppressed if the same span later emits an error for the use of the unstable feature.
Future Work
This is not part of this MCP, but included for illustration of a potential direction.
Discussed in rust-lang/rust#65860 is a potential compromise: only syntax-verify "one level deep" in the token tree. If this change is done, it should be carefully considered what this loses (e.g. rustc checked known syntax-correctness for external tooling such as rustfmt to be able to syntactically analyze block bodies without expanding attribute macros).
Possible directions to allow cfg-gating unstable syntax include shallow syntax verification for some or all language constructs with an active attribute or introduction of a std-blessed[^1] cfg_if style bang macro, as bang macros do allow arbitrary internal syntax.
[^1]: The advantage of being std-blessed is that tooling (such as rustfmt) can presume that the macro is the std one and process the internal syntax (potentially even without performing name resolution) such as is done for format_args!-like macros.
Mentors or Reviewers
No mentor/reviewer has been suggested. I (@CAD97) am willing/able/available to do the work necessary to cherry-pick the previous early syntax gate implementation and modify it to emit a future-compatility lint instead of a hard error. (This has not been done yet, but I plan to do it shortly following a second, if given.)
The work to actually early-gate the features has previously been done and reviewed. The new work needing mentor/review is primarily just diagnostics (e.g. communicating the unstable-in-stable status and suppressing the warning if an error is also emitted).
References
- https://github.com/rust-lang/rust/issues/65860 (tracking)
- https://github.com/rust-lang/rust/pull/64672#issuecomment-542703363 (crater analysis on what unstable syntaxes are the most defacto syntax stable)
- https://github.com/rust-lang/rust/pull/65742 (originally landed)
- https://github.com/rust-lang/rust/pull/66004 (reverted due to breakage)
- https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/FYI.3A.20.60macro.60.20is.20syntax-stable (rediscovered by myself)
Process
The main points of the Major Change Process are as follows:
- [x] File an issue describing the proposal.
- [x] 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 mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- [ ] 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.
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.
cc @rust-lang/compiler @rust-lang/compiler-contributors
Initial implementation is available: https://github.com/rust-lang/rust/pull/99935
