Diagnostic groups: deprecated

Yeah, this is another thing I wanted to discuss. They do behave like they are deprecated declarations but AFAIK we don't have a concept of deprecated protocol requirement in the language, so such warnings can only be expressed as special cases in the compiler. Do they still should be considered part of the DeprecatedDeclaration group?

I'd say yes—possibly with a subgroup of DeprecatedProtocolRequirement?

My rationale is this: These groups are for end users and ought to be comprehensible (in their grouping) to them. How something is implemented as a special case is sort of immaterial from that perspective.

4 Likes

I'm a bit worried that with only a subject part in a group name, we may face some naming difficulties in the future. Consider the possibility that one day the compiler will diagnose another warning for the same attribute, something like "@_implementationOnly attribute is used for a non-resilient module that wasn't prepared for it".
We will have two warnings: ImplementationOnlyAttribute and ImplementationOnlyAttribute(some_suffix). It's a bit confusing.
I'd love to give all the groups short names, but I'm afraid of shortening them based on today's set of diagnostics.

1 Like

Let's focus on DeprecatedDeclaration then. I'm removing everything else from the PR and merging DeprecatedExecutorEnqueueOwnedJobImplementation and DeprecatedHashValueImplementation into DeprecatedDeclaration.
I think we are better not to give them a dedicated group (i.e. DeprecatedProtocolRequirement) since we're not providing DeprecatedWitness or DeprecatedConformance.
But I think in one of the next iterations we might bring DeprecatedExecutorEnqueueOwnedJobImplementation back because it should probably belong to a supergroup about concurrency warnings as well.