Upgrade frontend & libs to v2.112 #4949
Conversation
…lt to be treated as __rvalue. (dlang/dmd!20946) This is essential to implement `move`, `forward`, etc.
…o mutable fails (dlang/dmd!20984)
…ersion to mutable fails (dlang/dmd!21003)
… type mismatch (dlang/dmd!20990)
This brings the compiler's behavior in line with the language spec. Fixes dlang/dlang.org#4137
- Removed references to _d_arrayappendcTX, _d_newThrowable, and _d_arrayappendT. - Ensured test cases pass after deletion. - Left _d_arrayctor and _d_arraysetctor untouched for future semantic phase changes.
Co-authored-by: Dennis Korpel <[email protected]>
…dmd!21001) * Fix: Prevent ICE on final switch forward referencing its enum * more simpler approach * moved the enum member analysis * Move enum number analysis to sementic2 * WhiteSpace Remove * Remove Redundant Code in enumsem
* 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. (dlang/dmd!20946) This is essential to implement `move`, `forward`, etc. * memoryerror.d: Fix AnySupported version condition (dlang/dmd!20983) * Fix dlang/dmd!20982 - wrong line number in iasmgcc (dlang/dmd!20993) * Move genCfunc to cxxfrontend (dlang/dmd!20992) * druntime: Fix compilation of rt.cover on Android (dlang/dmd!21015) * Expose SourceLoc to C++ interface (dlang/dmd!20980) * [stable] C++ header fixes for declaration, expression, and typinf (dlang/dmd!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 (dlang/dmd!21017) * Fix dlang/dmd!21020 - Indexing a *cast* AA yields no lvalue anymore (dlang/dmd!21029) * Add C++23 to CppStdRevision enum (dlang/dmd!21043) * Improve UFCS/property error message (dlang/dmd!21046) --------- Co-authored-by: Manu Evans <[email protected]> Co-authored-by: Martin Kinkelin <[email protected]> Co-authored-by: Iain Buclaw <[email protected]> Co-authored-by: Martin Kinkelin <[email protected]>
…ation (dlang/dmd!21053)
…symbol (dlang/dmd!21055)
…iteral (dlang/dmd!21063)
Fixes dlang/dmd!21068. Also say base class *constructor* in supplemental message.
* Refactored memcpy calls to D slices * Added .DS_Store to .gitignore
… 128 This enables using (LLVM/gcc) intrinsics for shifts, for which such inputs are undefined behavior, as for builtin types.
…line asm on x86_64
…(dlang/dmd!21067) * Fix dlang#18262 - Resolved special enum case and other conflicts * Fix dlang#18262 - Resolved Special Enum case and failing test. * Fix dlang#18262 - Resolved special enum case and other failing tests
… as virtual even though they are not in the vtbl isVirtual not good enough to check whether a function is virtual
…order in a debugger set SFLhidden for hidden parameter reconstruct order in calcLexicalScope
…lang/dmd!21361) [stable] Fix dlang/dmd!21359 - Merge more types in `substWildTo()` Signed-off-by: Rainer Schuetze <[email protected]> Merged-on-behalf-of: Martin Kinkelin <[email protected]>
As that can cause a 'compatible' function type with resolved return type to wrongly get that deco. This is what happens with LDC for a particular test case as D v2.111 regression, causing an assertion in the frontend while generating a TypeInfo_Function for some TypeFunction, with `TypeFunction.next` being null (unknown return type). The relevant `genTypeInfo()` calls before the patch, in the format `genTypeInfo: <type> (<deco>), <type after merge2()> (<deco after merge2()>)`: ``` // const funcptr: TypeInfo_Const genTypeInfo: const(Algebraic!() function(Function) nothrow @System) (xPFNbC4util8FunctionZSQq__T9AlgebraicZQl), const(Algebraic!() function(Function) nothrow @System) (xPFNbC4util8FunctionZSQq__T9AlgebraicZQl) // mutable funcptr: TypeInfo_Pointer genTypeInfo: Algebraic!() function(Function) nothrow @System (PFNbC4util8FunctionZSQq__T9AlgebraicZQl), Algebraic!() function(Function) nothrow @System (PFNbC4util8FunctionZSQq__T9AlgebraicZQl) // function: TypeInfo_Function // NOTE the missing Algebraic return type in the decos, this is the bug genTypeInfo: nothrow @System Algebraic!()(Function) (FNbC4util8FunctionZ), nothrow @System (Function) (FNbC4util8FunctionZ) ``` With this patch: ``` genTypeInfo: const(Algebraic!() function(Function) nothrow @System) (xPFNbC4util8FunctionZSQq__T9AlgebraicZQl), const(Algebraic!() function(Function) nothrow @System) (xPFNbC4util8FunctionZSQq__T9AlgebraicZQl) genTypeInfo: Algebraic!() function(Function) nothrow @System (PFNbC4util8FunctionZSQq__T9AlgebraicZQl), Algebraic!() function(Function) nothrow @System (PFNbC4util8FunctionZSQq__T9AlgebraicZQl) genTypeInfo: nothrow @System Algebraic!()(Function) (FNbC4util8FunctionZSQq__T9AlgebraicZQl), nothrow @System Algebraic!()(Function) (FNbC4util8FunctionZSQq__T9AlgebraicZQl) ```
…ang/dmd!21398) Fix issue dlang/dmd!21397 - Refcounting with Throwable is unsound Signed-off-by: Martin Kinkelin <[email protected]> Merged-on-behalf-of: Martin Kinkelin <[email protected]>
…ompiler (dlang/dmd!21407) check for missing ident
….112 Conflicts: dmd/typesem.d runtime/druntime/src/core/int128.d tests/dmd/compilable/test3004.d
…6 archs (dlang/dmd!21432)
…folder 64, not to 64.obj (dlang/dmd!21401) (dlang/dmd!21433) this avoids concurrently creating the same file multiple times Co-authored-by: Rainer Schuetze <[email protected]>
…use optimized core.checkedint.mulu() instead
The new templated function's signature isn't suited to adapt this existing optimization - the old length is in the by-ref passed slice, not a separate parameter anymore, so we can't trivially check for a constant. I guess its effect is negligible, plus the new template provides regular inlining opportunities, so just remove it.
|
I don't know how to fix dlang/dmd#21241 elegantly in LDC - I guess we'd have to resort to IR-renaming colliding C I'm inclined to not fix this - we're a D compiler, with the ability to compile some C code too (though discouraged - use importC for importing only, as the name suggests; and if you need to compile some non-trivial C parts, use a proper C compiler and mix the D/C++ builds via reggae instead). This flexibility means you can compile multiple C modules to a single object file, unlike with C, and this causes the issue. So as noted in the upstream issue, can also be worked around by compiling to separate object files (such as with Edit: And unlike DMD, we emit a warning at least when hitting such a case of conflicting mangles in an object file. |
|
That's the single failure on Posix AFAICT. On Windows, debuginfo tests in |
dmd used to declare function parameters in the wrong order. I see no separator between parameters and locals in the debug info generated by LDC-1.40.1, so I would expect the checks for |
Interestingly, it seems to work on 32-bit Windows though. I had to double-check, thinking that the test muss somehow be skipped on Win32, but no, it seems to be run and work. We do set the DI parent scope of member function definitions to the struct/class type (in IR), we 'just' don't explicitly add any functions as members when defining the parent aggregate type in IR (which clang does). |
Fixes dmd-testsuite's runnable/structinit.c, which imports assert.h, causing LDC to validate the signature.
No description provided.