Extensions that extend non-public types should never be required to have
explicit availability, even if they declare conformances to public protocols.
Resolves rdar://148697770.
This attribute controls whether cross-module access to the declaration
needs `@unknown default:` because it's allowed to gain new cases even
if the module is non-resilient.
The changes in https://github.com/swiftlang/swift/pull/80040 caused the
compiler to start diagnosing extensions containing only members that are
either `@_spi`, `@_alwaysEmitIntoClient`, or unavailable when the
`-require-explicit-availability` flag is passed. Extensions should not be
diagnosed when they only contain members that would not be diagnosed
themselves.
Resolves rdar://148275432.
Print diagnostic groups as part of the LLVM printer in the same manner as the
Swift one does, always. Make `-print-diagnostic-groups` an inert option, since we
always print diagnostic group names with the `[#GroupName]` syntax.
As part of this, we no longer render the diagnostic group name as part
of the diagnostic *text*, instead leaving it up to the diagnostic
renderer to handle the category appropriately. Update all of the tests
that were depending on `-print-diagnostic-groups` putting it into the
text to instead use the `{{documentation-file=<file name>}}`
diagnostic verification syntax.
We've been converging the implementations of educational notes and
diagnostic groups, where both provide category information in
diagnostics (e.g., `[#StrictMemorySafety]`) and corresponding
short-form documentation files. The diagnostic group model is more
useful in a few ways:
* It provides warnings-as-errors control for warnings in the group
* It is easier to associate a diagnostic with a group with
GROUPED_ERROR/GROUPED_WARNING than it is to have a separate diagnostic
ID -> mapping.
* It is easier to see our progress on diagnostic-group coverage
* It provides an easy name to use for diagnostic purposes.
Collapse the educational-notes infrastructure into diagnostic groups,
migrating all of the existing educational notes into new groups.
Simplify the code paths that dealt with multiple educational notes to
have a single, possibly-missing "category documentation URL", which is
how we're treating this.
This feature only exists as a mechanism to suppress the warning introduced in
https://github.com/swiftlang/swift/pull/75378. The RegexParser module, which is
effectively part of the standard library, declares a Swift runtime symbol and
as a result every build of the compiler and stdlib produces warnings which
there are no plans to address. Warnings that are not going to be addressed need
some way of being suppressed, and an experimental features seems like a
reasonable mechanism for this one.
A bug in `@objc @implementation` is causing incorrect `@_hasStorage` attributes to be printed into module interfaces. As an initial step towards fixing this, diagnose bad `@_hasStorage` attributes and treat them as computed properties so that these malformed interfaces don’t cause compiler crashes.
Partially fixes rdar://144811653.
A same-type constraint in an enclosing `where` clause will eliminate a generic parameter’s ABI impact. Teach `ABIDeclChecker::checkType()` about this so it can handle a known-unsupported case for `Swift.Result.init(catching:)`.
This commit compares the attributes on the decl inside the `@abi` attribute to those in the decl it’s attached to, diagnosing ABI-incompatible differences. It also rejects many attributes that don’t need to be specified in the `@abi` attribute, such as ObjC-ness, access control, or ABI-neutral traits like `@discardableResult`, so developers know to remove them.
This commit compares the decl inside the `@abi` attribute to the decl it’s attached to, diagnosing ABI-incompatible differences. It does not yet cover attributes, which are a large undertaking.
`AvailabilityRange` is now being used as a currency type in more of the
compiler, and some of those uses are in permanent `ASTContext` allocations. The
class wraps the `VersionRange` utility, which is itself a wrapper around
`llvm::VersionTuple` with some additional storage for representing sentinel
values. Even though the two sentinel values can be be represented with just a
single bit of additional storage on top of the 16 bytes required to represent
`VersionTuple`, because of alignment requirements the sentinel values end up
bloating the layout of `VersionRange` by many bytes.
To make `AvailabilityRange` and `VersionRange` more efficient to store, we can
instead reserve two unlikely `llvm::VersionTuple` bit patterns as the sentinel
values instead. The values chosen are the same ones LLVM uses to represent
version tuple tombstones and empty keys in a `DenseMap`.
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.
Delay resolution of availability domain identifiers parsed in availability
specifications until type-checking. This allows custom domain specifications to
be written in `if #available` queries.
This will unblock parsing and type-checking availability queries that specify
custom availability domains, e.g.:
```
if #available(CustomDomain) {
// Use declarations protected by @available(CustomDomain)
}
```
Implement lookup of availability domains for identifiers on
`AvailabilityDomainOrIdentifier`. Add a bit to that type which represents
whether or not lookup has already been attempted. This allows both
`AvailableAttr` and `AvailabilitySpec` to share a common implementation of
domain lookup.
In order to unblock resolution of availability domains during type-checking
instead of parsing, diagnostics about missing or superfluous wildcards in
availability specification lists need to move to Sema.
According to the proposal both variants cannot be used together
with other forms of isolation i.e. isolated parameters, global
actors, `@isolated(any)` attributes.
Switch to calling `swift::getAvailabilityConstraintsForDecl()` to get the
unsatisfied availability constraints that should be diagnosed.
This was intended to be NFC, but it turns out it fixed a bug in the recently
introduced objc_implementation_direct_to_storage.swift test. In the test,
the stored properties are as unavailable as the context that is accessing them
so the accesses should not be diagnosed. However, this test demonstrates a
bigger issue with `@objc @implementation`, which is that it allows the
implementations of Obj-C interfaces to be less available than the interface,
which effectively provides an availability checking loophole that can be used
to invoke unavailable code.
