[Issue 22076] hashOf(S) can segfault if S.toHash is forwarded via 'alias this' to a receiver which may be null
https://issues.dlang.org/show_bug.cgi?id=22076 --- Comment #3 from Dlang Bot --- dlang/druntime pull request #3515 "merge stable" was merged into master: - ed76256b7dd63748ba135467e9d8be5722b579cc by Nathan Sashihara: Fix 22076 - hashOf(S) can segfault if S.toHash is forwarded via 'alias this' to a receiver which may be null - 186e58071e35ac1866f371b44b50cf560ef06f9b by Nathan Sashihara: Fix 22076 - hashOf(S) can segfault if S.toHash is forwarded via 'alias this' to a receiver which may be null https://github.com/dlang/druntime/pull/3515 --
[Issue 21488] Bundled 32-bit dlang tools (ddemangle, dustmite, rdmd) segfault on startup
https://issues.dlang.org/show_bug.cgi?id=21488 --- Comment #10 from Dlang Bot --- dlang/druntime pull request #3515 "merge stable" was merged into master: - 6b0de2de32c4746b95f08457d451e023173af985 by Iain Buclaw: Issue 21488 - Always compile druntime library with -fPIC on POSIX targets - 56017e1315adacc4c0e1d9472f390fb788126be4 by Iain Buclaw: Issue 21488 - Always compile druntime library with -fPIC on POSIX targets https://github.com/dlang/druntime/pull/3515 --
[Issue 22081] DWARF v5 support is utterly broken - 'illegal instruction' when throwing exceptions
https://issues.dlang.org/show_bug.cgi?id=22081 --- Comment #3 from Dlang Bot --- dlang/druntime pull request #3515 "merge stable" was merged into master: - 414316556aa95fa5b3b03a558479ecd4ccacb86e by Martin Kinkelin: Fix Issue 22081 - Utterly broken DWARF v5 support This has actually been tested to work with LDC, fixing the `assert(0)` and **numerous** terrible issues of #3189 after looking at the DWARF v5 spec (section 6.2.4). LLVM apparently puts all directory/file name strings into the new .debug_line_str section (DW_FORM_line_strp form code, one of various encoding options); reading the strings from there would require mmapping that section too, not just the .debug_line one. So at least with LLVM, *all* source file paths (of according DWARF v5 line-number programs) in the exception backtrace string currently show up as `/`. - 56bfaaf03c9ff8ea3a1c9bcf41259c941cccef26 by Martin Kinkelin: Fix Issue 22081 - Utterly broken DWARF v5 support This has actually been tested to work with LDC, fixing the `assert(0)` and **numerous** terrible issues of #3189 after looking at the DWARF v5 spec (section 6.2.4). LLVM apparently puts all directory/file name strings into the new .debug_line_str section (DW_FORM_line_strp form code, one of various encoding options); reading the strings from there would require mmapping that section too, not just the .debug_line one. So at least with LLVM, *all* source file paths (of according DWARF v5 line-number programs) in the exception backtrace string currently show up as `/`. https://github.com/dlang/druntime/pull/3515 --
[Issue 21996] -checkaction=context triggers InvalidMemoryOperationError in finalizer
https://issues.dlang.org/show_bug.cgi?id=21996 --- Comment #3 from Dlang Bot --- dlang/druntime pull request #3515 "merge stable" was merged into master: - 6563a53ec0b064ea6729d4db36bbfef917c850ce by MoonlightSentinel: Fix 21996 - Skip message formatting for checkaction=context in finalizer The message formatting isn't `@nogc` yet and hence caused an `InvalidMemoryOperationError` when called from a finalizer. - 04f2d6df36eb31b7e1fe201deb33b4128e5041cb by MoonlightSentinel: Fix 21996 - Skip message formatting for checkaction=context in finalizer The message formatting isn't `@nogc` yet and hence caused an `InvalidMemoryOperationError` when called from a finalizer. https://github.com/dlang/druntime/pull/3515 --
[Issue 22024] hashOf does not work on enum types whose base type is a SIMD vector
https://issues.dlang.org/show_bug.cgi?id=22024 --- Comment #3 from Dlang Bot --- dlang/druntime pull request #3515 "merge stable" was merged into master: - 4aa8c47d8fee3f2389dcb4408412a307d15b0393 by Nathan Sashihara: Fix Issue 22024 - hashOf does not work on enum types whose base type is a SIMD vector Also incidentally do not pass vector by ref to toHash - 324dca6924266be7415c50744d8a4dc74d43d407 by Nathan Sashihara: Fix Issue 22024 - hashOf does not work on enum types whose base type is a SIMD vector Also incidentally do not pass vector by ref to toHash https://github.com/dlang/druntime/pull/3515 --
[Issue 18554] `tupleof` ignoring `private` shouldn't be accepted in @safe code
https://issues.dlang.org/show_bug.cgi?id=18554 ag0aep6g changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=22137 --
[Issue 22137] -preview=dip1000 enables visibility checks for tupleof
https://issues.dlang.org/show_bug.cgi?id=22137 ag0aep6g changed: What|Removed |Added CC||ag0ae...@gmail.com See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=18554 --
[Issue 22141] New: Property .capacity is not listed in the array properties section
https://issues.dlang.org/show_bug.cgi?id=22141 Issue ID: 22141 Summary: Property .capacity is not listed in the array properties section Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: paultjeadriaa...@gmail.com Under 12.13 - 2 (Dynamic Array Properties ) the .capacity property is not listed, even though it is mentioned in 12.13.1 - 5 (Setting Dynamic Array Length) See: https://dlang.org/spec/arrays.html#array-length --
