Accept `@cdecl` enums without an explicit C name. The C name defaults to
the Swift one. It is printed using the `SWIFT_ENUM` macro instead of
`SWIFT_ENUM_NAMED`.
There are two main scenarios when printing a compatibility header that
references a @cdecl enum defined in Swift code. (1) When defined in the
same module as it's used we can print the definition normally and then
reference it. (2) When used in a different mode we need to print a
forward declaration before we can reference it.
This change adds printing the forward declaration and fix an issue where
the compiler would instead print an @include of the Swift module. The
import of the Swift module would work only in a local scenario where a
compatibility header and module would be generated under the same name.
However for a distributed frameworks we do not distribute the
compatibility header so this strategy doesn't work. Relying on a forward
declaration should be more reliable in all cases but clients may need to
import the other compatibility header explicitly.
Print @cdecl enums in the C section of the compatibility header. Use and
extend the macros to support C compiler clients.
The macro is adapted to the features supported by the client compiler.
It uses an Objective-C style macro with raw type when available and
fallbacks to a simple typedef for C compatibility.
@cdecl enums are Swift enums representable in C. These enums must have
an integer raw type. They can be referenced from @cdecl functions and
@objc methods. @objc enums are still rejected from @cdecl functions.
Begin accepting the attribute in the form of `@cdecl(cName)`, using an
identifier instead of a string.
For ease of landing this change we still accept the string form. We
should stop accepting it before making this feature available in
production.
Start printing `#include` for headers referenced from `@cdecl` function
signatures. This adds on top of the existing tiered imports. We already
print each module referenced from decls printed in the compatibility
header. Previously we printed mostly `@import` with an option to
fallback on a `#import`. This change adds a third fallback to `#include`
when the module is referenced from a `@cdecl` function signature. The
bridging header can also be imported in a similar way.
Add a block for C clients in the compatibility header. This block
contains only the `@cdecl` functions that are printed using only C
types.
This C block is printed above the Objective-C and C++ blocks as if we
add support for `@cdecl` types other languages should be able to
reference them in function signatures. Other languages block don't
duplicate printing the `@cdecl` functions either as they are already
accessible to them.
This implements basic checks on the validity of the @cdecl attribute and
ensures the parameters and result types are representable in C. Many
more diagnostics will need to be updated to verify full representability
in C.
Adds an access control field for each imported module identified. When multiple imports of the same module are found, this keeps track of the most "open" access specifier.
`TypeSimplifier` may not eliminate type variables from e.g the
pattern types of pattern expansion types since they can remain
unresolved due to e.g having a placeholder count type. Make sure we
eliminate any remaining type variables along with the placeholders.
There's probably a more principled fix here, but this is a quick and
low risk fix we can hopefully take for 6.2.
rdar://154954995
A prior change ensured that we forego this query when looking up Swift overlays for a textual interface which was built without C++ interop. This change introduced a bug where it also caused us to skip this lookup for the main source module. This commit resolves that by preserving the fix above but also ensuring we perform the lookup for the main source module under scan.
This results in wrong argument/return calling conventions.
First, the method call must be specialized. Only then the call can be de-virtualized.
Usually, it's done in this order anyway, because the `class_method` instruction is located before the `apply`.
But when inlining functions, the order (in the worklist) can be the other way round.
Fixes a compiler crash.
rdar://154631438
Explanation: There was a null pointer dereference in reverse interop
when we wanted to expose an ObjC class written in Swift. There was a
crash during generating the scaffolding we do for Clang types. Since
the type is written in Swift, no such scaffolding is needed, this patch
skips this operation avoiding the null dereference.
Scope: Reverse C++ interop when exposing @ObjC classes written in Swift.
Issues: rdar://154252454
Original PRs: #82684
Risk: Low, the fix is narrow to the affected scenario.
Testing: Added a compiler test.
Reviewers: @egorzhdan
Currently only declarations would get `nonisolated(nonsending)`
inferred if the upcoming flag is enabled, this changes extend
this to apply to asynchronous nonisolated function types as well.
Resolves: rdar://154808850
(cherry picked from commit bb0cd6f0a6)
We can't assume that type-checking the expression macro in the
parameter will also fail if it fails at the call site since e.g
name lookup may differ. Make sure we only apply this logic to simple
literals.
rdar://154771596
Split out the state mutation into a new `updateFor`
function that we call for diagnostic emission, allowing
`DiagnosticTransaction::hasErrors` to query the behavior without
mutating any state.
If we fail to resolve the value type for a value generic parameter,
previously we would have returned a null Type, causing crashes
downstream. Instead, return an ErrorType, leaving a null Type for
cases where the generic parameter isn't a value generic at all.
rdar://154856417
