To hide a symbol in the sense of making it DSO-local. An `export`
visibility is stronger and overrides the UDA.
On non-Windows, also newly hide symbols (without `export`) with
linkonce_odr etc. linkage.
Functions can and apparently are magically stubbed (something like
`void myFunc() { (*__imp_myFunc)(); }`), but it seems we cannot avoid
dllimport for global variables exported from other DLLs/executables.
In order to try to make druntime etc. work as DLL without explicitly
exporting all required globals, `-fvisibility=public` now also assumes
all `extern(D)` globals *not* defined in some root module are exported
from some binary and dllimports them accordingly.
So e.g. compiling Phobos with `-fvisibility=public` means
* Phobos exports all defined symbols,
* Phobos dllimports extern(D) druntime symbols, and
* extern(C) globals, e.g., from the C runtime, remain external and are
linked regularly.
To pave the way for simple DLL generation (end goal:
druntime-ldc-shared.dll).
The dllexport storage class for functions definitions is enough; the
automatically generated import .lib seems to resolve the regular symbol
name to the actual symbol (__imp_*), so dllimport for declarations seems
superfluous.
For global variables, things are apparently different unfortunately.
As they are emitted into each referencing object file anyway.
Handling the globals resolves issue #3648.
I think this also solves issue #2968 - in the presumably rare event
that you absolutely don't want to emit a function into its owning
CU and only into each referencing CU, an enum-lambda can be used as
shown in the testcase.
With `pragma(inline, true)`, it'll most likely be actually inlined
and not make it to the object files.
As *the* way to access the IrType associated with a Type via its `ctype`
field. Most importantly, it makes sure all access is redirected to the
*unqualified* type's `ctype`, which allows to get rid of the 'multiple
types' workaround for aggregates in DtoType(). Those were e.g. hit for
`shared struct SpinLock`, where the struct's type includes the `shared`
modifier...
Reducing some ugliness found while investigating
https://issues.dlang.org/show_bug.cgi?id=19762.
A struct or class can apparently have 'semantic errors', in which case
the associated type is Terror. In DtoType(), we've been associating
Terror with the IrType (via `ctype`) for the first such aggregate, so
the LL type was *some* struct and got reused for other erroneous
aggregates with Terror type.
Use an opaque '_error_' LL struct in these cases now, and don't
associate Terror with any IrType anymore.
The semantics were almost identical, except for DtoIsTemplateInstance()
checking the specified Dsymbol and its parents, while isInstantiated()
starts from its parent and ignores the symbol itself.
After a quick glance, we seem to have fed it with {Aggregate,Func,Var}
Declarations only, so should be fine with the default front-end variant.
I.e., *define* templated symbols in each referencing compilation unit
when using discardable linkonce_odr linkage, analogous to C++.
This makes each compilation unit self-sufficient wrt. templated symbols,
which also means increased opportunity for inlining and less need for
LTO. There should be no more undefined symbol issues caused by buggy
template culling.
The biggest advantage is that the optimizer can discard unused
linkonce_odr symbols early instead of optimizing and forwarding to the
assembler. So this is especially useful with -O to decrease compilation
times and can at least in some scenarios greatly outweigh the
(potentially very much) higher number of symbols defined by the glue
layer.
Libraries compiled with -linkonce-templates can generally not be linked
against dependent code compiled without -linkonce-templates; the other
way around works.
Fixes#3490 by avoiding unnecessary extra key allocations for the literals cache etc.
Also gets rid of code duplication and improves IRState encapsulation.
This is exactly what happened for the 4 problematic delegate literals
for the Phobos unittests - DtoDefineFunction(fd) could result in that
definition ending up as available_externally - all done as part of
DtoResolveFunction(), which declared it, and DtoDeclareFunction()
defined it as available_externally, and the outer DtoDefineFunction()
returned early in that case without fixing up the linkage.
Emulation for @weak global variables is still left out but should be
analogous.
The test adaptations are mostly a revert of 3893840f. The testcase has
shown that @weak hasn't worked properly for ELF (linker apparently
prefers the version in the 1st object file, independent of whether it's
weak or not), because the functions are emitted in COMDATs.
clang emits COMDATs for templates and inline functions only, not for
regular functions.
Not all type declarations yet (e.g., some TypeInfo subtypes are still
accessed directly), but those already wrapped as LazyType in the
gen/runtime.cpp module (with check and proper error msg in case object.d
doesn't contain a required declaration).
The dtors can be checked at compile-time; insert a runtime check for the
monitor before finalizing the stack-allocated class object via druntime
call.
See issue #2515.
