Fixes https://github.com/dlang/dmd/issues/21241
C Static functions were being given the same externally mangled
name as their identifier, which caused only one to be picked
when linking with linkers that supported that.
Additionally, the dmd glue code was only outputting one of these
static functions as a workaround for a different linker issue.
Solve this by giving C static functions a unique name (by using D
mangling) and adding an `isStatic()` check to the dmd glue hack.
Fixes https://github.com/dlang/dmd/issues/20499
Fixes https://github.com/dlang/dmd/issues/20963
ImportC deferred declaring "tagged" types (structs/unions/enums)
until after it saw a possible typedef so that the identifier for
a typedef declaration like:
typedef struct { int x; } Foo;
would give the struct the name Foo. In several circumstances,
this led to tagged types not being declared. Resolve this by
chasing down those circumstances.
Also, there were other circumstances where types weren't being
correctly declared which caused other issues. Lock those down.
* Fix#21024 - Optimize x^^c expressions
Reason for the *magic* constraint c<8 on inlining x^^c:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/fpu/e_powl.S;h=47f129f34d368d7c67b8e5f2462b36b0bebb7621;hb=HEAD#l136
* Fix poor assumption about expression state
* Restrict optimization to floating point expressions
* Generalize optimization to any scalar data type
* Fix segfault on x^^c where x is a single member anonymous enum
DMD segfaulted on compiling the unittests in std/algorithm/sorting.o, the
unittest that caused the segfault can be reduced to:
enum real Two = 2.0;
auto _ = Two^^3;
I'm not sure why copying the anonymous enum into a `const` variable causes
the compiler to segfault.
* Add tests to x^^c inlining optimization
* Fix missing type for e1 ^^ -1 to 1 / e1 rewrite
* Move rewrites from constant folding to expression semantic and restrict them to [-1, 2]
* Improve error message for the x^^2 rewrite.
Before:
ex.d(4): Error: can implicitly convert expression `(const const(double) __powtmp2 = x + 5.0;) , __powtmp2 * ...` of type `double` to `int`
int y = ( x + 5 ) ^^ 2;
^
and after:
ex.d(4): Error: cannot implicitly convert expression `(x + 5.0) ^^ 2L` of type `double` to `int`
int y = ( x + 5 ) ^^ 2;
^
* Update C++ frontend header to match change in `CommaExp`
* Address code review feedback
---------
Co-authored-by: Fares A. Bakhit <faresa.bakhit@gmail.com>
* bump VERSION to v2.110.0
* purge changelog
* bump VERSION to v2.111.0-beta.1
* Accept __rvalue attribute on ref functions; which will force the result to be treated as __rvalue. (#20946)
This is essential to implement `move`, `forward`, etc.
* memoryerror.d: Fix AnySupported version condition (#20983)
* Fix#20982 - wrong line number in iasmgcc (#20993)
* Move genCfunc to cxxfrontend (#20992)
* druntime: Fix compilation of rt.cover on Android (#21015)
* Expose SourceLoc to C++ interface (#20980)
* [stable] C++ header fixes for declaration, expression, and typinf (#21016)
Seen either from compilation errors or missing symbols at link time.
* C++ headers: Add 3 Declaration bitfield setters/getters required by LDC
* druntime: Add module declaration to rt.invariant, to prevent conflicts with user-provided invariant.d (#21017)
* Fix#21020 - Indexing a *cast* AA yields no lvalue anymore (#21029)
* Add C++23 to CppStdRevision enum (#21043)
* Improve UFCS/property error message (#21046)
---------
Co-authored-by: Manu Evans <turkeyman@gmail.com>
Co-authored-by: Martin Kinkelin <kinke@users.noreply.github.com>
Co-authored-by: Iain Buclaw <ibuclaw@gdcproject.org>
Co-authored-by: Martin Kinkelin <noone@nowhere.com>
Objective-C Improvements
Signed-off-by: Dennis <dkorpel@users.noreply.github.com>
Signed-off-by: Nicholas Wilson <thewilsonator@users.noreply.github.com>
Merged-on-behalf-of: Dennis <dkorpel@users.noreply.github.com>
Commit a3abf1187e fixes some cases of
lambdas having unstable symbol names between compilation units by
using `generateIdWithLoc` to generate stable lambda names, however since
LOC doesn't uniquely identify a lambda instance (because templates,
mixins, static foreach and foreach unrolling), `generateIdWithLoc`
adds a counter, so there is still some instability going on.
`generateIdWithLoc` makes the name uniq per file+loc, by adding adding a
numeric suffix. But the order of instantiations might be different
across compilation units, so with this counting scheme we are back to
unstable names, so one module might have
`t!0.__lambda_LOC` and
`t!1.__lambda_LOC_1`
while another one has
`t!1.__lambda_LOC`
This is not a critical problem, but at very least the code gets
duplicated for no reason. I also have an example where it leads to
linking error, but since it's not a small one and fails to minimize
further, I suspect it's a result of interaction with some other bug.
The thing is we don't even need uniqueness for those lambdas inside
templates/mixins: their final names will have the instantiation prefix anyway.
But we can't also just disable this uniqueness check completely: `static
foreach` as well as unrollings of the normal `foreach` with lambdas in
the loop body will have several copies of a single lambda with the same
file+loc. So here we do want to keep making them unique. Fortunately, I
don't think a `foreach` could be iterated in different order in
different compilation units, so hopefully if we limit the counting to
this case only, it won't make symbols unstable.
To implement this idea, I've added an extra `parent` argument to
`generateIdWithLoc`: it works like using `parent ~ prefix` prefix, but
without adding `parent` to the final output.
Fixes since last review:
1. Changed `fromStringz` to `toDString`
2. Added a test to showcase the problem
Commit a3abf1187e fixes some cases of
lambdas having unstable symbol names between compilation units by
using `generateIdWithLoc` to generate stable lambda names, however since
LOC doesn't uniquely identify a lambda instance (because templates,
mixins, static foreach and foreach unrolling), `generateIdWithLoc`
adds a counter, so there is still some instability going on.
`generateIdWithLoc` makes the name uniq per file+loc, by adding adding a
numeric suffix. But the order of instantiations might be different
across compilation units, so with this counting scheme we are back to
unstable names, so one module might have
`t!0.__lambda_LOC` and
`t!1.__lambda_LOC_1`
while another one has
`t!1.__lambda_LOC`
This is not a critical problem, but at very least the code gets
duplicated for no reason. I also have an example where it leads to
linking error, but since it's not a small one and fails to minimize
further, I suspect it's a result of interaction with some other bug.
The thing is we don't even need uniqueness for those lambdas inside
templates/mixins: their final names will have the instantiation prefix anyway.
But we can't also just disable this uniqueness check completely: `static
foreach` as well as unrollings of the normal `foreach` with lambdas in
the loop body will have several copies of a single lambda with the same
file+loc. So here we do want to keep making them unique. Fortunately, I
don't think a `foreach` could be iterated in different order in
different compilation units, so hopefully if we limit the counting to
this case only, it won't make symbols unstable.
To implement this idea, I've added an extra `parent` argument to
`generateIdWithLoc`: it works like using `parent ~ prefix` prefix, but
without adding `parent` to the final output.
Fixes since last review:
1. Changed `fromStringz` to `toDString`
2. Added a test to showcase the problem
