Note that new code path doesn't actually seem to be taken, due to
NameImporter logic that renames non-member operators differently.
Adds some test case to at least document current behavior.
When generating a reverse interop header for a Swift module that declares `func ===` for a Swift type, we were printing `operator===`, which isn't valid in C++.
This teaches reverse interop to only print operators that are valid in C++.
rdar://169474185
c2952b7 mistakenly treated the binary C++ operator*() ("multiply") as
the unary operator*() ("dereference"), preventing ClangImporter from
synthesizing the Swift func *(_:_) operator. This patch fixes the issue
and adds some tests to exercise the scenario.
rdar://169448888
We only added the old attributes but those are not picked up by
ASTPrinter. This PR adds inherited entries which is the correct
representation of these conformances.
rdar://157868143
Confusingly, isObjC on an existential does not check if the super class
is actually ObjC. Make the check stricter to avoid a crash down the
line.
rdar://169210092
On some Linux versions (e.g. UBI9) this test failed because __counted_by
was already defined, but defined to nothing. I haven't figured out how
or why, because I was debugging via CI output, but this should fix it.
rdar://163085444
Windows paths can contain colons (etc. C:\foo\bar), which the diagnostic
verifier would confuse for the end of the path. By quoting them we can
ignore all colons until the matching single quote character.
This makes sure that Swift correctly imports `CF_OPTIONS`/`NS_OPTIONS` types in C++ interop mode, such as:
```
typedef CF_OPTIONS(NSUInteger, TEST(Enum))
```
`CF_OPTIONS`/`NS_OPTIONS` macros have different expansions in C++ language mode, which forces us to have extra logic to handle them correctly with C++ interop enabled.
rdar://166528719
Protocol conformance checking requests a qualified name lookup of
"successor()", not "successor", which is a compound name with zero
arguments rather than a simple name.
Teach ClangRecordMemberLookup to be aware of this. Without accounting
for this, protocol conformances will fail.
rdar://169217941
At the moment plugin paths do not get passed along when consuming a
textual interface of an imported module. Normally this is not an issue,
because all macros have already been expanded at this point, but this is
not the case for _SwiftifyImport which belongs to a clang module but is
expanded while gompiling a dependent Swift module. This would cause an
error when trying to expand the macro. Since most textual interfaces
don't call any safe wrappers at the moment, this unblocks the
compilation by checking whether the macro plugin can be loaded before
attaching the macro, and emitting a warning if not. Long term we'll want
to pass along the plugin path to swift-api-digester, but this will do
for now.
rdar://168967555
This removes the swiftifyProtocol function, because it fundamentally
incompatible with our layering. By iterating over the protocol members
of the node we are currently importing, we immediately force all members
to be imported. This can lead to cycles and various hard-to-debug import
failures. Instead we need to attach the extension macro when importing
each invidvidual method. This will take some plumbing however, because
that may happen after the protocol's macros have already been expanded,
preventing later macros from being expanded.
rdar://168500103
This PR introduces implicit bridging from annotated smart pointers to
reference counted objects to Swift foreign reference types. The bridging
only happens when these smart pointers are passed around by value. The
frontend only sees the Swift foreign reference types in the signature
and the actual bridging happens during SILGen when we look at the
original clang types and note that they differ significantly from the
native types.
The bridging of parameters did not quite fit into the existing structure
of bridging conversions as smart pointers are non-trivial types passed
around as addresses and existing bridging conversions were implemented
for types passed directly.
rdar://156521316
If a C++ method returns a foreign reference type as a pointer (`MyImmortal*`), Swift correctly treats the method as safe. However, if the method returns a foreign reference type as a reference (`MyImmortal&`), Swift assumed that the method is unsafe.
This change adjusts the heuristic to treat such methods as safe. It also addresses a FIXME comment: previously, if the returned foreign reference type has inherited its `import_reference` attribute from a base class, the safety heuristic did not correctly detect the type as an FRT.
rdar://168057355
[Swiftify] get module from canonical decl
This aligns the logic in SwiftifyDecl.cpp for fetching the owning module with that of the rest of the compiler. Previously we would fetch the owning module from the clang decl directly associated with the Swift decl, whereas the rest of the compiler looks at the canoncial (first) decl to determine ownership. This mismatch resulted in a state where swiftifyImpl did not think the decl originated in a bridging header (because it was not imported into the __ObjC module), but it also didn't find an owning module on the clang decl. This occured when a bridging header would import a header from a module, and then redeclare a function from that module.
rdar://168703691
When compilng for tvOS, `availability(ios,introduced=2.0)` seems to
imply `availability(tvos)`. This gets imported as `@available(tvOS)`,
which is invalid Swift syntax. Normally this attribute has no effect,
but when attaching a macro to such a function the macro gets invalid
Swift syntax as input.
rdar://168272342
This aligns the logic in SwiftifyDecl.cpp for fetching the owning module
with that of the rest of the compiler. Previously we would fetch the
owning module from the clang decl directly associated with the Swift
decl, whereas the rest of the compiler looks at the canoncial (first)
decl to determine ownership. This mismatch resulted in a state where
swiftifyImpl did not think the decl originated in a bridging header
(because it was not imported into the __ObjC module), but it also didn't
find an owning module on the clang decl. This occured when a bridging
header would import a header from a module, and then redeclare a
function from that module.
rdar://168703691
Currently the importer simply adds new "synthesized protocol" attribute
for `Sendable` which is problematic during type-checking because the new
attribute is supposed to replace `@Sendable` and properly synthesize the
conformance.
Resolves: rdar://158224838
Android uses libc++, just like Darwin, so it has the same error message
for the constructor, not the one linux has with libstdc++, so check the
specific OS also.
Otherwise, we see this error on the Android
CI:
```
15:49:14 // expected-TEST7-LINUX-error@-7 {{call to deleted constructor of 'std::unique_ptr<int>'}}
15:49:14 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
15:49:14 call to implicitly-deleted copy constructor of 'std::unique_ptr<int>'
```
We were previously marking synthesized FRT initializers as
"returns_retained" unconditionally (for non-immortal types), which can
cause memory errors and also suppresses diagnostics about the lack of
such annotations.
This patch fixes that behavior, and also adjusts the source locations of
the synthesized C++ factory method to point to the actual constructor
decl when its location is available, so that the diagnostics make sense
when warning about the lack of annotations.
rdar://163127315
