The coverage format version we use is automatically
set to whatever the latest version LLVM has. This
resulting in us outputting version 6 as our
format without having made the changes necessary
to reflect the new format. Update the emission
logic to take account for [the new changes in
version 6][1] (we need to include the current
working directory as the first element of the list
of files we output). Additionally, add a
`static_assert` so we don't get caught out by
version bumps in the future. Note we can't pin our
version, as it must stay in sync with the version
Clang is using.
[1]: https://llvm.org/docs/CoverageMappingFormat.html#llvm-ir-representation
Fix the type of the `alloca` created by `GenPack`'s for type metadata
and witness tables by fixing its callee, `emitDynamicAlloca` to always
return a `StackAddress` whose `Address`' type is the one specified by
the caller.
rdar://109540863
The Clang importer's Clang instance may be configured with a different (higher)
OS version than the compilation target itself in order to be able to load
pre-compiled Clang modules that are aligned with the broader SDK, and match the
SDK deployment target against which Swift modules are also built. In this case,
we must use the Swift compiler's OS version triple in order to generate the
binary as-requested.
This change makes 'ClangImporter' 'Implementation' keep track of a distinct
'TargetInfo' and 'CodeGenOpts' containers that are meant to be used by clients
in IRGen. When '-clang-target' is not set, they are defined to be copies of the
'ClangImporter's built-in module-loading Clang instance. When '-clang-target' is
set, they are configured with the Swift compilation's target triple and OS
version (but otherwise identical) instead. To distinguish IRGen clients from
module loading clients, 'getModuleAvailabilityTarget' is added for module
loading clients of 'ClangImporter'.
The notion of using a different triple for loading Clang modules arises for the
following reason:
- Swift is able to load Swift modules built against a different target triple
than the source module that is being compiled. Swift relies on availability
annotations on the API within the loaded modules to ensure that compilation
for the current target only uses appropriately-available API from its
dependencies.
- Clang, in contrast, requires that compilation only ever load modules (.pcm)
that are precisely aligned to the current source compilation. Because the
target triple (OS version in particular) between Swift source compilation and
Swift dependency module compilation may differ, this would otherwise result in
builtin multiple copies of the same Clang module, against different OS
versions, once for each different triple in the build graph.
Instead, with Explicitly-Built Modules, Swift sets a '-clang-target' argument
that ensures that all Clang modules participating in the build are built against
the SDK deployment target, matching the Swift modules in the SDK, which allows
them to expose a maximally-available API surface as required by
potentially-depending Swift modules' target OS version.
--------------------------------------------
For example:
Suppose we are building a source module 'Foo', targeting 'macosx10.0', using an
SDK with a deployment target of 'macosx12.0'. Swift modules in said SDK will be
built for 'macosx12.0' (as hard-coded in their textual interfaces), meaning they
may reference symbols expected to be present in dependency Clang modules at that
target OS version.
Suppose the source module 'Foo' depends on Swift module 'Bar', which then
depends on Clang module `Baz`. 'Bar' must be built targeting 'macosx12.0'
(SDK-matching deployment target is hard-coded into its textual interface). Which
means that 'Bar' expects 'Baz' to expose symbols that may only be available when
targeting at least 'macosx12.0'. e.g. 'Baz' may have symbols guarded with
'__MAC_OS_X_VERSION_MIN_REQUIRED >= __MAC_12_0'. For this reason, we use
'-clang-target' to ensure 'Baz' is built targeting 'macosx12.0', and can be
loaded by both 'Foo' and 'Bar'.
As a result, we cannot direclty use the Clang instance's target triple here and
must check if we need to instead use the triple of the Swift compiler instance.
Resolves rdar://109228963
Arguments that have been loaded due to underlying method conversion
have to be destroyed after the call otherwise they are going to leak.
Resolves: https://github.com/apple/swift/issues/65853
Resolves: rdar://109207043
Use the signature to get the function type when getting Swift function pointer callees.
This is okay because there is a previous call to cast to that type using the Signature
* [IRGen] Respect optionality of unowned(unsafe) reference properties
rdar://108705703
When generating the type info for fields marked unowned(unsafe) of an optional reference (e.g. AnyObject?), we dropped the fact that it was optional along the way. This caused incorrect tags to be returned when on object of the type was stored in an optional itself and the unowned property contained `nil`. In those cases the outer optional appeared to be `nil` as well, even if it in fact contained a value.
* Fix additional case
As an optimization, there is a fast-cast to non-final classes that just
compares isa pointers. If the source of the cast is an Optional<class>,
though, it's not allowed to "directly compare the isa-pointer"; because
the source might be Optional.none, i.e. null.
Add a check for nil when emitting the fast class cast.
rdar://108614878
We started using clang to emit the _OBJC_PROTOCOL_ definition.
But we would use a different name for the proto_list definition than clang.
"OBJC_LABEL_PROTOCOL$" (objc)
|--> OBJC_PROTOCOL
"\01l_OBJC_LABEL_PROTOCOL$_" (swift)
|--> OBJC_PROTOCOL
If an Objective C object also emitted the same protocol definition you could
end up in a situation where both clang's and swift's proto_list definitions
point to the same protocol definition.
Older linkers don't like that.
rdar://108505376
We missed converting such types inside static initializers of global variables.
This results in ptrauth crashes when ptrauth is enabled.
rdar://108165425
Before this patch the parents of SILDebugScopes representing macro expansions
were missing the inlinedAt field, which resulted in incorrent LLVM IR being
produced. This is fixed by first computing the inlined call site for a macro
expansion and then computing the nested SILDebugScope for the ASTScope of the
expanded nodes; adding the inlinedAt field to all of levels of parent scopes.
rdar://108323748
Those builtins always need to assume a thick metatype which is a pointer.
In other words the builtins need to use the maximally abstracted type.
rdar://108308786
* [IRGen] Fix layout string generation for pre-specialized metadata
rdar://108012057
Pre-specialized metadata has to be specifically handled by using the bound generic type instead of the unbound one. All the necessary information is already being passed down as BoundGenericTypeCharacteristics, we just need to apply them when present.
* Add tests and a few fixes
* Fixes after rebase
* Attempt to fix Windows linker issue in test
This entry point doesn't exist on older runtimes. Sema enforces
that constrained existentials don't appear in substitution maps,
however IRGen would sometimes try to instantiate metadata even
if the user didn't do that.
Fixes#64657.
When expanding a conformance macro, the generated extension decls are added to
the TopLevelDecls vector of the synthesized file unit to expose them to
sf->getSynthesizedFile()->getTopLevelDecls(). There are two problems with this:
1. These decls are also visited via visitAuxiliaryDecls() for the purpose of
type checking. This causes problems in code generation because the extensions
are visited separately, and because SIL and IRGen assume nested auxiliary decls
are members.
2. SILGen only emits top-level decls directly from the source file rather than its
synthesized file. Auxiliary decls are visited here, but this doesn't work for
nested conformance macros because the attached-to decl is not at the top-level,
so macro-generated conformances for nested types never emit their descriptor.
To fix this in the short term, visit top-level decls in the synthesized file that are
generated by conformance macros, and skip auxiliary extension decls when emitting type
members. This fix is narrowly scoped to only impact macros, but in the future this
warrants a more structural fix to better handle top-level decls in the synthesized file.
Default system linkers on non-Darwin platforms do not support the `-framework`
argument for framework linking. This change updates autolinking to not emit
`-framework` into the .o _swift1_autolink_entries metadata when there is no
native linker support.
This is related to rdar://106578342.
* [IRGen] Reject enums with inaccessible tpye metadata in layout string generation
rdar://107679697
Because we are currently handling most enums in layout strings by going through the metadata, we have to ensure that the metadata is accessible from the current module and reject the enum otherwise.
* Use proper mechanism to create and reference dylib in test
* Fix linking
* Add rpath to test dylib
When compiling with interop enabled, emit the C++ interop compiler flag
into the DW_AT_APPLE_flags, to make it so LLDB can accurately match the
C++ interop mode when initializing its compiler instance.
rdar://97610458
(cherry picked from commit b1dbb0a321)
