Swift Proposal: Precise Control Flags Over Compiler Warnings
This proposal suggests adding new options that will allow the behavior of warnings to be controlled based on their diagnostic group.
-Werror <group>
- upgrades warnings in the specified group to errors-Wwarning <group>
- indicates that warnings in the specified group should remain warnings, even if they were previously suppressed or upgraded to errors[…]
Thus, for example, you can use the combination
-warnings-as-errors -Wwarning deprecated
, which will upgrade all warnings to errors except for those in thedeprecated
group. However, if these flags are specified in the reverse order(-Wwarning deprecated -warnings-as-errors
) it will be interpreted as upgrading all warnings to errors, as the-warnings-as-errors
flag is the last one.[…]
We are also introducing a new compiler flag,
-print-diagnostic-groups
, to display the names of diagnostic groups along with the textual representation of the warnings.
I’ve linked to this before, but I wanted to give it a full post because I think it’s important. I’d still like to see even more control over warnings, e.g. a way to suppress a particular warning or deprecation only within a certain region of code, as was possible with Clang.
Previously: