Set the synthesized constructor's return result to nullptr and add an ASTVerifier check that the constructor's return statement does not contain a result.
This adds support to `ClangImporter` to import C++ member function operators as static methods into Swift, which is part of SR-12748.
The left-hand-side operand, which gets passed as the `this` pointer to the C++ function is represented as an additional first parameter in the Swift method. It gets mapped back in SILGen.
Two of the tests are disabled on Windows because we can't yet call member functions correctly on Windows (SR-13129).
The Clang importer has an old hack that makes OS_object and its subclasses
implicitly "objc_runtime_visible" (which maps to the "runtime" foreign
class kind in Swift). Now that the headers in the SDK all use the
appropriate annotation, remove the hack.
Fixes rdar://problem/64778416.
The default C++ object constructor assigns the newly created object out of the function so, it should not return a value. Returning a value will trigger SILGen assertions.
Previously inherited constructors would be skipped from added in member list, depending on the order of request evaluator calls.
This was a regression compared to swift 5.2
clang::Decl::isHidden() is misleadingly named (see the associated FIXME
comment) and doesn't do what we want when
`-fmodules-local-submodule-visibility` is turned on.
This change alone isn't unfortunately enough to make Swift work with
`-fmodules-local-submodule-visibility`. For one thing, Clang's
Objective-C component doesn't work correctly with
`-fmodules-local-submodule-visibility`:
https://bugs.llvm.org/show_bug.cgi?id=46248
However, in the meantime, we should still clean up our use of
clang::Decl::isHidden().
The ClangImporter currently calls into
`ObjCSelector`'s `lookupDirect` in a couple of
places, stashing the selector in a DenseMap to try
and avoid re-entrancy problems.
However this will become a problem once
`ObjCSelector`'s `lookupDirect` is both
requestified and starts pulling in members from
the main module, so migrate the ClangImporter off
calling it.
Fortunately most of its uses only care about decls
with associated Clang nodes. For those cases, we
can use the existing member table, making sure to
populate it with any method we import.
In one case, the ClangImporter needs to check to
see if there's a deserialized Swift method with a
matching selector. Instead of calling through to
`lookupDirect`, let's just query the Swift module
loaders directly.
This imports const members of C++ structs/classes stored properties with
an inaccessible setter.
Note that in C++ there are ways to change the values of const members,
so we don't use `WriteImplKind::Immutable` storage.
Resolves: [SR-12463](https://bugs.swift.org/browse/SR-12463)
* Don't import C++ class members that are protected or private.
We omit protected members in addition to private members because Swift
structs can't inherit from C++ classes, so there's effectively no way to
access them.
* Check access specifiers centrally in importDeclImpl().
* Fix macOS build by using <stddef.h> instead of <cstddef>.
Apparently, the macOS toolchain doesn't provide <cstddef>.
<stddef.h> is used in test/Inputs/clang-importer-sdk/usr/include/macros.h,
so I'm assuming it will be OK. (I don't unfortunately have a macOS
machine to test on.)
* Add comment explaining why we skip private and protected C++ class
members.
Non-identifier names aren't currently an issue, but it will become one
when we add more support for C++, e.g. for C++ constructors (which I
plan to tackle soon).
Recent clang side change merges ObjCCategoryDecl with the same name. All re-declarations
of a category points to the first category as the canonical one. This patch keeps these
non-canonical redeclarations as separate extensions in Swift.
rdar://problem/59744309
