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
This comes up when an imported error enum has duplicate cases.
The FooError.Code enum has an alias for the duplicate case, and
the wrapper type FooError defines aliases for every member of
FooError.Code.
The implementation of importEnumCaseAlias() assumed that 'original'
was an EnumElementDecl, and built AST accordingly; however if it
is a 'VarDecl', we have to build a MemberRefExpr instead.
This regression was introduced in https://github.com/apple/swift/pull/25009.
Fixes <rdar://problem/58552618>.
Add an algorithm to go search the override tables *and* the existing
loaded members of a class for a redeclaration point. The idea is that
both mirrored protocol members and categories offer a way to convince
the Clang Importer to import a property twice. We support a limited form
of this multiple-imports behavior today by allowing the redeclared
property to refine a readonly property into a readwrite property.
To maintain both the refinement behavior and to disambiguate any
remaining cases of ambiguity caused by extensions, attempt to identify
a redeclaration point if we can't identify an override point. Then,
decline to import the redeclared member if we're successful.
Note that the algorithm as presented is subject to import ordering. That
is, if a framework declares both an overlay and a clang module unit, if
the overlay is not loaded or members from the overlay are not installed
in the class by the time we see the declaration we may fail to identify
an redeclaration point.
The regression tests are for rdar://59044692, rdar://59075988, and
rdar://59125907.
Once lazy loading supports mirrored protocol members, we can end up
calling importSubscript() for a setter method before we've mirrored
the getter. In this case, we call findCounterpart() with the setter,
which finds the imported getter from the ProtocolDecl itself.
Stop processing the potential subscript in this case, since when we
later mirror the protocol member, we'll go and build it again.
This should be NFC without the next change I'm working on.
