Skip to content

Commit b985812

Browse files
committed
Exclude -Wsuppress and -suppress-warnings from the proposal
1 parent c0576bc commit b985812

File tree

1 file changed

+24
-19
lines changed

1 file changed

+24
-19
lines changed

proposals/0443-warning-control-flags.md

Lines changed: 24 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@
1010

1111
## Introduction
1212

13-
This proposal introduces new compiler options that allow fine-grained control over how the compiler emits certain warnings: as warnings, as errors, or not at all.
13+
This proposal introduces new compiler options that allow fine-grained control over how the compiler emits certain warnings: as warnings or as errors.
1414

1515
## Motivation
1616

@@ -25,7 +25,6 @@ This lack of flexibility leads to situations where users who want to use `-warni
2525

2626
This proposal suggests adding new options that will allow the behavior of warnings to be controlled based on their diagnostic group.
2727
- `-Werror <group>` - upgrades warnings in the specified group to errors
28-
- `-Wsuppress <group>` - disables the emission of warnings in the specified group
2928
- `-Wwarning <group>` - indicates that warnings in the specified group should remain warnings, even if they were previously suppressed or upgraded to errors
3029

3130
The `<group>` parameter is a string identifier of the diagnostic group.
@@ -80,28 +79,20 @@ Each warning in the compiler is assigned one of three behaviors: `warning`, `err
8079
Compiler options for controlling the behavior of groups are now processed as a single list. These options include:
8180
```
8281
-Werror <group>
83-
-Wsuppress <group>
8482
-Wwarning <group>
8583
-warnings-as-errors
8684
-no-warnings-as-errors
87-
-suppress-warnings
8885
```
89-
When these options are passed to the compiler, we sequentially apply the specified behavior to all warnings within the specified group from left to right. For `-warnings-as-errors`, `-no-warnings-as-errors`, and `-suppress-warnings`, we apply the behavior to all warnings.
90-
91-
The `-no-warnings-as-errors` option should be read as "set the behavior to 'warning' for all warnings". Thus, it overrides all previously set behaviors, including if the `-suppress-warnings` option was applied earlier or if a warning was suppressed by default.
86+
When these options are passed to the compiler, we sequentially apply the specified behavior to all warnings within the specified group from left to right. For `-warnings-as-errors` and `-no-warnings-as-errors`, we apply the behavior to all warnings.
9287

9388
Examples of option combinations:
9489
- `-warnings-as-errors -Wwarning deprecated`
9590

9691
Warnings from the `deprecated` group will be kept as warnings, but all the rest will be upgraded to errors.
9792

98-
- `-warnings-as-errors -Wwarning deprecated -Wsuppress availability_deprecated`
99-
100-
Warnings from the `availability_deprecated` group will be suppressed. Other warnings from the `deprecated` group will remain as warnings. All other warnings will be upgraded to errors.
101-
102-
- `-suppress-warnings -Wwarning deprecated`
93+
- `-Werror deprecated -Wwarning availability_deprecated`
10394

104-
Warnings from the `deprecated` group will remain as warnings. All others will be suppressed.
95+
Warnings from the `availability_deprecated` group will remain as warnings. Other warnings from the `deprecated` group will be upgraded to errors. All others will be kept as warnings.
10596

10697
It’s crucial to understand that the order in which these flags are applied can significantly affect the behavior of diagnostics. The rule is "the last one wins", meaning that if multiple flags apply to the same diagnostic group, the last one specified on the command line will determine the final behavior.
10798

@@ -110,6 +101,14 @@ For example, as mentioned above, the `unsafe_global_actor_deprecated` group is p
110101
- `-Wwarning deprecated -Werror concurrency` will make it an error,
111102
- `-Werror concurrency -Wwarning deprecated` will keep it as a warning.
112103

104+
#### Interaction with `-suppress-warnings`
105+
106+
This proposal deliberately excludes `-suppress-warnings` and its group-based counterpart from the new unified model. We retain the behavior of the existing `-suppress-warnings` flag but forbid its usage with the new options. The following rules will be applied:
107+
108+
- It is forbidden to combine `-suppress-warnings` with `-Wwarning` or `-Werror`. The compiler will produce an error if these options are present in the command line together.
109+
- It is allowed to be combined with `-no-warnings-as-errors`. The current compiler behavior permits the usage of `-no-warnings-as-errors` or `-warnings-as-errors -no-warnings-as-errors` with `-suppress-warnings`. We will maintain this behavior.
110+
- It remains position-independent. Whenever `-no-warnings-as-errors` and `-suppress-warnings` are combined, `-suppress-warnings` will always take precedence over `-no-warnings-as-errors`, regardless of the order in which they are specified.
111+
113112
### Usage of `-print-diagnostic-groups` and `-debug-diagnostic-names`
114113

115114
As mentioned earlier, we are adding support for the `-print-diagnostic-groups` compiler option, which outputs the group name in square brackets.
@@ -153,7 +152,7 @@ The adoption of diagnostic groups and the new compiler options will provide a fo
153152

154153
### Support in the language
155154

156-
While diagnostic groups are introduced to support the compiler options, it may be possible in the future to standardize the structure of the group graph itself. This could open up the possibility of using these same identifiers in the language, implementing something analogous to `#pragma diagnostic` or `[[attribute]]` in C++. However, such standardization and the design of new constructs in the language go far beyond the scope of this proposal, and we need to gain more experience with diagnostic groups before proceeding with this.
155+
While diagnostic groups are introduced to support the compiler options, it may be possible in the future to standardize the structure of the group graph itself. This could open up the possibility of using these same identifiers in the language, implementing something analogous to `#pragma diagnostic` or `[[attribute]]` in C++. It could also address suppressing warnings entirely, which isn't covered by this proposal. However, such standardization and the design of new language constructs go far beyond the scope of this proposal, and we need to gain more experience with diagnostic groups before proceeding with this.
157156

158157
### Support in SwiftPM
159158

@@ -204,18 +203,15 @@ During the design process, other names for the compiler options were considered,
204203
|--------------------------|--------------------------------|
205204
| `-warnings-as-errors` | `-warning-as-error <group>` |
206205
| `-no-warnings-as-errors` | `-no-warning-as-error <group>` |
207-
| `-suppress-warnings` | `-suppress-warning <group>` |
208-
209-
However, with this naming, the combination `-suppress-warning deprecated -no-warning-as-error availability_deprecated` might be misleading.
210206

211207
In Clang, diagnostic behavior is controlled through `-W...` options, but the format suffers from inconsistency. We adopt the `-W` prefix while making the format consistent.
212208
| Clang | Swift |
213209
|-------------------|----------------------|
214210
| `-W<group>` | `-Wwarning <group>` |
215-
| `-Wno-<group>` | `-Wsuppress <group>` |
211+
| `-Wno-<group>` | |
216212
| `-Werror=<group>` | `-Werror <group>` |
217213

218-
Additionally, the option name `-Wwarning` is much better suited when it comes to enabling suppressed-by-default warnings. Today we have several of them behind dedicated flags like `-driver-warn-unused-options` and `-warn-concurrency`. It might be worth having a common infrastructure for warnings that are suppressed by default.
214+
The option name `-Wwarning` is much better suited when it comes to enabling suppressed-by-default warnings. Today we have several of them behind dedicated flags like `-driver-warn-unused-options` and `-warn-concurrency`. It might be worth having a common infrastructure for warnings that are suppressed by default.
219215

220216
### Alternative format for `-print-diagnostic-groups`
221217

@@ -232,3 +228,12 @@ However, even this does not eliminate the possibility of breaking code that pars
232228

233229
Moreover, `-print-diagnostic-groups` provides a formalized version of the same functionality using identifiers suitable for user use. And thus it should supersede the usages of `-debug-diagnostic-names`. Therefore, we believe the best solution would be to use the same format for `-print-diagnostic-groups` and prohibit the simultaneous use of these two options.
234230

231+
## Revision History
232+
233+
- Revisions based on review feedback:
234+
- `-Wsuppress` was excluded from the proposal.
235+
- `-suppress-warnings` was excluded from the unified model and addressed separately by forbidding its usage with the new flags.
236+
237+
## Acknowledgments
238+
239+
Thank you to [Frederick Kellison-Linn](https://forums.swift.org/u/Jumhyn) for the idea of addressing the `-suppress-warnings` behavior without incorporating it into the new model.

0 commit comments

Comments
 (0)