The D types of the variable and the right-hand-side of the init AssignExp
must match; this fixes issue #1548.
Don't restrict it to memory-only types anymore though; the sret-check
performed by DtoIsReturnInArg() should suffice and makes more sense to me.
* Introduce a DRValue base class to be able to discriminate between
DLValues and DRValues (e.g., function parameters).
* Let DValue::getRVal() return each DValue's value as DRValue.
This allows to convert a DLValue to a DRValue, a snapshot of the
lvalue's current state, while retaining the D type, something we've
previously lost when returning the low-level rvalue directly.
* Let the DtoR/LVal() helpers be the only way to convert a DValue to a
low-level value.
All DValues are now required to have a (main) LL value, which allows
to conveniently refactor the DValue hierarchy.
DSliceValue now represents a LL struct instead of separate values for
length and pointer.
Use the existing public field directly instead.
It's shorter and different than LLValue's getType() (making it easier
to discriminate DValues and LLValues for experienced LDC devs imho).
Windows x64 ABI: remove unnecessary \01 from mangled symbol name.
This removes the 0x1 byte from `.mangleof` accessible from user code.
Resolves issue #1519
Also let mangleForLLVM take a std::string, to enable C++11's moves.
Allow ABIRewrites to return the D parameter's LL value directly.
Most rewrites store to memory anyway, so let the D parameter point
directly to that memory instead of a dedicated alloca bitcopy.
When certain attributes are applied to the calling function, like "unsafe-fp-math", the inlined inlineIR function has to have the same attributes otherwise the calling function attribute will be reset to the safe merge of the two: "false". Because the same inlineIR function can be called in different functions using an alias definition, a new function (with possibly different attributes) has to be instantiated upon every call.
Related GH issue #1438
The relationship between them is at best tenuous; DVarValue should
probably be renamed to DLValue and is used right now to describe
a general lvalue, of which variables are just one example.
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
This now uses actual struct literals for attributes that can be generated
by arbitrary CTFE expressions. This should allow for quite a bit of
flexibility when targeting multiple compilers.
This is apparently assumed by a std.conv unittest.
Using DtoAlignment() here instead of checking for an explicit
vd->alignment != STRUCTALIGN_DEFAULT is not only nice for consistency,
but also leads to a `struct S { align(16) int a; }` global being correctly
aligned on a 16-bytes boundary. The struct itself has no explicit
alignment, but alignsize() is 16; so the upstream code doesn't set any
explicit alignment for the global.
