Skip to content

Frontend: Implement optional parsing diagnostics for enabled language features #78642

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jan 16, 2025

Conversation

tshortli
Copy link
Contributor

Parsing for -enable-upcoming-feature and -enable-experimental-feature is lenient by default because some projects need to be compatible with multiple language versions and compiler toolchains simultaneously, and strict diagnostics would be a nuisance. On the other hand, though, it would be useful to get feedback from the compiler when you attempt to enable a feature that doesn't exist. This change splits the difference by introducing new diagnostics for potential feature enablement misconfigurations but leaves those diagnostics ignored by default. Projects that wish to use them can specify -Wwarning StrictLanguageFeatures.

Copy link
Member

@DougGregor DougGregor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@tshortli tshortli force-pushed the warn-unrecognized-language-feature branch 2 times, most recently from e737b23 to 9e3ea48 Compare January 15, 2025 19:05
@tshortli
Copy link
Contributor Author

@swift-ci please test

@tshortli
Copy link
Contributor Author

@swift-ci please build toolchain macOS

@tshortli tshortli enabled auto-merge January 15, 2025 19:09
@tshortli tshortli disabled auto-merge January 15, 2025 20:47
Diagnostics may be emitted while parsing command line arguments. This implies
that the options which affect how diagnostics are emitted and presented need to
be parsed first.
… features.

Parsing for `-enable-upcoming-feature` and `-enable-experimental-feature` is
lenient by default because some projects need to be compatible with multiple
language versions and compiler toolchains simultaneously, and strict
diagnostics would be a nuisance. On the other hand, though, it would be useful
to get feedback from the compiler when you attempt to enable a feature that
doesn't exist. This change splits the difference by introducing new diagnostics
for potential feature enablement misconfigurations but leaves those diagnostics
ignored by default. Projects that wish to use them can specify `-Wwarning
StrictLanguageFeatures`.
@tshortli tshortli force-pushed the warn-unrecognized-language-feature branch from 9e3ea48 to 24f5632 Compare January 16, 2025 00:34
@tshortli
Copy link
Contributor Author

@swift-ci please smoke test

@tshortli tshortli enabled auto-merge January 16, 2025 00:34
@tshortli tshortli merged commit 6576929 into swiftlang:main Jan 16, 2025
3 checks passed
@tshortli tshortli deleted the warn-unrecognized-language-feature branch January 16, 2025 05:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants