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`.)
clang::DeclContext::decls_begin() deserializes all the pre-compiled headers
imported into the current translation unit, which is expensive.
Workaround this by disabling the emission of PragmaCommentDecls unless we're
building for a Windows target, or LTO is enabled.
A better fix would be to serialize a separate index for PragmaCommentDecls
so that they can be deserialized without deserializing everything else.
I filed rdar://problem/74036099 to track the longer-term fix.
Fixes rdar://problem/73951264.
Currently the following code doesn't work when `callConstructor()` is called from Swift:
```cc
inline int increment(int value) {
return value + 1;
}
struct Incrementor {
int incrementee;
Incrementor(int value) : incrementee(increment(value)) {}
}
int callConstructor(int value) {
return Incrementor(value).incrementee;
}
```
The issue is that we don't generate `IR` for the `increment()` function when it's only called from a constructor or a method.
Swift is aware of the existence of `increment()` and we see it in `IR` as `declare incrementEi`, however, as we don't to emit a definition, we get the following error:
```
Incrementor::Incrementor(int): error: undefined reference to 'increment(int)'
```
This PR fixes this by visiting constructors and methods in `IRGen` and calling `HandleTopLevelDecl()` with all used declarations, which results in emitting definitions for the used declarations.
Co-authored-by: Marcel Hlopko <hlopko@google.com>
emitClangDecl interacts with clang and LLVM to achieve C interop. On the
LLVM side, CodeGenModule::EmitGlobal asserts if the decl eventually
passed to it is not a "file scoped" via VarDecl::isFileVarDecl.
LLVM currently asserts on local extern variables in C headers passed to
Swift when the definition exists outside that header. To fix this, we
need to ensure that we are only passing Decls that do not trip the
assertion but not unduly limit local extern variables when the
corresponding definition exists inside that header.
We can do that fairly simply by checking for isFileVarDecl just before
we hand-off to clang. When the definition for the local extern variable
exists inside the header, isFileVarDecl is true, and if it exists
elsewhere, it is false. This matches up with the assert expectation on
the LLVM side exactly.
This indirectly addresses #28968, since that contains the only part of
the Swift stdlib that uses a local extern variable, but any header that
is used with Swift that contains a local extern variable will cause the
compiler to assert when built with assertions enabled.
This is important, for example, for linking correctly to the C++
standard library on Windows, which uses `#pragma comment(lib, ...)` in
its headers to specify the correct library to link against.
Previously, we were only doing this after the fast-path code that
handles decls without any executable code. This meant, however, that we
were potentially processing these decls multiple times. This is
definitely inefficient; it may even be a correctness issue, depending on
what amount of checking `HandleTopLevelDecl` does to see if it has
processed a particular decl before (which I'm not sure about either
way).
Adds a test that fails without the fix.
The fix consists simply of removing a return statement; as a result, we
now always emit code for functions referenced from the function we are
currently emitting.
Previously, this was not done for externally visible functions. This
goes all the way back to when `GenClangDecl.cpp` was originally introduced here:
ee22004b84
I speculate that the reason for doing this was that in C and Objective-C, we
can assume that an externally visible function will be provided by some
`.o` file we're linking against (though I'm not sure if this is in fact
true for C99 inline functions). At any rate, this assumption is no longer true
for C++ inline functions.
Previously, we had hacks in place to eagerly emit everything in
the global ExternalDefinitions list. These can now be removed,
at least at the IRGen layer.
We need this because that global state includes tables like llvm[.compiler].used
which would otherwise be sorely missed.
This fixes an issue of the clang importer that would cause us to fail whenever
we imported a function (say it is marked as static inline) that performs an
objective-c method call and we optimize the code. The optimizer would not see
the objective-c selector global variable (which is marked private) as being
"used by unkown i.e the objc runtime" and would rightly assume it could
propagate the value of the global variable's initializer value as a constant to
loads of the global variable.
Now we call the ClangCodeGenerators translation unit finalization code which
will emit these tables and other module flags. We need to take care that we
merge those datastrutures with datastructures that we emit from swift's IRGen.
rdar://21115194
Swift SVN r29176
Per the previous commit we are no longer using this. Minor save in
simplicity and maybe a bit of compilation time as well.
In the long run IRGen probably shouldn't be pulling information from the
AST at all; the SILModule should be able to tell it what types it needs
to emit information for. But this is still an improvement for now.
No functionality change (that was the previous commit).
Swift SVN r24840
This handles things like NSSwapHostLongLongToBig and MKMapRectMake that
are static inline functions that themselves call other static inline
functions.
<rdar://problem/17227237>
Swift SVN r21080
