[Issue 16081] New: CTFE mistakes for arr in cast
https://issues.dlang.org/show_bug.cgi?id=16081 Issue ID: 16081 Summary: CTFE mistakes for arr in cast Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: ag0ae...@gmail.com Encountered by Era Scarecrow in D.learn: http://forum.dlang.org/post/mzzpcdzuovajqygue...@forum.dlang.org size_t f() { size_t[] arr = [13]; return *(cast(size_t*) ); } void main() { import std.stdio; enum ct = f(); auto rt = f(); writeln(ct, " ", rt); } Prints: "13 1". The expected value is 1 for both. A "not supported" error during CTFE would also be acceptable, as happens when is assigned to a variable first. Looks like CTFE mistakes for arr here. --
[Issue 16080] Internal error: backend\cgobj.c 3406 when building static library
https://issues.dlang.org/show_bug.cgi?id=16080 Sönke Ludwigchanged: What|Removed |Added Severity|major |regression --- Comment #1 from Sönke Ludwig --- Introduced in 2.071.0, still happens in 2.071.1-b1 --
[Issue 16080] Internal error: backend\cgobj.c 3406 when building static library
https://issues.dlang.org/show_bug.cgi?id=16080 Sönke Ludwigchanged: What|Removed |Added Keywords||ice, ice-on-valid-code --
[Issue 16080] New: Internal error: backend\cgobj.c 3406 when building static library
https://issues.dlang.org/show_bug.cgi?id=16080 Issue ID: 16080 Summary: Internal error: backend\cgobj.c 3406 when building static library Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: slud...@outerproduct.org Taking the following three modules: a.d: --- struct A() { static immutable A a; } --- b1.d --- import a; --- b2.d --- import a; void test2() { A!() v = A!().a; } --- Running "dmd -lib b1.d b2.d" results in: Internal error: backend\cgobj.c 3406 Changing the order or taking away either b1.d or b2.d from the command line will make the build succeed. --
[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored
https://issues.dlang.org/show_bug.cgi?id=15925 Martin Nowakchanged: What|Removed |Added CC||c...@dawg.eu --- Comment #8 from Martin Nowak --- Weird, need to work on this. With 2.071.0 -transition=import works as expected (but -transition=checkimports doesn't report an error). With the latest nightly dmd-2016-05-26 it will accept the code w/o -transition=import b/c we haven't yet merged back the revert. With the latest stable 64f3fdb27 it will fail even with -transition=import. --
[Issue 15966] [REG 2.071] {public,protected} imports in base class ignored on symbol lookup
https://issues.dlang.org/show_bug.cgi?id=15966 --- Comment #13 from Martin Nowak--- Works as expected with -transition=import/checkimports and that behavior is already covered by test cases. --
[Issue 16065] Provide digitally signed binaries for Windows
https://issues.dlang.org/show_bug.cgi?id=16065 b2.t...@gmx.com changed: What|Removed |Added CC||b2.t...@gmx.com --- Comment #4 from b2.t...@gmx.com --- "-4" for the windows certificate because - It is not free. It's a commercial system, e.g there are companies whose buisness it to sell them. - Companies who deliver them for free do it only for FOSS. but DMD is not fully FOSS. - This system usually just reassures people who know nothing to software but since DMD are dedicated to programmers this is not useful at all. - This system means nothing unless the software checks itself for the certificate at run-time (e.g windows only checks on execution if the UAC is toggled on). Windows certificates are just a trick invented in the early 2010's to steal the money of the developers. The impact on the secutity is very low since this system would have been useful ten years before (early 2000's, XP, the freeware galore, ...) when Windows was still the main platform used as malware vector. I would advice you not to lose time to obtain that DMD, the tools and the installer, get signed. ;) --
[Issue 16065] Provide digitally signed binaries for Windows
https://issues.dlang.org/show_bug.cgi?id=16065 --- Comment #3 from Sobirari Muhomori--- A more reliable mechanism would be a PGP signature. If you check against only one key, it will be equivalent to key pinning. Oh, and the ultimate security is to build everything from source. --
[Issue 16079] New: memoize should cache objects too
https://issues.dlang.org/show_bug.cgi?id=16079 Issue ID: 16079 Summary: memoize should cache objects too Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: minor Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: greensunn...@gmail.com I don't see any reason why memoize should execute this code twice. int executed = 0; T median(T)(T[] nums) { import std.algorithm: sort; executed++; nums.sort(); if (nums.length % 2) return nums[$ / 2]; else return (nums[$ / 2 - 1] + nums[$ / 2]) / 2; } alias fastMedian = memoize!(median!int); assert(fastMedian([7, 5, 3]) == 5); assert(fastMedian([7, 5, 3]) == 5); assert(executed == 1); // ERROR, 2 --
[Issue 16062] Add 'clear' method to OutBuffer (std.outbuffer)
https://issues.dlang.org/show_bug.cgi?id=16062 greensunn...@gmail.com changed: What|Removed |Added CC||greensunn...@gmail.com --- Comment #1 from greensunn...@gmail.com --- I absolutely agree that there should be a "standard D way" as for other range types See also this discussion on Github: https://github.com/dlang/phobos/pull/3362 --
[Issue 16063] DLL projects seem to ignore DllMain, won't link
https://issues.dlang.org/show_bug.cgi?id=16063 --- Comment #3 from Manu--- Ah, I don't think I've ever used optlink since your 32bit COFF work was merged ;) --
[Issue 9149] Disallow converting delegates to const
https://issues.dlang.org/show_bug.cgi?id=9149 --- Comment #15 from Sobirari Muhomori--- If we have syntax to declare delegates with function attributes and disambiguate context attributes, why not implement contravariance check? It's likely to be big and complex, but it's pure, doesn't change the compiler state, doesn't even allocate memory, only takes two const types and returns bool - unlikely to cause serious side effects. --
[Issue 16078] New: %e (scientific notation) should be supported for all integer-like types
https://issues.dlang.org/show_bug.cgi?id=16078 Issue ID: 16078 Summary: %e (scientific notation) should be supported for all integer-like types Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: greensunn...@gmail.com I expected the following to work: ``` import std.bigint; import std.stdio; void main() { writefln("%e", BigInt(100_000)); } ``` It turns out that "%e" is only supported for floating point types and even doesn't work for built-in int/long. --
[Issue 16077] [CodeView] no language information in MS-COFF debug information
https://issues.dlang.org/show_bug.cgi?id=16077 Rainer Schuetzechanged: What|Removed |Added Keywords||pull, symdeb --- Comment #1 from Rainer Schuetze --- https://github.com/dlang/dmd/pull/5808 --
[Issue 16077] New: [CodeView] no language information in MS-COFF debug information
https://issues.dlang.org/show_bug.cgi?id=16077 Issue ID: 16077 Summary: [CodeView] no language information in MS-COFF debug information Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: r.sagita...@gmx.de The codeview debug information generated by dmd for MS-COFF does not contain any language information which could be used by a debugger to select the expression evaluator. This can be implemeted by adding a S_COMPILE record. The OMF debug information contains this record, but only pretends to be C/C++. --