Rethinking support for warning control flags (SE-0443)

[DmT021]

We've been working on adding support for warning control flags to SwiftPM (which were added to Swift in SE-0443 and similar for Clang). And I found this PR.
If my understanding is correct (and please correct me if I'm wrong), that implementation emits all "-Wwarning" flags and then all "-Werror" flags, or vice versa. So it's impossible to configure the following invocation: -Wwarning A -Werror B -Wwarning C.
This is a problem because in Swift (as well as in Clang) warning groups are not a flat list but a graph - one group can be nested inside another.
We don't have any nested groups in Swift at the moment, but you can imagine the PreconcurrencyImport group could become nested within a wider group collecting all concurrency warnings. It should be possible to configure -Werror Concurrency -Wwarning PreconcurrencyImport (which means all concurrency-related warnings are upgraded to errors except PreconcurrencyImport) or -warnings-as-errors -Wwarning Concurrency -Werror PreconcurrencyImport (which means all warnings are upgraded to errors except all concurrency-related warnings, but PreconcurrencyImport warnings are upgraded to errors again). Or any other combinations of -Werror, -Wwarning, -warnings-as-errors, and -no-warnings-as-errors.
The same goes for Clang. For example, the deprecated diagnostic group includes a bunch of narrower groups.

Can we retract the SWIFT_WARNINGS_AS_WARNINGS_GROUPS and SWIFT_WARNINGS_AS_ERRORS_GROUPS and think about a better solution here?

I don't have a good solution off the top of my head here. I looked at some of the other build systems - CMake, GN, and Buck2. None of them have a sophisticated high-level abstraction over the warning control flags. CMake has COMPILE_WARNING_AS_ERROR, but it's just a boolean, same as C[PLUSPLUS]_TREAT_WARNINGS_AS_ERRORS in swift-build.
Maybe if we want something better than OTHER_SWIFT_FLAGS, we should come up with an ad-hoc syntax for enabling/disabling warnings while preserving the order. Something along the lines:

SWIFT_WARNINGS_TREAT_RULES = [
  "error:*",  // -warnings-as-errors
  "warning:*",  // -no-warnings-as-errors
  "error:PreconcurrencyImport",  // -Werror PreconcurrencyImport
  "warning:PreconcurrencyImport",  // -Wwarning PreconcurrencyImport
]

cc @owenv @swiftlysingh @hborla

[owenv]

In the common case, I think users/tools relying on warning flag order to subset out groups of diagnostics is an anti-pattern - there's no way for the user or their tools to interpret the behavior of a particular combination of flags without referencing the compiler implementation. If a user does want this level of customization, I think it's reasonable to ask them to use something like OTHER_SWIFT_FLAGS to manually specify a specific ordering instead of using the friendlier dedicated settings. I'd like to avoid designing a dedicated syntax for these flags - I don't think the complexity is justified when there's an easy escape hatch available with OTHER_SWIFT_FLAGS

[DmT021]

I understand, and I will not insist on a comprehensive solution. But the current implementation is already causing some confusion: https://forums.swift.org/t/diagnostic-groups-deprecated/74581/26.
Perhaps it would be worth establishing at least a strict order between SWIFT_TREAT_WARNINGS_AS_ERRORS, SWIFT_WARNINGS_AS_WARNINGS_GROUPS, and SWIFT_WARNINGS_AS_ERRORS_GROUPS.

Also, we will have to resort to OTHER_SWIFT_FLAGS in SwiftPM then.