`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`.
Introduce a constructor that takes an `llvm::VersionTuple` directly, instead of
needing to spell out `VersionRange::allGTE(<tuple>)` which is unnecessarily
verbose.
Introduced `SemanticAvailabilitySpecRequest` to retrieve the semantic spec for
an `AvailabilitySpec`. Add an `isInvalid` bit to `AvailabilitySpec` to track
whether the request failed. Unfortunately, there aren't any easily accessible
spare bits in the layout of `AvailabilitySpec` so it had to be a new field.
ClangImporter can now import non-public members as of be73254cdc and 66c2e2c52b, but doing so triggers some latent ClangImporter bugs in projects that don't use or need those non-public members.
This patch introduces a new experimental feature flag, ImportNonPublicCxxMembers, that guards against the importation of non-public members while we iron out those latent issues. Adopters of the SWIFT_PRIVATE_FILEID feature introduced in bdf22948ce can enable this flag to opt into importing private members they wish to access from Swift.
rdar://145569473
To pave the way for the new experimental feature which will operate on '@const' attribute and expand the scope of what's currently handled by '_const' without breaking compatibility, for now.
Unfortunately, Unsafe*Pointer types do not support non-escapable
pointees so we do not really have anything to map these types to at the
moment. Previously, importing such code resulted in crashes.
rdar://145800679
Bridge the category name and educational note computed for the Swift
compiler's diagnostics to the newly-introduced category field for
the swift-syntax diagnostics. This lets the swift-syntax renderer
introduce the category name and (optionally) link to the
documentation.
This makes more efficient use of the permanent memory allocated for
`AvailabilityContext` representations and also fixes a leak that was introduced
in https://github.com/swiftlang/swift/pull/79718 where the small vector for
unavailable domain storage was not being cleaned up on `ASTContext`
deallocation.
Resolves rdar://145929932.
Choose names that don't imply availability is versioned, since custom
availability will support domains that are version-less (they are simply
available or unavailable).
Introduce `SemanticAvailableAttr` conveniences to compute the deprecated and
obsoleted ranges for an attribute and ensure they remap versions when needed.
Now that `AvailabilityContext` supports multiple unavailable domains, it's no
longer necessary to have a total ordering amongst the Swift,
PackageDescription, and Embedded availability domains.
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.
The serialized diagnostic format has some extra fields that we can
adopt for diagnostic groups. Specifically:
* Category: store the diagnostic group name here
* Flags: extend the hack used by educational notes of placing Markdown file paths here
The algorithm already performs pairwise checks on module dependencies brought into compilation per-source-file. Previously, the algorithm considered the entire sub-graph of a given source file. Actual source compiles do not consider the full transitive module dependency set for cross-import-overlay lookup, but rather only directly-imported modules in a given source file, and '@_exported import' Swift transitive dependencies.
This change adds tracking of whether a given import statement is 'exported' to the dependency scanner and then refines the cross-import overlay lookup logic to only consider transitive modules that are exported by directly-imported dependencies.
