[Issue 20126] codegen reloads parameter from register when iasm changed the backing memory
https://issues.dlang.org/show_bug.cgi?id=20126 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @WalterBright created dlang/dmd pull request #10316 "fix Issue 20126 - codegen reloads parameter from register when iasm c…" fixing this issue: - fix Issue 20126 - codegen reloads parameter from register when iasm changed the backing memory https://github.com/dlang/dmd/pull/10316 --
[Issue 20126] codegen reloads parameter from register when iasm changed the backing memory
https://issues.dlang.org/show_bug.cgi?id=20126 Walter Bright changed: What|Removed |Added Summary|bad codegen for return |codegen reloads parameter |statement in function with |from register when iasm |asm code|changed the backing memory --
[Issue 20136] New: opEquals not recognized for AA key
https://issues.dlang.org/show_bug.cgi?id=20136
Issue ID: 20136
Summary: opEquals not recognized for AA key
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: tim.dl...@t-online.de
The following code compiles with dmd 2.086.0, but not with dmd 2.086.1 or dmd
2.088.0-beta.1:
class Context
{
size_t[const(Key)] aa;
bool checkAll;
}
struct Key
{
Context context;
int i;
bool opEquals(ref const Key other) const
{
if(context.checkAll && i != other.i)
return false;
return true;
}
}
Dmd 2.086.1 prints the following error message:
Error: AA key type Key does not have bool opEquals(ref const Key) const
--
[Issue 20132] segfault on fiber.call() in release mode
https://issues.dlang.org/show_bug.cgi?id=20132 --- Comment #1 from JR --- That's supposed to be the current 2.087.1, not 2.078.1. My apologies. --
[Issue 20135] Tuple assignment incorrectly calls destructor on freshly postblitted structs
https://issues.dlang.org/show_bug.cgi?id=20135 --- Comment #1 from Adam D. Ruppe --- Specifically I'd like to thank Nick Rozinsky on IRC for being the one who provided the initial report to me. --
[Issue 20135] New: Tuple assignment incorrectly calls destructor on freshly postblitted structs
https://issues.dlang.org/show_bug.cgi?id=20135
Issue ID: 20135
Summary: Tuple assignment incorrectly calls destructor on
freshly postblitted structs
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: destructiona...@gmail.com
Tested on dmd.2.088.0-beta.1, but also present on older versions I tried, so I
don't think it is new.
Consider the following code:
--
import std.stdio;
struct Test {
string s;
this(string s) { this.s = s; }
this(this) { this.s ~= " postblitted"; }
~this() { this.s = "destroyed"; }
}
struct Wrapper {
Test s;
}
void bug(Ranges...)(Ranges _ranges) {
auto ranges = _ranges;
// notice how in the original, we can still see the "1" in there
writeln(_ranges[0]);
// but in the copy made from the tuple assignment above, the destructor
// has apparently been run on the new object, starts with "destroyed"
writeln(ranges[0]);
assert(ranges[0].s.s[0 .. "destroyed".length] != "destroyed"); // fails
// same thing happens to ranges[1] btw
}
void main()
{
Wrapper a = Wrapper(Test("1"));
Wrapper b = Wrapper(Test("2"));
bug(a, b);
}
--
The `ranges = _ranges` does everything right - copies the bits, calls the
postblit then immediately calls the destructor on the freshly postblitted
object, leaving s == "destroyed". (then the writeln adds a bunch of other
postblits to it, but once it is destroyed, the relevant data is lost and we are
in bug city.)
This is reduced from a case an IRC user brought up trying to lockstep over some
phobos Files.
--
