The Port function names are actually camel-cased and
as such do not collide with the math macros, and undefining
the names in the header is just annoying on platforms where
you want to use the system macros in the implementation.
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.
