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.
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
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
This fixes two bugs:
1) The outermost pointee type is not necessarily a nominal type. There
can e.g. be a pointer to an array (tuple) type. This would result in a
null pointer dereference. Instead of assuming direct pointee nominal
types, we now check for nominal types anywhere in the type hierarchy.
2) Enum types can also be forward declared. Instead of checking for
clang::RecordDecl, we now check for clang::TagDecl (which is a base
class of clang::RecordDecl and clang::EnumDecl).
rdar://165864358
Somehow these tests passed CI despite being incorrect from the start.
The original intention with the bridging header import fix was to only
stop re-importing the AST nodes from the bridging header, but still have
the macro expansions implicitly import the bridging header module. I
accidentally returned true instead of false in importBridgingHeader,
which resulted in the macro expansions not importing the bridging header
module. This turned out to be fine however, because the macro expansion
won't refer to anything in the bridging header. So instead update the
tests to reflect this. This also adds a test to verify that the macro
expansion can still access symbols from a C++ namespace despite not
importing the __ObjC module.
While the clang macro expansion SourceFile ought to resolve the bridging
header as an implicit import, the contents of the bridging header have
already been imported at this point, so there's no need to do it again.
Other than being bad for performance, this would also result in
compilation errors in non-ObjC mode when the header contained
definitions (not just declarations), since the same ClangImporter would
import the header twice, resulting in redefinitions (unless the header
contained header guards). In ObjC mode this would not manifest, because
the bridging header is imported using `#import` in that mode, so header
guards are not needed.
rdar://165851601
This prevents stuff like memcmp from SwiftShims from being imported with
@_SwiftifyImport, which would then result in name lookup errors as it
does not import the Swift standard library module. This makes the
previous approach to disable safe interop when compiling with
-parse-stdlib redundant.
irdar://165856959
Since decls with no module are imported to __ObjC this is not an issue,
because __ObjC is always implicitly imported. Added test case that would
previously assert.
This fixes an assert when signatures contain
`struct forward_declared_t **`, and makes sure that
`struct foo { struct forward_declared_t *bar; }` does *not* block
swiftification, since `@_SwiftifyImport` does not need to access the
struct field.
A Swift module only imports a type definition once. This means that some
clang modules may have function signatures imported with
`UnsafePointer<qux>` even if `qux` is only forward declared in that
module (which would normally be imported as `OpaquePointer`), because
some Swift file in the module imported the clang module with the
definition, so ClangImporter sees the definition. The macro expansion
only imports the imports of the clang module it belongs to however, so
namelookup for `qux` fails. This patch detects when this will result in
an error and avoids attaching the macro in those cases.
rdar://165864358
These cases would trigger an assert in both release and debug builds.
With this change they are ignored in release mode, and cases that are
both unhandled and unknown trigger an assert in debug mode.
rdar://166074719
Any safe wrapper expansion originating in a bridging header would fail
typechecking because the `__ObjC` module doesn't import the standard
implicit imports. This is because the main module is not available to
inherit implicit imports from when the `__ObjC` module is created. We
don't need all of the implicit modules for safe wrappers, so import
`Swift` specifically.
rdar://163078116
Inheriting a clang import marked `requires: !swift` will always result
in an error. This skips such imports, which *may* result in name lookup
errors instead, but also may not, depending on the module.
rdar://161795145
`span` is not available in all versions of libstd++, so make it a
conditional header. Also adds other missing c++20 headers.
Fixing this triggered an assert when importing a constant initialized
`wchar_t` variable, so that is also fixed. The reason is that `wchar_t`
is mapped to `Unicode.Scalar`, which cannot be directly initialized by
integer literals in Swift, triggering an assert when looking up the
protocol conformance for `_ExpressibleByBuiltinIntegerLiteral`.
rdar://162074714
Since the compiler invokation performing the macro expansion dump
redirects its stderr output, any errors are not displayed by default.
This is extra problematic for test failures in CI. By performing the
compiler invokation with -verify first, errors are shown.
Importing clang submodules results in an implicit import of the
top-level module as well. This can result in the same TLM being imported
many different times, if multiple submodules are imported from the same
module. This deduplicates these imports.
Other imports are not expected to be duplicated, so care is taken to
only deduplicate clang TLM imports.
Non-explicit submodules don't need to be explicitly added to the list of
imports to be visible, since their decls are implicitly exported. Skip
these modules even when present in the list of imports. Explicit
submodules are imported *regardless* of whether another module
imports them however.
The imported top-level module inherits the imports of all its
(transitive) submodules. Since multiple submodules can import the same
modules these need to be deduplicated to avoid redundant work.
