This simplifies the code to emit availabilty diagnostics and ensures that they
display domain names consistently. While updating existing diagnostics, improve
consistency along other dimensions as well.
This group has not shipped yet and was added mainly to support test
coverage for d56b7df8a9. Now that we have
unit tests for this, delete the group, pending discussion.
This change addresses the following issue: when an error is being wrapped in a warning, the diagnostic message will use the wrapper's `DiagGroupID` as the warning's name. However, we want to retain the original error's group for use. For example, in Swift 5, async_unavailable_decl is wrapped in error_in_future_swift_version. When we print a diagnostic of this kind, we want to keep the `DiagGroupID` of `async_unavailable_decl`, not that of `error_in_future_swift_version`.
To achieve this, we add `DiagGroupID` to the `Diagnostic` class. When an active diagnostic is wrapped in DiagnosticEngine, we retain the original `DiagGroupID`.
For illustration purposes, this change also introduces a new group: `DeclarationUnavailableFromAsynchronousContext`.
With this change, we produce errors and warnings of this kind with messages like the following:
```
global function 'fNoAsync' is unavailable from asynchronous contexts [DeclarationUnavailableFromAsynchronousContext]
global function 'fNoAsync' is unavailable from asynchronous contexts; this is an error in the Swift 6 language mode [DeclarationUnavailableFromAsynchronousContext]
```
updates noasync diagnostics in TypeCheckAvailability.cpp to diagnose
defer bodies as if they had the same `isAsyncContext()` value as their
nearest non-defer parent scope.
resolves: https://github.com/apple/swift/issues/73614
Missed setting a diagnostic as a warning until swift 6, resulting in
noasync functions being emitted as errors in Swift 5.x. This fixes that
so they are only warnings until Swift 6.
Since `@_unavailableFromAsync` is serialized as `@available(*, noasync)`
in the swiftinterface/swiftmodule, this affects functions that are
imported from other modules as well.
This patch adds validation to ensure that the noasync attribute is only
applied to useful declarations.
Specifically, the `noasync` attribute cannot be applied to `deinit`
declarations, asynchronous functions, or asynchronous properties.