[Issue 23742] New: Functions in core.sys.windows.imagehlp should be marked @nogc nothrow
https://issues.dlang.org/show_bug.cgi?id=23742 Issue ID: 23742 Summary: Functions in core.sys.windows.imagehlp should be marked @nogc nothrow Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: j...@jackstouffer.com The functions in core.sys.windows.imagehlp are Win32 functions and do not allocate gc memory or throw exceptions. --
[Issue 23741] New: Functions in core.sys.windows.dbghelp should be marked @nogc nothrow
https://issues.dlang.org/show_bug.cgi?id=23741 Issue ID: 23741 Summary: Functions in core.sys.windows.dbghelp should be marked @nogc nothrow Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: j...@jackstouffer.com The function type aliases in core.sys.windows.dbghelp are Win32 functions and do not allocate gc memory or throw exceptions. --
[Issue 23710] [REG master] Reachable code inside an 'if (false)' block no longer gets codegen
https://issues.dlang.org/show_bug.cgi?id=23710 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @WalterBright created dlang/dmd pull request #14916 "fix Issue 23710 - [REG master] Reachable code inside an 'if (false)' …" fixing this issue: - fix Issue 23710 - [REG master] Reachable code inside an 'if (false)' block no longer gets codegen https://github.com/dlang/dmd/pull/14916 --
[Issue 17541] Function attribute deduction depends on compile invocation
https://issues.dlang.org/show_bug.cgi?id=17541 Paul Backus changed: What|Removed |Added CC||212fahrenh...@posteo.us --- Comment #14 from Paul Backus --- *** Issue 23723 has been marked as a duplicate of this issue. *** --
[Issue 23723] Attributes incorrectly inferred given the same source but compiled individually
https://issues.dlang.org/show_bug.cgi?id=23723 Paul Backus changed: What|Removed |Added Status|NEW |RESOLVED CC||snarwin+bugzi...@gmail.com Component|phobos |dmd Resolution|--- |DUPLICATE Severity|regression |normal --- Comment #6 from Paul Backus --- It's a compiler bug, originally reported in 2017, several years before the linked Phobos PR was merged. *** This issue has been marked as a duplicate of issue 17541 *** --
[Issue 23723] Attributes incorrectly inferred given the same source but compiled individually
https://issues.dlang.org/show_bug.cgi?id=23723 Iain Buclaw changed: What|Removed |Added Component|dmd |phobos Hardware|x86_64 |All OS|Linux |All --
[Issue 23723] Attributes incorrectly inferred given the same source but compiled individually
https://issues.dlang.org/show_bug.cgi?id=23723 --- Comment #5 from Iain Buclaw --- Introducing commit d5c10671317ca1f3de61acd8be760d1b77aed3a2 https://github.com/dlang/phobos/pull/8651 --
[Issue 23723] Attributes incorrectly inferred given the same source but compiled individually
https://issues.dlang.org/show_bug.cgi?id=23723 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #4 from Iain Buclaw --- Looks like this is a library regression, not compiler. --
[Issue 23740] New: Alias breaks valid array operation code using operator overloading
https://issues.dlang.org/show_bug.cgi?id=23740
Issue ID: 23740
Summary: Alias breaks valid array operation code using operator
overloading
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: huskyna...@protonmail.ch
When an alias introduces a potential array, it's picked over a valid overloaded
operator when doing an array operation, causing a compilation error.
(Note this issue reminds of issue #3064)
When the alias is removed, this code compiles and functions properly:
struct Vec{
int[2] list;
alias list this; // Causes failing compilation (c[]*b has b cast to
int[2]).
Vec opBinary(string op)(const Vec rhs) const {
Vec newA;
mixin("newA.list[0] = list[0]"~op~"rhs.list[0];");
mixin("newA.list[1] = list[1]"~op~"rhs.list[1];");
return newA;
}
}
void main(string[]) {
Vec a;
a.list = [1,1];
Vec b;
b.list = [2,2];
Vec[2] c = [a, b];
Vec[2] d;
d[] = c[] * b;
writeln(d);
}
--
[Issue 23739] Can't return by ref from opApply iteration
https://issues.dlang.org/show_bug.cgi?id=23739 kinke changed: What|Removed |Added CC||ki...@gmx.net --- Comment #2 from kinke --- The 1st testcase just requires a `foreach (ref x; s)`, which I think is consistent. The 2nd one never sets `S.x` before dereferencing it, so adding `ref` there still causes a segfault. --
