[Issue 16058] `immutable delegate()` and `immutable delegate() immutable` are considered equal but treated differently
https://issues.dlang.org/show_bug.cgi?id=16058
timon.g...@gmx.ch changed:
What|Removed |Added
CC||timon.g...@gmx.ch
--- Comment #4 from timon.g...@gmx.ch ---
(In reply to Kenji Hara from comment #3)
> From the type qualifier transitivity, immutable(int* delegate()) should be
> same with immutable(int* delegate() immutable).
> ...
This does not follow from transitivity because the postfix `immutable` also
annotates the implicit context parameter of the function pointer while the
`immutable` qualifier on the delegate a priori does not.
If those two types are conflated this actually leads to type system
unsoundness:
auto foo()pure{
int x;
return ()pure{ return x++; };
}
void main(){
immutable dg=foo(); // can convert to immutable as it's a strongly pure
call
import std.stdio;
writeln(dg()," ",dg()); // 0 1, immutable context is modified
}
--
[Issue 17011] cleanup std.signals documentation
https://issues.dlang.org/show_bug.cgi?id=17011 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=16203 --
[Issue 9606] `std.signal` implementation is fundamentally incorrect
https://issues.dlang.org/show_bug.cgi?id=9606 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=16203 --
[Issue 18903] std.signals uses _dtor
https://issues.dlang.org/show_bug.cgi?id=18903 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=16203 --
[Issue 19842] std.signals Segfault when connecting with a lambda
https://issues.dlang.org/show_bug.cgi?id=19842 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=16203 --
[Issue 4150] std.signals causes memory corruption and heisenbugs
https://issues.dlang.org/show_bug.cgi?id=4150 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=16203 --
[Issue 16203] std.signals connect() error
https://issues.dlang.org/show_bug.cgi?id=16203 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=9606, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=4150, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=17011, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=18903, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=19842 --
[Issue 1578] Allow AA literals to initialize static variables
https://issues.dlang.org/show_bug.cgi?id=1578 --- Comment #7 from Ethan Watson --- (In reply to mw from comment #6) > The work-around is: > > enum int[int] sizemap= [0:0, 1:1, 2:4, 3:8, 4:8, 4:16]; That's not a workaround *at all*. That's defining a constant. My example from 2018 even illustrates exactly this, and that assigning the constant to a static variable does not work. --
[Issue 1578] Allow AA literals to initialize static variables
https://issues.dlang.org/show_bug.cgi?id=1578 mw changed: What|Removed |Added CC||min...@gmail.com --- Comment #6 from mw --- (In reply to Don from comment #2) > Reduced test case: > > static int sizemap[int]= [0:0, 1:1, 2:4, 3:8, 4:8, 4:16]; > > changed title from "const initializer rejected". The work-around is: enum int[int] sizemap= [0:0, 1:1, 2:4, 3:8, 4:8, 4:16]; BTW, this is a very old issue, if it's not intended to be fixed, can we add to the doc, and close it? --
[Issue 21808] Position format specifiers don't work for AAs
https://issues.dlang.org/show_bug.cgi?id=21808 Berni44 changed: What|Removed |Added CC||bugzi...@bernis-buecher.de Severity|enhancement |normal --- Comment #1 from Berni44 --- This is related to https://issues.dlang.org/show_bug.cgi?id=18599 but not identical. --
[Issue 8600] "writeln" one parameter garbled
https://issues.dlang.org/show_bug.cgi?id=8600 Berni44 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Berni44 --- I'm closing this, because it's unclear, what the bug is and the report is old, so it might not even be there anymore. Please feel free to reopen it, if you think, the bug still persists. --
[Issue 21823] IFTI type conversions should apply to all types.
https://issues.dlang.org/show_bug.cgi?id=21823 Bolpat changed: What|Removed |Added CC||qs.il.paperi...@gmail.com --
[Issue 21823] New: IFTI type conversions should apply to all types.
https://issues.dlang.org/show_bug.cgi?id=21823 Issue ID: 21823 Summary: IFTI type conversions should apply to all types. Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: qs.il.paperi...@gmail.com https://dlang.org/spec/template.html#ifti-conversions basically states that qualifiers are not inferred for the first layer of indirection for pointers and slices: f(T)(T a); called with a const(int[]) infers T to const(int)[] as it does for const(int*) to const(int)*. This apparently falls short for any other type. const int myConstant = returns!int; f(myConstant); // calls f!(const int)(myConstant) There is no reason to infer `const int` when calling it with a local variable that happens to be declared `const`. Worse, `f` looks to the author as `a` would be mutable on the first layer of indirection unless `T` is a non-POD aggregate type. (Note: When it `T` is a non-POD aggregate type like a class or a struct with indirections, removing the qualifier is not sound and cannot be done autmatically.) On the other hand, there is no simple way to define `f` such that calling `f` with a `const int` local results in a mutable parameter `a` when using IFTI: * One can call `f` like `f!int(myConstant)`, but honestly, who does that? We want IFTI. * One can define `f` using `Unqual!T` as the parameter type, but then IFTI fails and we want IFTI. Is there even an advantage to infer `const int` on IFTI? --
[Issue 21822] Optimizer flowlv() does not account for OPmemcmp and OPstrcmp
https://issues.dlang.org/show_bug.cgi?id=21822 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #12427 "fix Issue 21822 - Optimizer flowlv() does not account for OPmemcmp an…" was merged into master: - a7d0f6424d80e6cccba083d138eff417d8aecd5f by Walter Bright: fix Issue 21822 - Optimizer flowlv() does not account for OPmemcmp and OPstrcmp https://github.com/dlang/dmd/pull/12427 --
[Issue 21822] Optimizer flowlv() does not account for OPmemcmp and OPstrcmp
https://issues.dlang.org/show_bug.cgi?id=21822 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @WalterBright created dlang/dmd pull request #12427 "fix Issue 21822 - Optimizer flowlv() does not account for OPmemcmp an…" fixing this issue: - fix Issue 21822 - Optimizer flowlv() does not account for OPmemcmp and OPstrcmp https://github.com/dlang/dmd/pull/12427 --
[Issue 21822] Optimizer flowlv() does not account for OPmemcmp and OPstrcmp
https://issues.dlang.org/show_bug.cgi?id=21822 Walter Bright changed: What|Removed |Added Keywords||backend, wrong-code --
[Issue 21822] New: Optimizer flowlv() does not account for OPmemcmp and OPstrcmp
https://issues.dlang.org/show_bug.cgi?id=21822
Issue ID: 21822
Summary: Optimizer flowlv() does not account for OPmemcmp and
OPstrcmp
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: bugzi...@digitalmars.com
The following:
char[4] sun();
bool moon() {
auto a = sun();
auto b = sun();
return a == b; // generates OPmemcmp
}
may be incorrectly compiled when optimized because the flowlv() function in the
optimizer does not account for the OPmemcmp or OPstrcmp intermediate code
operators.
This problem was exposed by https://github.com/dlang/dmd/pull/12409
--
[Issue 21821] Optimizer assumes immutables do not change, but they can in @system code
https://issues.dlang.org/show_bug.cgi?id=21821 Mathias LANG changed: What|Removed |Added CC||pro.mathias.l...@gmail.com --- Comment #2 from Mathias LANG --- Where is this specified ? `immutable` should never change, that's the point! I've never seen, nor heard, that `immutable` could be violated in `@system`. This code in `core.lifetime` exhibits UB and should be changed to apply `immutable` after the `memcpy`, e.g. as `assummeUnique` does. --
[Issue 21169] make checkedint as a drop-in replacement of native int/long
https://issues.dlang.org/show_bug.cgi?id=21169 Issue 21169 depends on issue 21761, which changed state. Issue 21761 Summary: make std.experimental.checkedint.Checked!T.toHash callable when Checked!T is shared https://issues.dlang.org/show_bug.cgi?id=21761 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 21761] make std.experimental.checkedint.Checked!T.toHash callable when Checked!T is shared
https://issues.dlang.org/show_bug.cgi?id=21761 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #7914 "make std.experimental.checkedint.Checked!T.toHash callable when Checked!T is shared" was merged into master: - 98174a053faacdcdc8e31739a71149c616947580 by Nathan Sashihara: Fix Issue 21761 - make std.experimental.checkedint.Checked!T.toHash callable when Checked!T is shared https://github.com/dlang/phobos/pull/7914 --
[Issue 18780] Inconsistent behavior with Variant holding int converting to unsigned types
https://issues.dlang.org/show_bug.cgi?id=18780 --- Comment #3 from Dlang Bot --- @berni44 created dlang/phobos pull request #7954 "Fix Issue 18780 - Inconsistent behavior with Variant holding int converting to unsigned types" fixing this issue: - Fix Issue 18780 - Inconsistent behavior with Variant holding int converting to unsigned types https://github.com/dlang/phobos/pull/7954 --
[Issue 20320] format("%f") leeds to wrong output
https://issues.dlang.org/show_bug.cgi?id=20320
Dlang Bot changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #8 from Dlang Bot ---
dlang/phobos pull request #7951 "std.format: Replace snprintf for x87-reals"
was merged into master:
- 23e5c9e15086c87f9160a0b594132eb60b338bb2 by berni44:
Fix Issue 20320 - format("%f") leeds to wrong output
https://github.com/dlang/phobos/pull/7951
--
[Issue 20536] std.format: %a on reals is inconsistent with %a on float/double
https://issues.dlang.org/show_bug.cgi?id=20536 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #7951 "std.format: Replace snprintf for x87-reals" was merged into master: - c9121a8c8930b06fca9d8ee6963b630b1cbae59e by berni44: Fix Issue 20536 - std.format: %a on reals is inconsistent with %a on float/double https://github.com/dlang/phobos/pull/7951 --
[Issue 20371] std.format limited to 500 characters for floats
https://issues.dlang.org/show_bug.cgi?id=20371 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Dlang Bot --- dlang/phobos pull request #7951 "std.format: Replace snprintf for x87-reals" was merged into master: - c116ac8d9cea7fe602fcd978a3d7757038e77b7f by berni44: Fix Issue 20371 - std.format limited to 500 characters for floats https://github.com/dlang/phobos/pull/7951 --
[Issue 9297] Formatting of floating point values in std.format truncates reals to double
https://issues.dlang.org/show_bug.cgi?id=9297 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Dlang Bot --- dlang/phobos pull request #7951 "std.format: Replace snprintf for x87-reals" was merged into master: - 6fb98242e0f8d0b3532a9c63802453d44475070d by berni44: Fix Issue 9297 - Formatting of floating point values in std.format truncates reals to double https://github.com/dlang/phobos/pull/7951 --
[Issue 8424] Compile time conversions of double/floats to strings
https://issues.dlang.org/show_bug.cgi?id=8424 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Dlang Bot --- dlang/phobos pull request #7951 "std.format: Replace snprintf for x87-reals" was merged into master: - c75bd8756d148cf3de0b44fd71d4f667da44ef6c by berni44: Fix Issue 8424 - Compile time conversions of double/floats to strings https://github.com/dlang/phobos/pull/7951 --
[Issue 21821] Optimizer assumes immutables do not change, but they can in @system code
https://issues.dlang.org/show_bug.cgi?id=21821 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @WalterBright created dlang/dmd pull request #12424 "fix Issue 21821 - Optimizer assumes immutables do not change, but the…" fixing this issue: - fix Issue 21821 - Optimizer assumes immutables do not change, but they can in @system code https://github.com/dlang/dmd/pull/12424 --
[Issue 21821] Optimizer assumes immutables do not change, but they can in @system code
https://issues.dlang.org/show_bug.cgi?id=21821 Walter Bright changed: What|Removed |Added Summary|Optimizer assumes |Optimizer assumes |immutables don't change,|immutables do not change, |but they can in @system |but they can in @system |code|code --
[Issue 21821] Optimizer assumes immutables don't change, but they can in @system code
https://issues.dlang.org/show_bug.cgi?id=21821 Walter Bright changed: What|Removed |Added Keywords||backend, wrong-code --
[Issue 21821] New: Optimizer assumes immutables don't change, but they can in @system code
https://issues.dlang.org/show_bug.cgi?id=21821
Issue ID: 21821
Summary: Optimizer assumes immutables don't change, but they
can in @system code
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: bugzi...@digitalmars.com
Consider this code from core.lifetime:
void copyEmplacex(ref immutable(S) source, ref immutable(S) target) @system {
import core.stdc.string : memcpy;
memcpy(cast(S*) , cast(S*) , S.sizeof);
(cast() target).__xpostblit();
}
Note the last line casts away immutability, and the call to __xpostblit()
modifies the supposedly immutable `target`. The part of the optimizer that
fails this is the function Symbol_isAffected() in backend/symbol.d
The fix is to set a flag in `funcsym_p` when it is @safe, and enable the check
for immutability.
--
[Issue 20704] `-preview=rvaluerefparam` does not work with `init` as default parameter
https://issues.dlang.org/show_bug.cgi?id=20704 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #12413 "Fix issue 20704 - -preview=rvaluerefparam does not work with init as default parameter" was merged into master: - 9a2042425a1e3161012f34b1c140c3a7d41b849a by nordlow: Fix issue 20704 https://github.com/dlang/dmd/pull/12413 --
