SE-0443: Precise Control Flags over Compiler Warnings

[dmt (Dima Galimzianov)]

@beccadax

• The proposal is clear that diagnostics cannot belong directly to more than one group (they can belong to other groups indirectly, by the other group containing that one). Do they belong to exactly one group, or can they belong to no groups?

The ultimate goal is to sort out pretty much all the diagnostics into groups. However for now they can belong to no groups because we just can't manage all of them in a single run. Also, I'm aware of one particular warning ("...; This is an error in the Swift N language mode") that shouldn't belong to any group, because 1) it's a compiler implementation detail 2) it doesn't communicate much information about the actual warning, so it's pretty useless from user perspective.
I hope it makes sense.

@beccadax

In at least one case, the proposal seems to suggest that a group might contain a single warning that is then aggregated into several groups.

• Do you expect this pattern to be common?
• Is it recommended?
• Is it baked in somehow?

Do you refer to the "unsafe_global_actor_deprecated" example? It's a matter of convenience in organizing the supergroups. And the group system allows great flexibility in how and when we can include a group in broader groups.
The basic rule is that a warning should be included in one narrow group. Narrow is 1-2 warnings. So for the unsafe_global_actor_deprecated warning, we should declare the unsafe_global_actor_deprecated group. But since we have "deprecated" and "concurrency" groups it's very natural to include the unsafe_global_actor_deprecated group in them as well.
I don't expect a warning can be contained in something like 10 unrelated supergroups, but there's no actual limitation implied here aside from the common sense. And I think with some practice we can come up with a more formal guideline.

@beccadax

If it is, how is that materially different from making the diagnostic IDs public

Simply can't make diagnostic IDs public, too fragile to use in user-visible API.

@beccadax

• Is the expectation that all warnings will (ideally) be organized into appropriate groups, or do you imagine that this will be more opportunistic, with groups added to cover use cases as they are discovered and many warnings belonging to no group (or just an "all" group)?
• Put another way, should there be project rules requiring that when you add a warning, you must find or create a place in the diagnostic group hierarchy for it?

Yes, pretty much all of them should be grouped. And yes, I think there should be such a rule and @Douglas_Gregor suggested enforcing it with an assert.

@beccadax

Is there a mechanism for creating diagnostics that are errors by default but can be downgraded to warnings?

Errors can be grouped as well, but -W options don't apply to them. This is needed because some errors are warnings in some language modes (that warning about swift 6 again). So if an error is downgraded by some other logic to a warning then it will be subject to the warning control flags, but users can't downgrade errors on their will.

@beccadax

• • Should remarks fit into this picture somehow?

I didn't find a use for it yet, so left them without group support for now, but in general, I don't see why they couldn't fit the model.

@beccadax

As the person who suggested we add -debug-diagnostic-names, I think you should break its format rather than accepting limitations on its use. As the debug prefix suggests, the flag is an aid to compiler debugging. Nothing ought to depend on its format, and I can find no evidence in Google or GitHub that anything does.

I think @allevato might disagree
Anyway, I think the proposed solution where we prevent interference with -debug-diagnostic-names is good enough. At least for now, I don't see why someone would need to use both of them.