If we try to import this in ObjC interop mode:
```objc
typedef CF_OPTIONS(uint32_t, MyFlags) {
...
} CF_SWIFT_NAME(MyCtx.Flags);
struct MyStruct {
MyFlags flags;
...
} CF_SWIFT_NAME(MyCtx);
```
ClangImporter tries to import `MyCtx/MyStruct` before it imports
`MyFlags` (via `importDeclContextOf()`), which in turn tries to import
`MyFlags` again due to the `flags` field. The existing cycle-breaking
mechanism prevents us from looping infinitely, but leads us to import
two copies of the Swift `EnumDecl`, which can cause errors later during
CodeGen.
~~This patch adds an assertion to catch such issues earlier, and breaks
the cycle by checking the cache again.~~ This patch no longer does so
because that caused issues beyond the scope of this patch.
rdar://162317760
Make sure the destination type actually conforms to the corresponding
builtin literal protocol before attempting to import it. We may want
to consider allowing any type that conforms to the non-builtin literal
protocol, but I want to keep this patch low risk and just ensure we at
least don't crash for now.
rdar://156524292
It hoists `destroy_value` instructions for non-lexical values.
```
%1 = some_ownedValue
...
last_use(%1)
... // other instructions
destroy_value %1
```
->
```
%1 = some_ownedValue
...
last_use(%1)
destroy_value %1 // <- moved after the last use
... // other instructions
```
In contrast to non-mandatory optimization passes, this is the only pass which hoists destroys over deinit-barriers.
This ensures consistent behavior in -Onone and optimized builds.
Whenever we have a reference to a foreign function/variable in SIL, use
a mangled name at the SIL level with the C name in the asmname
attribute. The expands the use of asmname to three kinds of cases that
it hadn't been used in yet:
* Declarations imported from C headers/modules
* @_cdecl @implementation of C headers/modules
* @_cdecl functions in general
Some code within the SIL pipeline makes assumptions that the C names of
various runtime functions are reflected at the SIL level. For example,
the linking of Embedded Swift runtime functions is done by-name, and
some of those names refer to C functions (like `swift_retain`) and
others refer to Swift functions that use `@_silgen_name` (like
`swift_getDefaultExecutor`). Extend the serialized module format to
include a table that maps from the asmname of functions/variables over
to their mangled names, so we can look up functions by asmname if we
want. These tables could also be used for checking for declarations
that conflict on their asmname in the future. Right now, we leave it
up to LLVM or the linker to do the checking.
`@_silgen_name` is not affected by these changes, nor should it be:
that hidden feature is specifically meant to affect the name at the
SIL level.
The vast majority of test changes are SIL tests where we had expected
to see the C/C++/Objective-C names in the tests for references to
foreign entities, and now we see Swift mangled names (ending in To).
The SIL declarations themselves will have a corresponding asmname.
Notably, the IRGen tests have *not* changed, because we generally the
same IR as before. It's only the modeling at the SIL lever that has
changed.
Another part of rdar://137014448.
This test was only run with NDK 28 locally, so we didn't realize this
feature won't work with Bionic in LTS NDK 27, which is what the CI uses.
We will re-enable this with the next LTS NDK release, when we switch the
Android CI to use that next LTS NDK.
Replace the `here` part of the generic exportability diagnostic for
variables with: `in a property declaration marked public or in a
'@frozen' or '@usableFromInline' context`.
The full diagnostic now looks like:
```
error: cannot use struct 'ImportedType' in a property declaration marked
public or in a '@frozen' or '@usableFromInline' context;
'HiddenDependency' has been imported as implementation-only
```
This should be improved further to support implicitly exported memory
layouts in non-library-evolution and embedded.
This is a tiny improvement to the diagnostic messages emitted by Swift. Conventionally we wrap identifiers, such as module names, in single quotes in the diagnostic messages.
rdar://138812125
Specifically, this means importing getters defined via swift_async_name. This
just ensures that they are treated just like any other imported objc async
function with completion handler.
rdar://156985950
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
A "permanently enabled" availability domain is one that has been declared
always available and is also simultaneously has either an attribute that
makes it deprecated or universally unavailable.
Emit fix-its that remove (or update) `@available` attributes that restrict
availability in a permanently enabled domain. Also, emit warnings about
`if #available` queries that always return true because they check a
permanently enabled domain.
Resolves rdar://157601761.
Internally-imported bridging headers must not leak outside of the Swift
module. Don't serialize their contents, and make sure we can still
import the module even if the bridging header has been removed.
It's very, very easy to make a mistake that will cause broken
serialized modules. Until that's no longer true, at least tell folks
that they are heading into uncharted waters, as we do with
`@_implementationOnly` imports.
C++ namespaces always get imported into the bridging header's module
for Reasons. Exempt them from internal-import checking, since we get
checking for the namespace members that are actually used.
When using an internal import for a bridging header, semantically treat
the contents of the bridging header, and anything that it imports, as
if they were imported internally. This is the actual semantic behavior
we wanted from internally-imported bridging headers.
This is the main semantic checking bit for rdar://74011750.
The flags "-import-bridging-header" and "-import-pch" import a bridging
header, treating the contents as a public import. Introduce
"internal-" variants of both flags that provide the same semantics,
but are intended to treat the imported contents as if they came in
through an internal import. This is just plumbing of the options for
the moment.
This is similar to ced4cb06.
Clang stores macro information for each identifier inside of `IdentifierInfo`, which can sometimes get outdated. Clang solves this by updating the identifier info if necessary in `getLeafModuleMacros`. Let's do the same in Swift.
This makes sure that macros that reference other macros are correctly imported with C++ interop enabled.
rdar://145584369
rdar://110071334
This allows diagnostics to be more precise and will also support logic that
allows for special cases for `@available` attributes in exportability checking.
Also fixes a bug where the exportability of `@available` attributes attached to
extensions were diagnosed twice for slightly differing reasons.
Cover all va_list family of types just aliased by __builtin_va_list, including __isoc_va_list from wasi-libc. This enables proper C interop for variable argument functions on WASI targets.
Close https://github.com/swiftlang/swift/issues/72398
Previously we would skip type-checking the result expression of a
`return` or the initialization expression of a binding if the contextual
type had an error, but that misses out on useful diagnostics and
prevents code completion and cursor info from working. Change the logic
such that we open ErrorTypes as holes and continue to type-check.
Teach Sema to diagnose the access level, exportability, and availability of
availability domains that are referenced by `@available` attributes and
`if #available` statements.
Resolves rdar://159147207.
When emitting statement diagnostics for `if #available` queries, diagnose the
availability of the decls representing the referenced availability domains.
Among other things, this checks that the domains are sufficiently visible to be
used in the containing function body context.
