[Issue 15822] InvalidMemoryOperationError when calling GC.removeRange/Root from a finalizer
https://issues.dlang.org/show_bug.cgi?id=15822 --- Comment #12 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/d23d7efb3649cd543e8d0b10b9a32ab3325f5cd0 fix Issue 15822 - InvalidMemoryOperationError when calling GC.removeRange/Root from a finalizer https://github.com/D-Programming-Language/druntime/commit/c6ac077a8d544fab65b1973b385c6f479697fb0e Merge pull request #1519 from MartinNowak/fix15822 --
[Issue 15822] InvalidMemoryOperationError when calling GC.removeRange/Root from a finalizer
https://issues.dlang.org/show_bug.cgi?id=15822 github-bugzi...@puremagic.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --
[Issue 15826] New: Insufficient locations of deprecation message in use of std.typecons.AutoImplement
https://issues.dlang.org/show_bug.cgi?id=15826
Issue ID: 15826
Summary: Insufficient locations of deprecation message in use
of std.typecons.AutoImplement
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: diagnostic
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: j...@red.email.ne.jp
This came from 2.071's strict change.
CODE:
import std.typecons : BlackHole;
interface I {
import std.array;
}
void main(string[] args)
{
auto o = new class BlackHole!I {
};
}
RESULT:
std\traits.d(3677): Deprecation: test.I.std is not visible from module traits
Putting the import out of the interface, the error will be gone.
However, the location to be fixed is Insufficient, so it is difficult to fix.
--
[Issue 15826] Insufficient locations of deprecation message in use of std.typecons.AutoImplement
https://issues.dlang.org/show_bug.cgi?id=15826 --- Comment #1 from j...@red.email.ne.jp --- I mean that it needs the location inside of user code. --
[Issue 15688] dmd segfault with an integer call through comma expression
https://issues.dlang.org/show_bug.cgi?id=15688 Kenji Hara changed: What|Removed |Added CC||briancsch...@gmail.com --- Comment #3 from Kenji Hara --- *** Issue 15698 has been marked as a duplicate of this issue. *** --
[Issue 15698] Compiler crash with unusual function call expression
https://issues.dlang.org/show_bug.cgi?id=15698 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Kenji Hara --- *** This issue has been marked as a duplicate of issue 15688 *** --
[Issue 11435] -O optimization flag causes invalid 32 bit codegen
https://issues.dlang.org/show_bug.cgi?id=11435 --- Comment #12 from yebblies --- (In reply to yebblies from comment #11) > https://github.com/D-Programming-Language/dmd/pull/3806 I can't reproduce this on win32 or linux32/64 any more, most likely due to this: https://github.com/D-Programming-Language/dmd/pull/5111 Can anyone reproduce the failure on their system? --
[Issue 15179] Local imports cause outer imports to be excluded from overload set
https://issues.dlang.org/show_bug.cgi?id=15179
--- Comment #5 from Steven Schveighoffer ---
(In reply to Jesse Phillips from comment #4)
> Main calls bar.foobar and the assertion passes.
>
> --
> import bar;
>
> void main() {
> import foo;
> assert(7.foobar);
> }
I'm surprised this works, because I would expect foo to not overload with bar's
functions, it has priority. I'm not sure how the current lookup rules work or
the rules for the new system about to be released (with all the import rule
fixes).
But in the final version, I would expect foo's foobar overload set to be
prioritized, because it was imported locally and has priority.
But we can "fix" the demonstration by removing the foobar(string) from foo, so
it wouldn't have been used as an overload set in the first place (similar to
the original code example).
In any case, the solution here is to do a selective import in a scope, which
works as expected. Alternatively, you can import both modules at the same scope
so they are used at the same priority.
--
[Issue 15827] New: std.variant.Variant can not be initialized with some struct
https://issues.dlang.org/show_bug.cgi?id=15827
Issue ID: 15827
Summary: std.variant.Variant can not be initialized with some
struct
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: maxim...@gmail.com
Test:
import std.variant;
struct Foo
{
Variant v;
this(Foo v) {}
}
void main()
{
Variant v = Foo.init;
}
Output:
../import/std/variant.d(571): Error: variable
std.variant.VariantN!32LU.VariantN.opAssign!(Foo).opAssign.rhs has scoped
destruction, cannot build closure
The error message is referring to line [std.variant:571] but is triggered by
line [std.variant:615].
Foo must have both member of type Variant and constructor accepting Foo in
order to produce the error.
It seems to be related to Issue 5730.
[std.variant:571]:
https://github.com/D-Programming-Language/phobos/blob/708c5d8e6ddd9245f793e4b8761382672225f271/std/variant.d#L571
[std.variant:615]:
https://github.com/D-Programming-Language/phobos/blob/708c5d8e6ddd9245f793e4b8761382672225f271/std/variant.d#L615
[Issue 5730]: https://issues.dlang.org/show_bug.cgi?id=5730
--
[Issue 15799] Misleading error message against the contract followed by semicolon in interface
https://issues.dlang.org/show_bug.cgi?id=15799 --- Comment #1 from Kenji Hara --- This is a bug since the beginning of the feature implementation. https://github.com/D-Programming-Language/dmd/commit/b0c80159d1080ddb13cc2c438f139bd153c9d79a --
[Issue 15827] std.variant.Variant can not be initialized with some struct
https://issues.dlang.org/show_bug.cgi?id=15827 --- Comment #1 from Maksim Zholudev --- https://github.com/D-Programming-Language/phobos/pull/4118 --
[Issue 15799] Misleading error message against the contract followed by semicolon in interface
https://issues.dlang.org/show_bug.cgi?id=15799 Kenji Hara changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #2 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/5571 --
[Issue 14439] aa's keys, values, byKey, byValue not usable in @safe context
https://issues.dlang.org/show_bug.cgi?id=14439 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #4 from Steven Schveighoffer --- I'm unsure why these are not safe in the first place. I think we should be able to make them safe in both implementation and wrapper interface. I'd like to see at least an attempt to make them safe in the implementation (even if we need to have @trusted wrappers for a few lines). --
[Issue 15822] InvalidMemoryOperationError when calling GC.removeRange/Root from a finalizer
https://issues.dlang.org/show_bug.cgi?id=15822 --- Comment #13 from hst...@quickfur.ath.cx --- Thanks!! --
[Issue 15777] Premature expansion of overload set in tuples
https://issues.dlang.org/show_bug.cgi?id=15777 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/5572 --
[Issue 15760] Segfault when compiling when using __gshared and selective import.
https://issues.dlang.org/show_bug.cgi?id=15760 --- Comment #3 from Kenji Hara --- (In reply to Kenji Hara from comment #2) > I'll add a test case to avoid future regression. https://github.com/D-Programming-Language/dmd/pull/5573 --
[Issue 15760] Segfault when compiling when using __gshared and selective import.
https://issues.dlang.org/show_bug.cgi?id=15760 --- Comment #2 from Kenji Hara --- The compiler segfault is fortunately fixed by the PR for issue 15519. https://github.com/D-Programming-Language/dmd/pull/5333 I'll add a test case to avoid future regression. --
[Issue 15757] D main is a nested function and cannot be accessed
https://issues.dlang.org/show_bug.cgi?id=15757 Kenji Hara changed: What|Removed |Added Keywords||pull, rejects-valid Hardware|x86_64 |All OS|Windows |All Severity|enhancement |normal --- Comment #1 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/5574 --
[Issue 12318] Nested structs with only templated methods do not capture context
https://issues.dlang.org/show_bug.cgi?id=12318 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Kenji Hara --- *** This issue has been marked as a duplicate of issue 11886 *** --
[Issue 11886] "cannot access frame" error on lambda in lambda
https://issues.dlang.org/show_bug.cgi?id=11886 Kenji Hara changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #6 from Kenji Hara --- *** Issue 12318 has been marked as a duplicate of this issue. *** --
[Issue 15828] New: DMD should refuse comparing unions
https://issues.dlang.org/show_bug.cgi?id=15828
Issue ID: 15828
Summary: DMD should refuse comparing unions
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: johannesp...@gmail.com
Original GDC bug for reference:
http://bugzilla.gdcproject.org/show_bug.cgi?id=216
Consider this example:
--
union U
{
T a;
T2 b;
}
U u1, u2; assert (u1 == u2);
--
DMD currently happily compares these unions by a memcmp. This causes multiple
problems:
First of all, there are cases where this can not work: if T is a type with a
opEquals, DMD does currently not call the opEquals. In fact, it can't call the
opEquals: As the compiler can not know which union member is valid, there is no
way the compiler can call opEquals for the correct member.
If T and T2 are types of different sizes, T.sizeof > T2.sizeof, code like this
will fail:
--
U u1, u2;
u1.a = someValue;
u2.a = someOtherValue;
u1.b = 0;
u2.b = 0;
assert(u1 == u2);
--
For GDC, things are even worse. The GCC backend is sometimes 'clever' and
doesn't copy alignment holes padding when assigning structs. Because of this,
GDC does not always memcmp structs and uses a more complicated check instead.
But if these structs are members in a union, we can't know which member is
active and can't do the advanced comparison (e.g. field-by-field comparison).
I think the compiler should simply refuse to compile such code and ask the user
to implement an opEquals function. In theory for DMD it's enough to check if
any union members require non-trivial comparison, but considering the GDC
problem I'd prefer to simply refuse comparison of all unions without opEquals.
This actually affects std.json BTW: Comparison of JSONValues is actually broken
right now...
--
[Issue 15828] DMD should refuse comparing unions
https://issues.dlang.org/show_bug.cgi?id=15828 --- Comment #1 from Johannes Pfau --- Small correction: std.json has already been fixed in upstream phobos, so I can just backport that fix for GDC. --
[Issue 15823] opIndex doesn't work for const std.variant.Variant
https://issues.dlang.org/show_bug.cgi?id=15823 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/918b58ec37d97fcacbe69b7c4070a0fffed27609 Fix Issue 15823 - Allow opIndex for const Variant https://github.com/D-Programming-Language/phobos/commit/00c5518e7ed0acaa1042b60a18308c28102faead Merge pull request #4112 from MaksimZh/fix-15823 Fix Issue 15823 - allow opIndex for const std.variant.Variant --
[Issue 15828] DMD should refuse comparing unions
https://issues.dlang.org/show_bug.cgi?id=15828 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #2 from Iain Buclaw --- (In reply to Johannes Pfau from comment #1) > Small correction: std.json has already been fixed in upstream phobos, so I > can just backport that fix for GDC. Excellent, less work for us to do. :-) --
[Issue 5363] const + alias this = wrong code
https://issues.dlang.org/show_bug.cgi?id=5363 taylorh...@gmail.com changed: What|Removed |Added CC||taylorh...@gmail.com --- Comment #7 from taylorh...@gmail.com --- Still fails on DMD 2.070.2 ( 2.070.2 ) http://dpaste.dzfl.pl/1da91ec34a86 --
[Issue 13409] std.range.padLeft/Right
https://issues.dlang.org/show_bug.cgi?id=13409 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/38c243cf91357c4986f01c472128e527dcb7422a Fix Issue 13409: add padLeft and padRight https://github.com/D-Programming-Language/phobos/commit/1651c7864f97ac582a0480850904ec3ebcd0194c Merge pull request #3765 from JackStouffer/pad [Issue 13409] std.range.padLeft/Right --
[Issue 13409] std.range.padLeft/Right
https://issues.dlang.org/show_bug.cgi?id=13409 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 15829] New: hasElaborateDestructor doesn't work for classes
https://issues.dlang.org/show_bug.cgi?id=15829
Issue ID: 15829
Summary: hasElaborateDestructor doesn't work for classes
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: petar.p.ki...@gmail.com
class C2 { ~this() {} }
static assert (hasElaborateDestructor!C1); // fails
--
[Issue 15658] isFile isn't a template
https://issues.dlang.org/show_bug.cgi?id=15658 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/45d15b9f0558689cd3e7dd1e96784aca62cc438b fix issue 15658 - UFCS used in isFile conflict with DirEntry member https://github.com/D-Programming-Language/phobos/commit/9c8f1a35da6d82d133ad08ef56326061d337717e Merge pull request #4104 from BBasile/issue-15658 fix issue 15658 - UFCS used in isFile caused a conflict with a DirEntry member --
[Issue 15658] isFile isn't a template
https://issues.dlang.org/show_bug.cgi?id=15658 github-bugzi...@puremagic.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --
[Issue 15830] New: UFCS prevents to select a free function when the parameter has a member with the same name
https://issues.dlang.org/show_bug.cgi?id=15830
Issue ID: 15830
Summary: UFCS prevents to select a free function when the
parameter has a member with the same name
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: b2.t...@gmx.com
Maybe DMD could detect that if the call to a member function is invalid this is
maybe because it's a call to another function.
struct Foo
{
uint _value;
alias _value this;
void test(){}
}
void test(uint param0, string param1){}
void main()
{
Foo foo;
foo.test(""); // want to call the free function, not the member
}
--
[Issue 15760] Segfault when compiling when using __gshared and selective import.
https://issues.dlang.org/show_bug.cgi?id=15760 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ec22537b5e745a286944342f2177237bd27dbb12 fix Issue 15760 - Segfault when compiling when using __gshared and selective import https://github.com/D-Programming-Language/dmd/commit/96aebe4cce9da42c137890aba692aecf08968b33 Merge pull request #5573 from 9rnsr/fix15760 Issue 15760 - Segfault when compiling when using __gshared and selective import --
[Issue 15179] Local imports cause outer imports to be excluded from overload set
https://issues.dlang.org/show_bug.cgi?id=15179 --- Comment #6 from Jesse Phillips --- (In reply to Steven Schveighoffer from comment #5) > In any case, the solution here is to do a selective import in a scope, which > works as expected. Alternatively, you can import both modules at the same > scope so they are used at the same priority. That doesn't solve the highjacking, Walter has made a big point about D's anti-highjacking feature. > But in the final version, I would expect foo's foobar overload set to be > prioritized, because it was imported locally and has priority. I would not, this would be a huge hole in D's anti-highjacking features. I would expect local imports to be included in the lookup set just as global imports. Only would an alias create the priority, just as global imports. --
