[Issue 20488] AA.length in multiple modules causes opDispatch failure
https://issues.dlang.org/show_bug.cgi?id=20488
FeepingCreature changed:
What|Removed |Added
CC||default_357-l...@yahoo.de
--- Comment #3 from FeepingCreature ---
Further reduction:
struct Bar {
void opDispatch(string s, Args...) (Args args) {
}
void fun() {
(bool[int]).init.length;
this.f((int[int]).init.length);
}
}
Looking into it.
--
[Issue 20492] New: __traits(getOverloads) and covariant return types in interfaces
https://issues.dlang.org/show_bug.cgi?id=20492
Issue ID: 20492
Summary: __traits(getOverloads) and covariant return types in
interfaces
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: destructiona...@gmail.com
Easier to explain with code:
---
interface A {
A foo();
}
interface B : A {
B foo();
}
class C : B {
C foo() { return this; }
}
void main() {
static foreach(overload; __traits(getOverloads, B, "foo"))
pragma(msg, typeof(overload));
}
---
* * *
Up to 2.080.1: Success with output: B()
Since 2.081.2: Success with output:
-
B()
A()
-
You can see there that getOverloads is considering both interface methods to be
overloaded on each other, despite the fact that they have identical arguments
(in this case, none).
The class, C, shows that the language proper considers them to have just one
slot. But getOverloads is returning both. I contend getOverloads should only
return the most derived version. It did that prior to 2.80.1, so I'm calling
this a regression. It is also blocking the currently most promising approach
for my auto-gen java bindings.
I suspect this was introduced in this PR https://github.com/dlang/dmd/pull/7959
--
[Issue 20491] extern(C) is not inferred for lambda agruments
https://issues.dlang.org/show_bug.cgi?id=20491 --- Comment #1 from Max Samukha --- (In reply to Max Samukha from comment #0) > Same for extern(C++). extern(C) --
[Issue 20491] New: extern(C) is not inferred for lambda agruments
https://issues.dlang.org/show_bug.cgi?id=20491
Issue ID: 20491
Summary: extern(C) is not inferred for lambda agruments
Product: D
Version: D2
Hardware: All
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: maxsamu...@gmail.com
extern(C++) alias F = void function();
void foo(F f) {
}
void bar(void function() f) {
}
void main() {
F f = () {}; // ok
bar(() {}); // ok without extern(C);
foo(() {}); // fail
}
onlineapp.d(12): Error: function onlineapp.foo(extern (C++) void function() f)
is not callable using argument types (void function() pure nothrow @nogc @safe)
onlineapp.d(12):cannot pass argument __funcliteral3 of type void
function() pure nothrow @nogc @safe to parameter extern (C++) void function() f
Same for extern(C++).
--
[Issue 20391] [REG 2.089] DMD compile times increased by 40% because ENABLE_RELEASE=0 in build
https://issues.dlang.org/show_bug.cgi?id=20391 Rainer Schuetze changed: What|Removed |Added CC||c...@dawg.eu, ||r.sagita...@gmx.de --- Comment #7 from Rainer Schuetze --- dmd 2.090 is still slower than 2.088. dmd.exe is also built with debug symbols and contains strings only used by assertions, so I suspect it's just a debug build. dub.exe also contains debug symbols, but it has always been this way. Maybe a locally modified makefile during release build is also causing the dmd version to have the suffix -dirty. @Martin any idea? --
[Issue 20489] Installer deleting files after install
https://issues.dlang.org/show_bug.cgi?id=20489 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze --- I tried to reproduce this, but for me, the uninstaller is blocking the installer until it is finished. The NSIS script is using an ExecWait statement to run the uninstaller. Maybe ExecWait doesn't work for some reason. What Windows version are you running? Mine is Win 10 1903. What version are you uninstalling? --
[Issue 17065] [REG2.072] Unique does not work with private members
https://issues.dlang.org/show_bug.cgi?id=17065 --- Comment #8 from Basile-z --- Created attachment 1772 --> https://issues.dlang.org/attachment.cgi?id=1772=edit fix proposal --
[Issue 17065] [REG2.072] Unique does not work with private members
https://issues.dlang.org/show_bug.cgi?id=17065 Basile-z changed: What|Removed |Added Keywords||patch --
[Issue 20483] std.uni.byGrapheme & Grapheme.opSlice requires obscure REF parameters.
https://issues.dlang.org/show_bug.cgi?id=20483 --- Comment #2 from hst...@quickfur.ath.cx --- The problem is caused by the implementation of Grapheme.opSlice(), which returns a proxy range object that contains a pointer to the parent Grapheme. A cursory glance at the code didn't show any obvious reason why this was done this way; conceivably the proxy object returned by .opSlice could just copy the necessary data from Grapheme instead of retaining a pointer to it. This implementation choice makes it hard to work with Graphemes in range-based pipelines. If anywhere in the pipeline a Grapheme is generated on-the-fly, it will generally be returned from .front as an rvalue, and therefore even the ref trick mentioned in this bug will no longer work. I recommend to change the implementation of .opSlice so that it does not retain a pointer to the parent Grapheme. --
[Issue 20483] std.uni.byGrapheme & Grapheme.opSlice requires obscure REF parameters.
https://issues.dlang.org/show_bug.cgi?id=20483 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 7066] You can redefine .init and .stringof without error
https://issues.dlang.org/show_bug.cgi?id=7066 Basile-z changed: What|Removed |Added CC||b2.t...@gmx.com --- Comment #13 from Basile-z --- *** Issue 17465 has been marked as a duplicate of this issue. *** --
[Issue 17465] stringof is allowed as identifier
https://issues.dlang.org/show_bug.cgi?id=17465 Basile-z changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Basile-z --- *** This issue has been marked as a duplicate of issue 7066 *** --
[Issue 7066] You can redefine .init and .stringof without error
https://issues.dlang.org/show_bug.cgi?id=7066 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 20488] AA.length in multiple modules causes opDispatch failure
https://issues.dlang.org/show_bug.cgi?id=20488 moonlightsenti...@disroot.org changed: What|Removed |Added CC||moonlightsentinel@disroot.o ||rg Severity|normal |regression --- Comment #2 from moonlightsenti...@disroot.org --- Digger blames https://github.com/dlang/dmd/pull/8584 --
[Issue 20490] malloc and calloc should be @safe / @trusted
https://issues.dlang.org/show_bug.cgi?id=20490 Nathan S. changed: What|Removed |Added Summary|malloc and free should be |malloc and calloc should be |@safe / @trusted|@safe / @trusted --
[Issue 20490] malloc and free should be @safe / @trusted
https://issues.dlang.org/show_bug.cgi?id=20490 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @n8sh created dlang/druntime pull request #2901 "Fix Issue 20490 - malloc and free should be `@safe` / `@trusted`" fixing this issue: - Fix Issue 20490 - malloc and free should be `@safe` / `@trusted` There is no good reason not to annotate them correctly. https://github.com/dlang/druntime/pull/2901 --
[Issue 20490] New: malloc and free should be @safe / @trusted
https://issues.dlang.org/show_bug.cgi?id=20490 Issue ID: 20490 Summary: malloc and free should be @safe / @trusted Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: minor Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com malloc and calloc should be @trusted because by specification they cannot corrupt memory regardless of what arguments they are passed. core.stdc.stdlib.d has this comment explaining why they aren't @trusted: // We don't mark these @trusted. Given that they return a void*, one has // to do a pointer cast to do anything sensible with the result. Thus, // functions using these already have to be @trusted, allowing them to // call @system stuff anyway. That comment is longer than just writing @trusted twice. Moreover since that comment was written Phobos has adopted the style of wrapping individual statements in @trusted lambdas instead of marking entire functions as @trusted. --
[Issue 20488] AA.length in multiple modules causes opDispatch failure
https://issues.dlang.org/show_bug.cgi?id=20488
Simen Kjaeraas changed:
What|Removed |Added
CC||simen.kja...@gmail.com
Summary|Strange opDispatch error|AA.length in multiple
|with multiple module|modules causes opDispatch
|compilation and the use of |failure
|hashmaps|
--- Comment #1 from Simen Kjaeraas ---
Further reduced:
foo.d:
///
struct Foo {
bool[int] aa;
void fun() {
int i = aa.length;
}
}
///
bar.d:
///
struct Bar {
int[int] aa;
void fun() {
this.f(aa.length);
}
void opDispatch (string s, Args...) (Args args) {
}
}
///
Compile with 'dmd foo bar', and you get
bar.d(4): Error: no property f for type bar.Bar
If the two AA types are identical it compiles.
Adding 'int j = (int[int]).init.length;' to S1.fun() does make it compile, but
only if it's before the 'int i = ...' line (wat).
--
[Issue 20489] New: Installer deleting files after install
https://issues.dlang.org/show_bug.cgi?id=20489 Issue ID: 20489 Summary: Installer deleting files after install Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: installer Assignee: nob...@puremagic.com Reporter: simen.kja...@gmail.com Something seems to be wrong with the 2.090.0 Windows installer. After successfully installing, it proceeds to delete every file it has just added. Looking closely at how it happens, it seems that it might actually be caused by the uninstaller deleting itself and the directory it's in. If I wait long after the previous version has been uninstalled before clicking 'next', it doesn't happen. So, how to reproduce: 1) have a previous DMD version installed 2) start the 2.090.0 installer 3) answer yes to uninstalling the previous version 4) quickly finish installing 2.090.0 If you do this with the install folder open in an explorer window, you should see the files disappearing during the uninstall of the previous version, until the only item in the D folder is uninstall.exe. As the new install proceeds more files and folders will be added, and finally they will all be deleted again, sometimes leaving an empty folders, other times a partial installation (I've only once managed to get a partial installation). It seems that the installer is not waiting for the uninstall to finish before installing things, or conversely that the uninstaller signals completion before it's actually done. --
[Issue 20488] New: Strange opDispatch error with multiple module compilation and the use of hashmaps
https://issues.dlang.org/show_bug.cgi?id=20488 Issue ID: 20488 Summary: Strange opDispatch error with multiple module compilation and the use of hashmaps Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: andrej.mitrov...@gmail.com Created attachment 1771 --> https://issues.dlang.org/attachment.cgi?id=1771=edit test case This is the weirdest bug I have ever filed. I couldn't reduce it further, and I reduced it to this stage manually because Dustmite took way too long. It seems that whatever I touch, the bug will fail to reproduce. For example, changing a hashmap into an array in the offending line makes the bug disappear. The attachment has the source files and a simple run.sh script. Tested on MacOS Mojave & DMD v2.089.1 --
