fix issue 17177. AutoImplement fails on function overload sets with …#5119
fix issue 17177. AutoImplement fails on function overload sets with …#5119DmitryOlshansky merged 3 commits intodlang:masterfrom
Conversation
…cannot infer type from overloaded function symbol".
|
wilzbach
left a comment
wilzbach
left a comment
There was a problem hiding this comment.
This looks like a valid fix at the first glance. Thanks a lot!
However, as my CTFE-foo is limited maybe @UplinkCoder can spare a pair of eyes?
| if (WITH_BASE_CLASS && !__traits(isAbstractFunction, func)) | ||
| //preamble ~= "alias super." ~ name ~ " parent;\n"; // [BUG 2540] | ||
| preamble ~= "auto parent = &super." ~ name ~ ";\n"; | ||
| preamble ~= "alias parent = AliasSeq!(__traits(getMember, super, \"" ~ name ~ "\"))[0];"; |
There was a problem hiding this comment.
The only thing that catches my eye is that AliasSeq!(...)[0] pattern - is it required?
There was a problem hiding this comment.
Yes, that's to work around a grammar limitation with alias = __traits. The compiler will complain something like "basic type expected, not __traits" and the identity template (which AliasSeq is) works around it, and the [0] kills the tupleness introduced by it.
I've used the pattern myself many times.
There was a problem hiding this comment.
A solution would be to use Identity alias from std.meta. The problem is that it is private for some reason. I'd say __traits would look nicer being encapsulated in Identity alias rather than AliasSeq template.
adamdruppe
left a comment
adamdruppe
left a comment
There was a problem hiding this comment.
Looks good to me. Code seems fine, passes the new test, doesn't fail any others = win.
|
I don't know what's up with that codecov thing, the Details it links to appear nonsensical for this diff. |
FYI:
|
|
Auto-merge toggled on |
|
@DmitryOlshansky only approved PRs can be merged, hence the message:
|
5 participants
Issue: https://issues.dlang.org/show_bug.cgi?id=17177
Problem found in generation of "parent" that is used to reference super.member in AutoImplement template.
Fixed it by, aliasing
parentto getMember trait that getssuper.member, instead of assigningparenttosuper.memberdelegate.