The check was never fully implemented. We need to look into
this again, as currently we fail with a fairly unintellegible
LLVM ICE (added as GitHub #).
'protection' and 'parent' are used in ScopeDSymbol::search
detected by Valgrind). The assignment in semantic0 is enough to
fix the bug, but I also added an initialization to the constructor.
This is a backport of DMD commit 4dfaf02d4d by Don Clugston.
For a foreach (int i, dchar c; str) loop the compiler generates a
delegate with a different type signature then the runtime uses.
The runtime declares the parameters as void* and passes a pointer
to a size_t variable for the index. The code generated by the
compiler expects a ref int. This works on a little endian architecture,
but on a big endian architecture the index is always 0.
This fix changes the parameter type of the passed index to size_t
and generates a cast to the type specified by the user.
LDC_never_inline is a complementary intrinsic to LDC_allow_inline.
It tells the LLVM optimizer to never inline a function. This can be
useful if inlining creates incorrect code.
A possible application is core.thread.getStackTop().
I hope I have untangled the checks for "native" Windows (Triple::Win32)
vs. Windows/MinGW/Cygwin (Triple::isOSWindows) correctly.
MinGW needs some default libraries as well, has to be fixed later.
In many parts the DMD frontend assumes a little endian CPU. In some
parts there are checks for endianess but they are incomplete and the
used definition is wrong. (Test for endianess will be removed in dmd
2.062.)
In this commit I add the required #if's and also add a CMake test for
endianess because there is no single compiler definition to check for.
Having two functions is not pretty, but shorter than messing
around with a custom context object, and much, MUCH better than
requiring a lot of changes to the rest of the code base.
This reverts commit c4adbedcc, which would have fixed the
problem at its roots, but caused strange template function
attribute inference failures in D-YAML, presumably due to
the different order of semantic3 execution on the templates.
Previously, it could happen that regular symbols referenced
only as part of a template instance (e.g. a lambda passed as
an alias parameter) were not even emitted in the wrong module,
but not at all because mustDefineSymbol would return false to
them when being analyzed during codegen of the wrong module.
This issue might affect incremental compilation with DMD as
well, and the fix should be discussed with the upstream devs.
GitHub: Fixes#249.
