This fixes an issue where any instantiation of TypeInfo in the final
output would lead to a cryptic error with no file or line information.
This change brings ldc in line with dmd's reporting of the same error,
which at least gives file and line information to discover the problem.
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...
Whenever we need an IR function, we'd better make sure it exists. Handle
that in DtoCallee(), by invoking DtoDeclareFunction() by default,
instead of the previous DtoResolveFunction() + DtoCallee() combo.
DtoResolveFunction() usually declares the function, but somehow doesn't
for abstract and body-less functions.
Fixes#3490 by avoiding unnecessary extra key allocations for the literals cache etc.
Also gets rid of code duplication and improves IRState encapsulation.
This may negatively impact performance, as the (final, i.e.,
non-virtual) Expression::is... family is implemented in D and not
available inline in the C++ headers.
There's a functional change here: previously, the direct calls to
`TypeInfo...Declaration_codegen()` bypassed the check whether the
TypeInfo can be omitted due to the described type being speculative,
which is performed for normal `Declaration_codegen()` calls only.
The latter is used by `DtoTypeInfoOf()`.
Improve robustness for TypeInfos of speculative types by only eliding
their TypeInfo definition, not the declaration of the LL global
altogether.
`DtoTypeInfoOf()` expects the LL global to be created and otherwise
fails with an assertion or segfault (e.g., issue #2357). So now only
linker errors should result in case the TypeInfo definition is missing.
Also normalize the calls to `DtoTypeInfoOf()` and revise the following
pointer bitcasts, as the LL type of forward-declared TypeInfo globals
may be opaque.
Previously, we would always try to splat the given expression across the
whole vector. This hasn't been noticed earlier as DMD mostly generates
ArrayInitializers when initializing vectors to array literals (but
notably not when explicitly assigning VectorType.init).
GitHub: Fixes#2101.
Errors are gagged while trying to create a constant initializer for an
associative array literal. So don't die with an assertion if the cast
source is a NewExp (or something else than a supported ClassReferenceExp),
emit a gaggable error instead.
Notably, the glue layer side of the changed multiple interface
inheritance layout (DMD a54e89d) has not been implemented yet.
This corresponds to DMD commit 3f6a763c0589dd03c1c206eafd434b593702564e.
Also adds the CMake infrastructure to compile and link the D source files.
The build is partially broken:
- A few files in Phobos and druntime do not build
- MSVC build is broken because of unresolved symbols involving reals
Trying to get the alignment right by using the first non-default one
in the following order of descending priority:
VarDeclaration::alignment [variables only of course]
Type::alignment()
Type::alignsize()
This fixes `align(x) struct S { ... }`.
