This patch to the Clang Importer avoids an assert by detecting when an
IndirectField belongs to an anonymous union that is not importable. How
it does this is by determining if an IndirectFieldDecl's anonymous
parent field is non-importable (based on isCxxRecordImportable) and if
so skips importing the IndirectFieldDecl.
This avoids the mentioned assert because makeIndirectFieldAccessors
expects a FieldDecl of __Unnamed_union___Anonymous_field that is only
populated when the top-level union is imported from an
IndirectFieldDecl's parent. IndirectFieldDecls for the members of an
anonymous union are dependent on their parent and should not be imported
if their parent can not also be imported.
This corner case can happen in cases when an anonymous union contains an
ARC pointer, which results in a non-trivial but also inaccessible dtor.
While the comment is correct to state that this won't enable any
new optimizations with -Onone, it does enable IRGen's lazy
function emission, which is important for 'reasync' functions,
which we don't want to emit at all even at -Onone.
This fixes debug stdlib builds with the new reasync versions
of the &&, || and ?? operators.
This builds on top of the work of Egor Zhdan. It implements
`T operator[]` and does so largely by taking a path very much like the
`const T &operator[]` path.
If we have a C++ record decl that's invalid (because of a deleted
destructor or copy constructor), bail before we import any of its
members or cache the decl. This way, we don't accidentally import any
"nested" decls.
Fail correctly if we can't import a shadow decl properly. We can
probably support this in the future, but right now, it's more important
that we don't crash while importing.
This change adds support for calling `operator()` from Swift code.
As the C++ interop manifesto describes, `operator()` is imported into Swift as `callAsFunction`.
Lazily instantiate class template members. This means we no longer
reject some programs that clang accepts, such as the following:
```
template<class T> struct Foo { void fail(T value) { value.fail(); } };
using Bar = Foo<int>;
```
The above program will not error so long as `Bar::fail` isn't called.
(Previously, we'd fail to import `Bar`.)
The pattern:
struct X { friend struct Y; }; struct Y {};
is fairly common. But before this commit we would crash while attempting
to add "Y" as a child of "X". This commit simply checks if the child
record is a declaration or definition. If the former, it bails (and the
"child" record will be imported where it's defined).
If a template specialization is more than 8 types deep, bail.
In future we could make this number (much) greater than 8 but first
we'll need to somehow make instantiating these types much fater.
Currently, I think there is some exponential type behavior happening so
this is super slow.
C++ namespaces are module-independent, but enums are owned by their module's in Swift. So, to prevent declaring two enums with the same name, this patch implements a new approach to namespaces: enums with extensions.
Here's an example:
```
// Module A
namespace N { void test1(); }
// Module B
namespace N { void test2(); }
// __ObjC module
enum N { }
// Swift module A
extension N { func test1() }
// Swift module B
extension N { func test1() }
```
Thanks to @gribozavr for the great idea.
Rather than skipping non-definitions, we should just check whether we've
already seen this decl. This not only fixes the specific problem with
class templates but also is a more general fix for other sub decls.
Since the NDK removes the platforms/ and sysroot/ directories in the latest NDK
22, switch to the unified sysroot in toolchains/llvm/ and take advantage of a
bunch of simplification that's now possible.