[Issue 19861] core.cpuid reports the wrong number of threads
https://issues.dlang.org/show_bug.cgi?id=19861 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Dlang Bot --- dlang/druntime pull request #2620 "fix Issue 19861 - core.cpuid reports the wrong number of threads" was merged into stable: - 0723a38a858e83a9c5c0d43a0400571ef2a0 by Rainer Schuetze: fix Issue 19861 - core.cpuid reports the wrong number of threads do not use i7 detection on AMD processors use cpuid 0x8000_001E to detect the number of threads per core https://github.com/dlang/druntime/pull/2620 --
[Issue 19975] object.opEquals(Object lhs, Object rhs) can skip typeid comparison when !lhs.opEquals(rhs)
https://issues.dlang.org/show_bug.cgi?id=19975 Mike Franklin changed: What|Removed |Added Status|NEW |RESOLVED CC||slavo5...@yahoo.com Resolution|--- |FIXED --- Comment #3 from Mike Franklin --- https://github.com/dlang/druntime/pull/2641 was merged. --
[Issue 15505] extern(C++) array parameter mangling gains surprise const
https://issues.dlang.org/show_bug.cgi?id=15505 --- Comment #5 from Manu --- I don't follow your examples: C++: void test(int arg[6]); void test(int arg[]); These are identical in C++, and they should mangle the same; with no size. And yes, we see that MSVC has `* const` here. This is actually uninteresting, because there's no way to make a declaration like this in D. In C++, it's just a lame way to pass an un-sized array, and would almost always just use a pointer. This is what's interesting: C++: void test(int ()[6]); void test(int (*arg)[6]); These are interesting because they have meaningful D counterparts: void test(ref int[6]); void test(int[6]*); These cases should be fixed in our mangler, they are useful functions that appear relatively often and are the proper way to pass static-arrays in C++. --
[Issue 19986] Can't assign large const T to std.Variant.VariantN
https://issues.dlang.org/show_bug.cgi?id=19986 Atila Neves changed: What|Removed |Added CC||atila.ne...@gmail.com --- Comment #2 from Atila Neves --- I'm unsure of why this is a bug. --
[Issue 20009] New: isForwardRange doesn't work with alias range this or inheritance
https://issues.dlang.org/show_bug.cgi?id=20009
Issue ID: 20009
Summary: isForwardRange doesn't work with alias range this or
inheritance
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: enhancement
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: ali.akhtarz...@gmail.com
struct FR {
bool empty = true;
void popFront() {}
auto front() { return 0; }
FR save() { return this; }
}
struct S {
FR range;
alias range this;
}
pragma(msg, isInputRange!S); // true
pragma(msg, isForwardRange!S); // false
It's because isForwardRange is defined as:
isInputRange!R && is(ReturnType!((R r) => r.save) == R);
But it should be:
isInputRange!R && is(R : ReturnType!((R r) => r.save));
The same thing will happen if you try an inherit from an interface that is a
forward range, and if the save function returns the base class it will fail.
--
[Issue 15478] cases of missed CTFE evaluation when defining arrays dimensions
https://issues.dlang.org/show_bug.cgi?id=15478 ag0aep6g changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #9 from ag0aep6g --- (In reply to Basile-z from comment #8) > https://www.youtube.com/watch?v=bLHL75H_VEM Title and content of that: "You're dereferencing a null pointer!" I realize that you're most likely just trying to insult me with that video. But if you think there would be a null dereference in the original test case, you're mistaken. `foo` is a valid instance of `Foo`. `foo.bug` is a valid call. Remember that the code works as expected when the call is written as `foo.bug()`. I'm reopening this again. If you close it again, please explain more elaborately and clearly how the original test case is invalid (preferably without external links). And please explain how it makes sense that it fails with `foo.bug` when it works with `foo.bug()`. --
[Issue 15478] cases of missed CTFE evaluation when defining arrays dimensions
https://issues.dlang.org/show_bug.cgi?id=15478 Basile-z changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Basile-z --- https://www.youtube.com/watch?v=bLHL75H_VEM --
[Issue 19399] Different Conversion Rules for Same Value and Type -- Enum
https://issues.dlang.org/show_bug.cgi?id=19399 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #7 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #10099 "Fix Issues 19399 and 10560 - Different Conversion Rules for Same Value and Type Enum" fixing this issue: - Fix Issues 19399 and 10560 - Different Conversion Rules for Same Value and Type Enum https://github.com/dlang/dmd/pull/10099 --
[Issue 10560] Enum typed as int with value equal to 0 or 1 prefer bool over int overload
https://issues.dlang.org/show_bug.cgi?id=10560 --- Comment #6 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #10099 "Fix Issues 19399 and 10560 - Different Conversion Rules for Same Value and Type Enum" fixing this issue: - Fix Issues 19399 and 10560 - Different Conversion Rules for Same Value and Type Enum https://github.com/dlang/dmd/pull/10099 --
[Issue 15478] cases of missed CTFE evaluation when defining arrays dimensions
https://issues.dlang.org/show_bug.cgi?id=15478 ag0aep6g changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from ag0aep6g --- (In reply to Basile-z from comment #5) > Open your eyes, the original test case is invalid. the function that gives > the dim is not static so the error message is correct. The original test case is valid. There's no reason why the method should have to be static. Also, please refrain from snarky remarks like "open your eyes". --
[Issue 20006] [REG 2.086.0] DIP1000: return scope ref outlives the scope of the argument
https://issues.dlang.org/show_bug.cgi?id=20006 --- Comment #1 from anonymous4 --- Doesn't look like your example escapes a reference to local variable. --
[Issue 19956] Subclassing Thread with synchronized (this) may deadlock
https://issues.dlang.org/show_bug.cgi?id=19956
--- Comment #4 from anonymous4 ---
Recommended lock pattern in .net:
import core.thread;
import core.time;
class BadThread : Thread
{
Object locker;
this()
{
locker=new Object;
super();
}
void run()
{
synchronized (locker)
{
Thread.sleep(1.seconds);
(new Thread({})).start;
}
}
}
--
[Issue 19956] Subclassing Thread with synchronized (this) may deadlock
https://issues.dlang.org/show_bug.cgi?id=19956 --- Comment #3 from anonymous4 --- Try to lock a dedicated mutex in BadThread instead of this and see if there's a deadlock. --
[Issue 19983] Add fast path using slice assignment to std.internal.cstring.tempCString
https://issues.dlang.org/show_bug.cgi?id=19983 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/phobos pull request #7079 "Issue 19983 - Add fast path using slice assignment to std.internal.cstring.tempCString" was merged into master: - 02659f65baafb2fb5d775b18b8be3746146ca22d by Nathan Sashihara: Fix Issue 19983 - Add fast path using slice assignment to std.internal.cstring.tempCString This is applicable for narrow strings when the output type matches the string's encoding type. https://github.com/dlang/phobos/pull/7079 --
