[Issue 19861] core.cpuid reports the wrong number of threads

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19861 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #8 from Dlang Bot --- @rainers

[Issue 19829] __traits(isSame) returns true for some non-local delegate lambdas even when they are different

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19829 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Issue 19916] union member access should be un-@safe

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19916 --- Comment #6 from Manu --- Glad you agree. I think it's overwhelmingly simple; if the compiler can't confirm that the memory it's accessing is valid, then it's not @safe, and if that's not the definition of @safe, then we need to fix the definitio

[Issue 19920] __trait(parent, ...) broken with extern(C++,"ns") nested in scopes

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19920 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @Geod24

[Issue 19920] New: __trait(parent, ...) broken with extern(C++, "ns") nested in scopes

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19920 Issue ID: 19920 Summary: __trait(parent, ...) broken with extern(C++,"ns") nested in scopes Product: D Version: D2 Hardware: All OS: All Status: NEW

[Issue 19916] union member access should be un-@safe

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19916 --- Comment #5 from Simen Kjaeraas --- (In reply to Manu from comment #4) > union U > { > int x = 10; > float f = void; > NotAPointer np = void; > } > U u; > > float r = 10.0 + u.f; // <- f is uninitialised, r is junk This is not a memory saf

[Issue 19912] [module] No implicit import of object module when an object declaration exists.

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19912 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from

[Issue 19917] unions should require that all members are `= void` initialised

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19917 --- Comment #6 from Manu --- Either way. I like the `= void` personally. It's explicit, and there's no magic rules to implement in the compiler. It's also not always convenient to express a default construction. --

[Issue 19917] unions should require that all members are `= void` initialised

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19917 --- Comment #5 from ki...@gmx.net --- Nah, I think LDC's way is fine, but it could be improved by *requiring* (exactly) one field to be explicitly initialized - clear as day and not much more syntax overhead: union U { int i; float f = 1.0f; re

[Issue 19917] unions should require that all members are `= void` initialised

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19917 --- Comment #4 from Manu --- Wow. Seriously, the only sensible thing to do is issue a compile error if more than one item doesn't have `= void`. That would be very sane. --

[Issue 19912] [module] No implicit import of object module when an object declaration exists.

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19912 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ibuclaw

[Issue 19917] unions should require that all members are `= void` initialised

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19917 ki...@gmx.net changed: What|Removed |Added CC||ki...@gmx.net --- Comment #3 from ki...@gmx.n

[Issue 19916] union member access should be un-@safe

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19916 --- Comment #4 from Manu --- union U { int x = 10; float f = void; NotAPointer np = void; } U u; float r = 10.0 + u.f; // <- f is uninitialised, r is junk np.callMethod(); // <- np is not a pointer, but still uninitialised, certain crash etc

[Issue 19919] New: Incorrect initialization of union when first member isn't marked = void

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19919 Issue ID: 19919 Summary: Incorrect initialization of union when first member isn't marked = void Product: D Version: D2 Hardware: x86 OS: Windows Stat

[Issue 19916] union member access should be un-@safe

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19916 Simen Kjaeraas changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #3 from

[Issue 19893] extern(C++, "ns") should count as module scope for version declarations

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19893 --- Comment #3 from Dlang Bot --- @Geod24 created dlang/dmd pull request #9912 "Fix issue 19893 - extern(C++ 'ns') should count as module scope" fixing this issue: - Fix issue 19893 - extern(C++ 'ns') should count as module scope The bug was fixe

[Issue 19918] New: UFCS doesn't work in typeid expressions for functions with alias template parameter

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19918 Issue ID: 19918 Summary: UFCS doesn't work in typeid expressions for functions with alias template parameter Product: D Version: D2 Hardware: x86_64 OS: Linux

[Issue 13727] std.stdio.File not thread-safe

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13727 --- Comment #21 from Dlang Bot --- dlang/dmd pull request #9911 "Workaround issue 13727 only for DigitalMars CRuntime" was merged into master: - 97c4d5e0b2719a29a1ce1c617d77fac3d9f86c73 by Jonathan Marler: Workaround issue 13727 only for DigitalMa

[Issue 19917] unions should require that all members are `= void` initialised

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19917 --- Comment #2 from Manu --- Okay... well take this as the enhancement request that it is ;) That existing rule you describe is unintuitive and terrible. Users should specify `= void` on every member except one of their choosing. You can't possibly g

[Issue 19916] union member access should be un-@safe

2019-05-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19916 --- Comment #2 from Manu --- I have seen such a complaint appear occasionally. I don't know what motivates it, but the truth of the matter is, literally any access to any member of a union is unsafe. --