Bug 15045 – [Reg 2.069-devel] hasElaborateCopyConstructor is true for struct with opDispatch

Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2015-09-11T23:07:00Z
Last change time
2015-09-16T00:24:28Z
Keywords
pull
Assigned to
nobody
Creator
code

Comments

Comment #0 by code — 2015-09-11T23:07:00Z
cat > bug.d << CODE import std.traits; struct S { void opDispatch(string func, Args...)(Args args) { } } static assert(!hasElaborateCopyConstructor!S); CODE ---- Introduced by https://github.com/D-Programming-Language/phobos/pull/3497. I'd suggest to fix __traits(hasMember) to not instantiate opDispatch in which case issue 14605 needs to be refixed.
Comment #1 by k.hara.pg — 2015-09-14T05:01:30Z
(In reply to Martin Nowak from comment #0) > I'd suggest to fix __traits(hasMember) to not instantiate opDispatch in > which case issue 14605 needs to be refixed. Today, hasMember, getMember, getOverloads, getVirtualMethods, and getVirtualFunctions have consistent result. If we fix the built-in __traits(hasMember), we should also fix other related traits.
Comment #2 by k.hara.pg — 2015-09-14T05:20:12Z
IMHO, it would be better to prevent forwarding some built-in special member names prefixed by double-underscore through alias this or opDispatch. As we've already patched in library code like, https://github.com/D-Programming-Language/druntime/pull/1313 forwarding of __xpostblit and __xdtor are hardly useless. From the dmd internal view, the complete list of "no forward" members would be: __ctor (Id.ctor) __dtor (Id.dtor) __xdtor (Id.__xdtor) __postblit (Id.postblit) __xpostblit (Id.__xpostblit) Following double-underscore member names are invisible with "something.name" syntax, so they don't need to be considered. __fieldDtor (Id.__fieldDtor) __aggrDtor (Id.__aggrDtor) __fieldPostblit (Id.__fieldPostblit) __aggrPostblit (Id.__aggrPostblit) __invariant (Id.classInvariant) __xopEquals (Id.xopEquals) __xopCmp (Id.xopCmp) __xtoHash (Id.xtoHash) If we kill the forwarding for the specific names, we can just modify Type.noMember function behavior.
Comment #3 by code — 2015-09-14T17:58:07Z
(In reply to Kenji Hara from comment #2) > IMHO, it would be better to prevent forwarding some built-in special member > names prefixed by double-underscore through alias this or opDispatch. > > As we've already patched in library code like, > > https://github.com/D-Programming-Language/druntime/pull/1313 > > forwarding of __xpostblit and __xdtor are hardly useless. > > From the dmd internal view, > the complete list of "no forward" members would be: > > __ctor (Id.ctor) > __dtor (Id.dtor) > __xdtor (Id.__xdtor) > __postblit (Id.postblit) > __xpostblit (Id.__xpostblit) Oh yes, that's a much better solution. The semantics of those builtin member functions don't make sense with forwarding (through alias this or for opDispatch) anyhow.
Comment #4 by k.hara.pg — 2015-09-15T02:24:45Z
(In reply to Martin Nowak from comment #3) > Oh yes, that's a much better solution. The semantics of those builtin member > functions don't make sense with forwarding (through alias this or for > opDispatch) anyhow. Implemented compiler fix: https://github.com/D-Programming-Language/dmd/pull/5077
Comment #5 by github-bugzilla — 2015-09-15T13:44:11Z
Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/38ede7450d198bde07d8089bb6fce2fff7c2d950 fix Issue 15045 - hasElaborateCopyConstructor is true for struct with opDispatch Stop forwarding these special aggregate members through opDispatch, alias this, or opDot. __ctor (Id.ctor) __dtor (Id.dtor) __xdtor (Id.__xdtor) __postblit (Id.postblit) __xpostblit (Id.__xpostblit) https://github.com/D-Programming-Language/dmd/commit/2c94b22fce321b36d18c5eefd2d845a442f3afad Merge pull request #5077 from 9rnsr/fix15045 [REG2.069-devel] Issue 15045 - hasElaborateCopyConstructor is true for struct with opDispatch
Comment #6 by k.hara.pg — 2015-09-16T00:22:18Z
Change to dmd issue.
Comment #7 by k.hara.pg — 2015-09-16T00:24:28Z
*** Issue 15016 has been marked as a duplicate of this issue. ***