Skip to content

WIP: Upgrade frontend & libs to v2.113#5113

Draft
kinke wants to merge 494 commits into
ldc-developers:masterfrom
kinke:merge-2.113
Draft

WIP: Upgrade frontend & libs to v2.113#5113
kinke wants to merge 494 commits into
ldc-developers:masterfrom
kinke:merge-2.113

Conversation

@kinke
Copy link
Copy Markdown
Member

@kinke kinke commented Apr 7, 2026

No description provided.

Iskaban10 and others added 30 commits January 2, 2026 15:42
…dlang/dmd!22343)

Fix dlang/dmd!19733 - wrong real literals on windows

use _atoldbl() from the MS runtime instead of strtold_dm to parse decimal floating point literals
…!22347)

Convert object-like macros whose value is a bare function-like macro
invocation (without outer parentheses):

    #define FUNC(x) ((x) * 2)
    #define RESULT FUNC(5)      // Now converted to D

Previously only the parenthesized form was recognized:

    #define RESULT (FUNC(5))    // Already worked

This is restricted to bare function calls only (not expressions like
`FUNC(5) + 1`) to preserve C semantics - function call `()` has highest
precedence in C, so bare calls have identical behavior in both languages.
…g/dmd!22349)

* ImportC: Add test for function-like macro calling another macro

Tests the `if (params) break;` branch in TOK.identifier case,
ensuring function-like macros with identifier bodies are handled
by caseFunctionLike, not the new nullary template path.

* ImportC: Replace unreachable branch with assertion

When we reach TOK.identifier case, params is always false because
if params were true (macro name followed by '('), the next token
would be TOK.leftParenthesis, not TOK.identifier.
…value

Fix scoping and slice update in Array.reserve
kinke and others added 16 commits April 10, 2026 19:22
…n NRVO functions

In the presence of an NRVO variable, `__result` is newly a *ref* variable.
…case range statement (dlang/dmd!22926)

Fixes: dlang/dmd!22925
…r causes ICE (dlang/dmd!22941)

CTFE used to check after interpreting if there were any changes, but it neglected the interpretation of the basis element, keeping it around uninterpreted which trips up the compiler down the line.

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
… string literal causes segfault

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…sion

In `elcond`, when restructuring `((a,b) ? c : d)` into `(a, (b ? c : d))`,
`Ety` was copied to the new inner OPcond but `ET` was not. This left the
OPcond with TYstruct Ety but null ET, causing `elstruct` to return early
and `exp2_copytotemp` to crash with `assert(ty != TYstruct)`.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…equence (dlang/dmd!22914)

* Fix dlang/dmd!21707 - segfault with -vcg-ast and foreach on a tuple sequence

* List vcg-ast output as OUTPUT_FILES

* Add expected output file to TEST_OUTPUT

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
…ray type

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…set for struct arrays, fixing the segfault in rt_finalize2 during GC sweep (dlang/dmd!22884)
Like DMD. After a quick search, it looks like only PPC64 has a v2.
We've been predefining it for Linux only, do it for all ELF targets
now.

New test `runnable/sectiondefs.d` depends on these predefined versions
to determine ELF targets.
kinke and others added 9 commits May 4, 2026 22:32
…e subnormal

Which LDC detects and rejects at parse time:
```
Error: number `1e-308` is not representable as a `double`
```
As tested by new compilable/issue22254.d.
Firstly, Apple targets diverge and don't have a special case for ARM64
wrt. anonymous bit fields contributing to the aggregate alignment:
https://cpp.godbolt.org/z/44GcTKnvY

Secondly, some `extern(D)` sizeofs were wrong (probably typos).
If initialized with a StringExp, as newly tested by runnable/testconst.d
(dlang/dmd!21194).
Treat it like a regular NRVO variable, as alias for the hidden return
value allocated by the caller (incl. capturing it by ref in nested
contexts).

Fixes `baz12()` in runnable/rvalue1.d.
Mainly, avoid any blitting from NRVO/__result variable to the return
value (a memcpy with source = target, e.g., for `bar12()` in
runnable/rvalue1.d, with __return being a *ref* variable for the
regular NRVO variable). It didn't cause any problems AFAIK but was
ugly.

Also get rid of the potential postblit call after any remaining blits;
looks like that can't happen nowadays anymore, with the frontend
handling this via temporaries and appropriate postblit or copy ctor
calls.
Looks like those are fortunately not needed anymore, handled in the
frontend instead (as e.g. copy ctors exist too nowadays).
@kinke
Copy link
Copy Markdown
Member Author

kinke commented May 18, 2026

On Win64, the first hurdle/regression is pretty wild - the compiler quickly ends up with random garbage alignments (incl. for real - alignments over 1000 etc.). Going down that rabbit hole led to the observation that the MSVC++ POD logic is even more curious - not just any ctor makes a struct a non-POD, but apparently also any private (or non-public) data symbols (private functions don't trigger this). Which we have in the frontend for the structalign_t struct - which we treat as POD on the D side, but C++ wants a non-POD because of the private fields.

So any existing LDC miscompiles the new compiler sources on Win64. We can work around this by adding a ctor to the D structalign_t definition for now.

@kinke
Copy link
Copy Markdown
Member Author

kinke commented May 18, 2026

The next problem on Win64 is that we're hitting #3504 now when compiling Phobos' std.parallelism (not touched itself).

@kinke
Copy link
Copy Markdown
Member Author

kinke commented May 18, 2026

On macOS arm64, the single remaining std.uuid problem is dlang/phobos#10862 (comment).

For Linux AArch64, it's the usual annoying x87-centric upstream tests for std.internal.math.gammafunction that need to be adapted for quadruple precision. And probably some separate AArch64-specific thingy as well (NaN sign propagation?), as the unittests fails on musl aarch64 too, with its double-precision real.

The other Posix targets are all green.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.