[Issue 19747] No debug line info for code in scope(exit)
https://issues.dlang.org/show_bug.cgi?id=19747 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #9459 "fix Issue 19747 - No debug line info for code in scope(exit)" was merged into master: - 494913ded60ba275b8caae09a3a09ad478f750eb by Rainer Schuetze: fix Issue 19747 - No debug line info for code in scope(exit) remove gratuitous requirement of ascending source testpdb.d now also supports registration free use of COM interfac to msdia140.dll as used by VS2017 and VS2019 https://github.com/dlang/dmd/pull/9459 --
[Issue 19605] invalid forward reference error when getting the `.sizeof` of an opaque enum
https://issues.dlang.org/show_bug.cgi?id=19605 Basile-z changed: What|Removed |Added Keywords|pull, rejects-valid | --
[Issue 19605] invalid forward reference error when getting the `.sizeof` of an opaque enum
https://issues.dlang.org/show_bug.cgi?id=19605 --- Comment #3 from Basile-z --- This one might be invalid actually. The implementation of the fix is problematic at least. --
[Issue 19605] invalid forward reference error when getting the `.sizeof` of an opaque enum
https://issues.dlang.org/show_bug.cgi?id=19605 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @Basile-z created dlang/dmd pull request #9460 "fix issue 19605 - invalid forward reference error when getting the `sizeof` of an opaque enum" fixing this issue: - fix issue 19605 - invalid forward reference error when getting the `.sizeof` of an opaque enum https://github.com/dlang/dmd/pull/9460 --
[Issue 19605] invalid forward reference error when getting the `.sizeof` of an opaque enum
https://issues.dlang.org/show_bug.cgi?id=19605 Basile-z changed: What|Removed |Added Summary|invalid forward reference |invalid forward reference |error when getting the |error when getting the |`.sizeof` if an opaque enum |`.sizeof` of an opaque enum --
[Issue 19605] invalid forward reference error when getting the `.sizeof` if an opaque enum
https://issues.dlang.org/show_bug.cgi?id=19605 Basile-z changed: What|Removed |Added Keywords||rejects-valid CC||b2.t...@gmx.com Summary|enum X: "Error: enum X is |invalid forward reference |forward referenced when |error when getting the |looking for sizeof" |`.sizeof` if an opaque enum --
[Issue 19747] No debug line info for code in scope(exit)
https://issues.dlang.org/show_bug.cgi?id=19747 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @rainers created dlang/dmd pull request #9459 "fix Issue 19747 - No debug line info for code in scope(exit)" fixing this issue: - fix Issue 19747 - No debug line info for code in scope(exit) remove gratuitous requirement of ascending source testpdb.d now also supports registration free use of COM interfac to msdia140.dll as used by VS2017 and VS2019 https://github.com/dlang/dmd/pull/9459 --
[Issue 5725] ubyte/ushort infinite foreach loops
https://issues.dlang.org/show_bug.cgi?id=5725 Basile-z changed: What|Removed |Added Status|NEW |RESOLVED CC||b2.t...@gmx.com Resolution|--- |WORKSFORME --- Comment #5 from Basile-z --- fixed at some point: /tmp/temp_7F8FB1CE2190.d(4,5): Error: index type `ubyte` cannot cover index range 0..256 /tmp/temp_7F8FB1CE2190.d(7,5): Error: index type `ushort` cannot cover index range 0..65536 --
[Issue 19748] New: [REG][wrong codegen] Returning 4 floats + DMD + 64-bit
https://issues.dlang.org/show_bug.cgi?id=19748
Issue ID: 19748
Summary: [REG][wrong codegen] Returning 4 floats + DMD + 64-bit
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: alil...@gmail.com
Consider this file:
repro.d -
struct A
{
float[4] array = [1, 2, 3, 4];
}
A _mm_add_ss(A a, A b) pure @safe
{
a.array[0] += b.array[0];
return a;
}
void main()
{
A a;
a = _mm_add_ss(a, a);
// this assert fails, content is [1, 2, 3, 4] instead
// This is a 2.085.0 regression
assert(a.array == [2.0f, 2, 3, 4]);
}
---
Build with DMD 2.085.0 on Windows:
$ dmd repro.d -O -inline -noboundscheck -m64 -inline -release -unittest
$ repro.exe
The assert fails, but it works in DMD 2.084.1
--
[Issue 19747] New: No debug line info for code in scope(exit)
https://issues.dlang.org/show_bug.cgi?id=19747
Issue ID: 19747
Summary: No debug line info for code in scope(exit)
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Keywords: symdeb
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: r.sagita...@gmx.de
Compiling this code for COFF with "dmd -m64 -g":
module dbgi;
__gshared int recurse;
int foo(int n)
{
recurse++;
scope(exit)
{
recurse--;
if (recurse < 0)
assert(false);
}
int r = n + n;
int s = r + 2;
return r;
}
void main()
{
int x = foo(7);
}
yields missing debug line information for the code in scope(exit), e.g.
disassembly in VS looks like this:
5: int foo(int n)
7FF797F0BF80 pushrbp
7FF797F0BF81 mov rbp,rsp
7FF797F0BF84 sub rsp,18h
7FF797F0BF88 pushrbx
7FF797F0BF89 mov dword ptr [n],ecx
6: {
7: recurse++;
7FF797F0BF8C inc dword ptr [dbgi.recurse (07FF79800A4A0h)]
8: scope(exit)
9: {
10: recurse--;
11: if (recurse < 0)
12: assert(false);
13: }
14: int r = n + n;
7FF797F0BF92 mov eax,dword ptr [n]
8: scope(exit)
9: {
10: recurse--;
11: if (recurse < 0)
12: assert(false);
13: }
14: int r = n + n;
7FF797F0BF95 mov ecx,eax
7FF797F0BF97 lea edx,[rax+rcx]
7FF797F0BF9A mov dword ptr [r],edx
15: int s = r + 2;
7FF797F0BF9D lea ebx,[rdx+2]
7FF797F0BFA0 mov dword ptr [s],ebx
7FF797F0BFA3 mov eax,edx
7FF797F0BFA5 mov qword ptr [rbp-10h],rax
7FF797F0BFA9 sub rsp,8
7FF797F0BFAD calldbgi.foo+4Fh (07FF797F0BFCFh)
7FF797F0BFB2 add rsp,8
7FF797F0BFB6 mov rax,qword ptr [rbp-10h]
7FF797F0BFBA pop rbx
7FF797F0BFBB mov rsp,rbp
7FF797F0BFBE pop rbp
7FF797F0BFBF ret
7FF797F0BFC0 sub rsp,8
7FF797F0BFC4 calldbgi.foo+4Fh (07FF797F0BFCFh)
7FF797F0BFC9 add rsp,8
7FF797F0BFCD jmp dbgi.foo+76h (07FF797F0BFF6h)
7FF797F0BFCF dec dword ptr [dbgi.recurse (07FF79800A4A0h)]
7FF797F0BFD5 cmp dword ptr [dbgi.recurse (07FF79800A4A0h)],0
7FF797F0BFDC jns dbgi.foo+75h (07FF797F0BFF5h)
7FF797F0BFDE mov edx,0Ch
7FF797F0BFE3 lea rcx,[__a6_646267692e64 (07FF797FF7E20h)]
7FF797F0BFEA sub rsp,20h
7FF797F0BFEE call_d_assertp (07FF797F0643Dh)
7FF797F0BFF3 ud2
7FF797F0BFF5 ret
16: return r;
17: }
7FF797F0BFF6 pop rbx
16: return r;
17: }
7FF797F0BFF7 mov rsp,rbp
7FF797F0BFFA pop rbp
7FF797F0BFFB ret
This prevents setting breakpoints in the scope(exit)-code or stepping through
the code.
--
[Issue 19621] The specification is self-contradictory on immutability
https://issues.dlang.org/show_bug.cgi?id=19621 ZombineDev changed: What|Removed |Added CC||petar.p.ki...@gmail.com --
[Issue 19602] Under some circumstances: throwing Error subclasses unwinds without invoking dtors
https://issues.dlang.org/show_bug.cgi?id=19602 --- Comment #13 from Jacob Carlborg --- (In reply to Walter Bright from comment #11) > Unittest failures at the top level do not call the assert fail handler, they > call _d_unittestp(), which then calls the assert error handler. This means > you can supply your own _d_unittestp() replacement. Ah, I didn't know about that. Then `_d_unittestp` can be implemented to throw an exception instead of an error. --
[Issue 19602] Under some circumstances: throwing Error subclasses unwinds without invoking dtors
https://issues.dlang.org/show_bug.cgi?id=19602 --- Comment #12 from Eyal --- Walter, the question is: what benefits does the current approach have over a much safer approach of having *only* "onError" callbacks that allow the user to write some handling code in case of error before abort? 1) Even if the unwinding behavior is fixed to not unwind in case of errors, using "catch" blocks to handle errors has very surprising semantics: it runs code in broken contexts that have not run (scope(exit)s, finally's, destructors all skipped). 2) Worse still: the program easily continues after catching Errors, even if it is by accident -- in a completely corrupt state. These would remain 2 huge gotchas to know about when working with try/catch. Why keep them? --
