[Issue 20246] isCallable fails for template opCall overload
https://issues.dlang.org/show_bug.cgi?id=20246 --- Comment #2 from Paul Backus --- Seems like this is an issue with the interface, then, not the implementation; the question "is S.init callable" is undecidable, so there's not much use trying to pretend we can answer it. One possible solution would be a trait like `isCallableWith!(S.init, int)`, that requires the user to specify the argument type(s). That way, we could just check with __traits(compiles) whether the call is valid or not. --
[Issue 20027] std.zip susceptible to zip malware attacks
https://issues.dlang.org/show_bug.cgi?id=20027 Berni changed: What|Removed |Added Assignee|nob...@puremagic.com|dl...@croco-puzzle.com --
[Issue 1890] DDOC removes leading space in D_CODE macro
https://issues.dlang.org/show_bug.cgi?id=1890 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #5 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #10444 "Fix Issue 1890 - DDOC removes leading space in D_CODE macro" fixing this issue: - Fix Issue 1890 - DDOC removes leading space in D_CODE macro https://github.com/dlang/dmd/pull/10444 --
[Issue 3113] final overriding
https://issues.dlang.org/show_bug.cgi?id=3113 RazvanN changed: What|Removed |Added Keywords||bootcamp CC||razvan.nitu1...@gmail.com --
[Issue 20219] Idle D programs keep consuming CPU in Gcx.scanBackground
https://issues.dlang.org/show_bug.cgi?id=20219 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Dlang Bot --- dlang/druntime pull request #2802 "Issue 20219 - Idle D programs keep consuming CPU in Gcx.scanBackground" was merged into stable: - 18ca55405eed87ce45e84e11dba14debf0346266 by Rainer Schuetze: fix issue 20219 - Idle D programs keep consuming CPU in Gcx.scanBackground background scan threads now wait indefinitely, with termination continuously triggering the condition until all threads have woken up https://github.com/dlang/druntime/pull/2802 --
[Issue 3075] Implement parameter contravariance
https://issues.dlang.org/show_bug.cgi?id=3075 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #29 from RazvanN --- (In reply to Walter Bright from comment #2) > A test case: > > void foo(void delegate(void[]) dg); > > void test() > { > void func(const(void)[] t) > { > } > > foo(); > } This test case compiles today. Is this issue fixed? --
[Issue 20248] Module constructors in executable called twice, never in loaded shared library
https://issues.dlang.org/show_bug.cgi?id=20248 John Colvin changed: What|Removed |Added Keywords||industry, wrong-code --
[Issue 3008] Members of non-lvalues (rvalues) can be assigned to.
https://issues.dlang.org/show_bug.cgi?id=3008 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #23 from RazvanN --- Andrei recently made a PR to the spec to clarify the definition of rvalues/lvalues, the result of which can be seen here [1]. It clearly states: "Definition ("Lvalue"): [...] a variable or the result of the DotIdentifier grammatical construct . (left side may be missing) when the rightmost side of the dot is a variable, field (direct or static), function name, or invocation of a function that returns by reference;" Acoording to these rules, this bug report is invalid. [1] https://dlang.org/spec/expression.html --
[Issue 20248] New: Module constructors in executable called twice, in
https://issues.dlang.org/show_bug.cgi?id=20248 Issue ID: 20248 Summary: Module constructors in executable called twice, in Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: major Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: john.loughran.col...@gmail.com % cat modcon.d import modcon2; void main() { import core.runtime : Runtime; import core.sys.posix.dlfcn; import std.stdio; writeln("HI"); assert(Runtime.loadLibrary("./libmodcon2.so")); } % cat modcon2.d __gshared int a; shared static this() { foo(); } void foo() { import core.stdc.stdio; printf("%p ", ); printf("%p\n", ); } % dmd -shared modcon2.d -of=libmodcon2.so % dmd -defaultlib=libphobos2.so modcon.d modcon2.d % ./modcon 0x7f920f3a2140 0x7f920f39f930 HI 0x7f920f3a2140 0x7f920f39f930 As you can see from the printed pointers, the module constructor from the executable is called twice - once on process start and once on loading the shared library - and the module constructor from the shared library is never called. Module constructors are normally designed to be called only once, so this causes some havok --
[Issue 20248] Module constructors in executable called twice, never in loaded shared library
https://issues.dlang.org/show_bug.cgi?id=20248 John Colvin changed: What|Removed |Added Summary|Module constructors in |Module constructors in |executable called twice, in |executable called twice, ||never in loaded shared ||library --
[Issue 3004] [patch] Better handling of ignored pragmas
https://issues.dlang.org/show_bug.cgi?id=3004 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #10443 "Fix Issue 3004 - Better handling of ignored pragmas" fixing this issue: - Fix Issue 3004 - Better handling of ignored pragmas https://github.com/dlang/dmd/pull/10443 --
[Issue 20247] New: ICE: access violation
https://issues.dlang.org/show_bug.cgi?id=20247 Issue ID: 20247 Summary: ICE: access violation Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: critical Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: basti...@veelo.net Compiling the following snippet using dmd 2.088.0 ```d int[] soov; bool a_is_kleiner_dan_b(int a, int b) { return afstand_2_tussen_twee_punten() + soov[a] ^^ 2 < afstand_2_tussen_twee_punten() + soov[b] ^^ 2; } double afstand_2_tussen_twee_punten() { return 1.0; } ``` Produces the following output: --- ERROR: This is a compiler bug. Please report it via https://issues.dlang.org/enter_bug.cgi with, preferably, a reduced, reproducible example and the information below. DustMite (https://github.com/CyberShadow/DustMite/wiki) can help with the reduction. --- DMD v2.088.0-dirty predefs DigitalMars Windows CRuntime_DigitalMars CppRuntime_DigitalMars LittleEndian D_Version2 all D_InlineAsm D_InlineAsm_X86 X86 Win32 assert D_ModuleInfo D_Exceptions D_TypeInfo D_HardFloat binaryC:\D\dmd2\windows\bin\dmd.exe version v2.088.0-dirty configC:\D\dmd2\windows\bin\sc.ini DFLAGS-IC:\D\dmd2\windows\bin\..\..\src\phobos -IC:\D\dmd2\windows\bin\..\..\src\druntime\import --- object.Error@(0): Access Violation 0x006526B7 0x0065A151 0x76ECADEE in RtlAllocateHeap 0x006F6B92 0x76ED09D2 in RtlReAllocateHeap 0x76ECB02F in RtlAllocateHeap 0x76ECADEE in RtlAllocateHeap 0x006F6B92 0x005E537B 0x005472AB 0x00703CD7 0x00703C51 0x00703AEC 0x0054723E 0x76006359 in BaseThreadInitThunk 0x76EF7B74 in RtlGetAppContainerNamedObjectPath 0x76EF7B44 in RtlGetAppContainerNamedObjectPath --
[Issue 1760] Closures - Variable unnecessarily allocated on heap
https://issues.dlang.org/show_bug.cgi?id=1760 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #6 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #10442 "Fix Issue 1760 - Closures - Variable unnecessarily allocated on heap" fixing this issue: - Fix Issue 1760 - Closures - Variable unnecessarily allocated on heap https://github.com/dlang/dmd/pull/10442 --
[Issue 3034] Template instance name wrongly mangled as LName
https://issues.dlang.org/show_bug.cgi?id=3034 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |FIXED --- Comment #3 from RazvanN --- Just tested on git master and the result is "S4test__T4TempZ1S". Closing as fixed. --
[Issue 3047] Foreach on tuple produces incorrect result (D1 only)
https://issues.dlang.org/show_bug.cgi?id=3047 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WONTFIX --- Comment #2 from RazvanN --- D1 is no longer supported, so closing as WONTFIX. --
[Issue 3073] (D1 only) expressions starting with string mixin don't parse
https://issues.dlang.org/show_bug.cgi?id=3073 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WONTFIX --- Comment #2 from RazvanN --- The issue does not appear in D2 and D1 is obsolete. Closing as WONTFIX. --
[Issue 20149] [DIP1000] Local data escapes `inout` method if not decorated with `return`
https://issues.dlang.org/show_bug.cgi?id=20149 --- Comment #18 from Dlang Bot --- @rainers updated dlang/druntime pull request #2802 "Issue 20219 - Idle D programs keep consuming CPU in Gcx.scanBackground" mentioning this issue: - Add `return` to `DSO.moduleGroup()` in support of compiler fix for issue 20149 - Merge pull request #2785 from JinShil/fix_20149 Add `return` to `DSO.moduleGroup()` in support of compiler fix for issue 20149 https://github.com/dlang/druntime/pull/2802 --
[Issue 20246] isCallable fails for template opCall overload
https://issues.dlang.org/show_bug.cgi?id=20246 Simen Kjaeraas changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #1 from Simen Kjaeraas --- It's impossible to distinguish between the above case and this: struct S { enum opCall(T) = true; } Clearly, the latter is *not* callable. To illustrate the situation perhaps more clearly: struct S { template opCall(T) { static if (is(T == int)) { void opCall(T t) {} } else { enum opCall = 14; } } } The above is perfectly valid code, but should isCallable!S return true? --
[Issue 20227] "Aborting from src/core/sync/event.d(141) Error: pthread_mutex_destroy failed." after fork()
https://issues.dlang.org/show_bug.cgi?id=20227 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Dlang Bot --- dlang/druntime pull request #2805 "fix Issue 20227 - "Error: phread_mutex_destroy failed." after fork()" was merged into stable: - e59c057c6c50f919131da5e508488be01de9cb05 by Rainer Schuetze: fix Issue 20227 - "Aborting from src/core/sync/event.d(141) Error: pthread_mutex_destroy failed." after fork() clear thread handles and events for parallel marking in child process after fork https://github.com/dlang/druntime/pull/2805 --