Emit the category documentation URL into serialized diagnostics as part of
the existing RECORD_CATEGORY, using the form
<category name>@<category URL>
and keeping the existing "category name length" field referring to the
length of the category name itself (up to the @). There is a corresponding
update to libclang to process such category names correctly and add
API, but it isn't strictly necessary: readers that use the category
name length field correctly will see no behavior change, whereas
readers that ignore it will merely see the extra `@<category URL>`.
This is a step toward staging out our (mis)use of the "flags" field as
the place to stash educational note and diagnostic group documentation
URLs.
Introduce the experimental feature InferIsolatedConformances to align
with the upcoming feature proposed in SE-0470. This is a slight
generalization of the main-actor-specific inference that was already
in place for the default-main-actor mode from SE-0466. Note that, as
specified in SE-0470, InferIsolatedConformances is implied by the
default-main-actor mode.
`-Xfrontend -enable-cond-fail-message-annotation`
LLVM IR produced by the Swift compiler will add the `annotation`
metadata attribute to the branch instruction generated for cond_fail
builtins.
With '-sdk-module-cache-path', Swift textual interfaces found in the SDK will be built into a separate SDK-specific module cache.
Clang modules are not yet affected by this change, pending addition of the required API.
Regardless of the value specified for `-unavailable-decl-optimization`, decls
that are unavailable in custom availability domains should be treated as always
unreachable at runtime.
Part of rdar://138441307.
It is possible for a module interface (e.g., ModuleA) to be generated
with C++ interop disabled, and then rebuilt with C++ interop enabled
(e.g., because ModuleB, which imports ModuleA, has C++ interop enabled).
This circumstance can lead to various issues when name lookup behaves
differently depending on whether C++ interop is enabled, e.g., when
a module name is shadowed by a namespace of the same name---this only
happens in C++ because namespaces do not exist in C. Unfortunately,
naming namespaces the same as a module is a common C++ convention,
leading to many textual interfaces whose fully-qualified identifiers
(e.g., c_module.c_member) cannot be correctly resolved when C++ interop
is enabled (because c_module is shadowed by a namespace of the same
name).
This patch does two things. First, it introduces a new frontend flag,
-formal-cxx-interoperability-mode, which records the C++ interop mode
a module interface was originally compiled with. Doing so allows
subsequent consumers of that interface to interpret it according to the
formal C++ interop mode. Note that the actual "versioning" used by this
flag is very crude: "off" means disabled, and "swift-6" means enabled.
This is done to be compatible with C++ interop compat versioning scheme,
which seems to produce some invalid (but unused) version numbers. The
versioning scheme for both the formal and actual C++ interop modes
should be clarified and fixed in a subsequent patch.
The second thing this patch does is fix the module/namespace collision
issue in module interface files. It uses the formal C++ interop mode to
determine whether it should resolve C++-only decls during name lookup.
For now, the fix is very minimal and conservative: it only filters out
C++ namespaces during unqualified name lookup in an interface that was
originally generated without C++ interop. Doing so should fix the issue
while minimizing the chance for collateral breakge. More cases other
than C++ namespaces should be added in subsequent patches, with
sufficient testing and careful consideration.
rdar://144566922
Temporarily make action cache update non-fatal and not failing the job.
The action cache update failure can happen due to cache poisoning from
non-deterministic compiler output. Assume the errors from the
non-determinism is benign and can be ignored till all issues are
resolved.
rdar://146780363
Added an `-executor-factory` argument to the compiler to let you safely
specify the executors you wish to use (by naming a type that returns
them).
Also added some tests of the new functionality.
rdar://141348916
Store `CustomAvailabilityDomain` instances in a folding set on `ASTContext`.
This instances of custom domains to be created without needing to cache them in
disparate locations.
This removes a workaround from the module interface loader, which was forcing Darwin to be rebuilt from their textual interfaces with C++ interop disabled, even if the current compilation explicitly enables it.
See also 3791ccb6.
rdar://142961112
https://github.com/swiftlang/swift/pull/37774 added '-clang-target' which allows us to specify a target triple that only differs from '-target' by the OS version, when we want to provide a different OS version for API availability and type-checking, in order to set a common/unified target triple for the entire Clang module dependency graph, for presenting a unified API surface to the Swift client, serving as a maximum type-checking epoch.
This change adds an equivalent flag for the '-target-variant' configuration, as a mechanism to ensure that the entire module dependency graph presents a consistent os version.
For build systems that already generate these files, it makes sense to include the aliases so that the map file serves as a comprehensive index of how the module inputs are referenced.
The original module names themselves must still be valid unescaped identifiers; most of the serialization logic in the compiler depends on the name of a module matching its name on the file system, and it would be very complex to turn escaped identifiers into file-safe names.
When printing diagnostics, category names are printed as [#<category-name>]
at the end of a diagnostic. For all of the category names that are mentioned
in this manner, print "footnotes" at the end of compilation providing
documentation references to each category, e.g.,
[#deprecated]: <http://example.com/deprecated>
[#StrictMemorySafety]: <http://example.com/memory-safety>
Right now, these point into the markdown files in the installed toolchain,
same as the URLs behind references. That is subject to change in the future.
This removes a workaround from the module interface loader, which was forcing AppKit and UIKit to be rebuilt from their textual interfaces with C++ interop disabled, even if the current compilation explicitly enables it.
The workaround was previously put in place because of a compiler error:
```
error: type 'AttributeScopes.AppKitAttributes.StrikethroughStyleAttribute' does not conform to protocol 'AttributedStringKey'
note: possibly intended match 'AttributeScopes.AppKitAttributes.StrikethroughStyleAttribute.Value' (aka 'NSUnderlineStyle') does not conform to 'Hashable'
```
`NSUnderlineStyle` is a C/C++ type from AppKit that is declared using `NS_OPTIONS` macro. `NS_OPTIONS`/`CF_OPTIONS` macros have different expansions in C vs C++ language modes. The C++ expansions weren't handled correctly by ClangImporter, resulting in two distinct Swift types being created: a `typealias NSUnderlineStyle` which was marked as unavailable in Swift, and `enum NSUnderlineStyle`. This mostly worked fine, since the lookup logic was picking the enum during regular name lookup. However, this silently broke down when rebuilding the explicit conformance from `AppKit.swiftinterface`:
```
extension AppKit.NSUnderlineStyle : Swift.Hashable {}
```
Swift was picking the (unavailable) typealias when rebuilding this extension, which means the (available) enum wasn't getting the conformance.
This is verified by an existing test (`test/Interop/Cxx/objc-correctness/appkit-uikit.swift`).
rdar://142961112
When it's available, use an open-coded allocator function that returns
an alloca without popping if the allocator is nullptr and otherwise
calls swift_coro_alloc. When it's not available, use the malloc
allocator in the synchronous context.
This allows external tools to locate the metadata pointer without needing to call the accessor function.
This is only useful for non-generic types, so we borrow the HasCanonicalMetadataPrespecializations flag to indicate the presence of this pointer on non-generic types, and it continues to indicate the presence of prespecializations for generic types.
Only emit this pointer for internal/private types with no runtime initialization. Public type metadata can be found with the symbol, and it's not useful for types that require runtime initialization.
This patch adds support for emitting the flag
llvm::DINode::FlagAllCallsDescribed when generating LLVM IR from the
Swift compiler to get call-site information for swift source code.
