Thread overview
[Issue 19786] alias to __traits(getMember) wrongfully always binds to this
Apr 03, 2019
Basile-z
Apr 04, 2019
RazvanN
Apr 04, 2019
Basile-z
Apr 04, 2019
RazvanN
Apr 11, 2019
Basile-z
Mar 21, 2020
Basile-z
May 24, 2020
Basile-z
May 24, 2020
Basile-z
April 03, 2019
https://issues.dlang.org/show_bug.cgi?id=19786

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@erdani.com
           Assignee|nobody@puremagic.com        |edi33416@gmail.com

--
April 03, 2019
https://issues.dlang.org/show_bug.cgi?id=19786

--- Comment #1 from Andrei Alexandrescu <andrei@erdani.com> ---
Very ironically I'm assigning this to Edi :o).

--
April 03, 2019
https://issues.dlang.org/show_bug.cgi?id=19786

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b2.temp@gmx.com
           Hardware|x86_64                      |All
                 OS|Linux                       |All
           Severity|enhancement                 |normal

--- Comment #2 from Basile-z <b2.temp@gmx.com> ---
See TypeTraits semantics.

Related PR were:

- https://github.com/dlang/dmd/pull/8938
- https://github.com/dlang/dmd/pull/8945
- https://github.com/dlang/dmd/pull/8992

--
April 04, 2019
https://issues.dlang.org/show_bug.cgi?id=19786

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #3 from RazvanN <razvan.nitu1305@gmail.com> ---
I think that this code should error. Aliases can be made to types or symbols, however you are trying to alias an expression. For example, simply trying:

alias tmp = rhs.x;

will result in a compilation error. I don't see how that code can be accepted without redefining the notion of traits. As for the implementation of TypeTraits, I think it was a mistake to allow all traits to be used as types. As you can see, some traits cannot be types. This bug report is an example of how the the type system is bypassed via TypeTraits: the expression returned by __traits is wrapped in a TypeTraits, therefore the compiler thinks it's okay to alias it.

--
April 04, 2019
https://issues.dlang.org/show_bug.cgi?id=19786

--- Comment #4 from Basile-z <b2.temp@gmx.com> ---
I wont fix the issue since it's assigned but just a few words to clarify the problem:

1. The wrong symbol is return because of a call to `getDsymbolWithoutExp()`
(https://github.com/dlang/dmd/blob/93b4b99b0b024d238b223e73804c1d0c01ee42ec/src/dmd/typesem.d#L1637)

2. After this call, a type is returned from the `TraitExp`, always, even when the `TraitsExp` doesn't represent a `Type`. That's because `getType()` returns the type of the expression when the expression itself doesn't represents/wraps a `Type`.

The fix would consist into detecting the invalid stuff beforehand

---
if (Expression e = semanticTraits(mtype.exp, sc))
{
    if (TupleExp te = e.toTupleExp)
        mtype.sym = new TupleDeclaration(mtype.loc,
            Identifier.generateId("__aliastup"), cast(Objects*) te.exps);
    else if (Dsymbol ds = getDsymbol(e))
        mtype.sym = ds;

    // detect invalid cases such as 19786 here at worst

    // if you reach this point with smthg like issue 19786 it's too late
    else if (Dsymbol ds = getDsymbolWithoutExpCtx(e))
        mtype.sym = ds;

    // if you reach this point with an invalid case it's too late
    else if (Type t = getType(e))
        result = t.addMod(mtype.mod);
}
---

Note in reaction to previous comment, `rhs` is not an expression, it's a `VarDeclaration`, so a symbol.

--
April 04, 2019
https://issues.dlang.org/show_bug.cgi?id=19786

--- Comment #5 from RazvanN <razvan.nitu1305@gmail.com> ---
(In reply to Basile-z from comment #4)
> I wont fix the issue since it's assigned but just a few words to clarify the problem:
> 
> 1. The wrong symbol is return because of a call to `getDsymbolWithoutExp()`
> (https://github.com/dlang/dmd/blob/93b4b99b0b024d238b223e73804c1d0c01ee42ec/
> src/dmd/typesem.d#L1637)
> 
> 2. After this call, a type is returned from the `TraitExp`, always, even when the `TraitsExp` doesn't represent a `Type`. That's because `getType()` returns the type of the expression when the expression itself doesn't represents/wraps a `Type`.
> 
> The fix would consist into detecting the invalid stuff beforehand
>
Fixing this specific case is trivial, but fixing the general case is more complicated because there are a lot of corner cases (expressions that might or might no be convertible to symbols/types).
> ---
> if (Expression e = semanticTraits(mtype.exp, sc))
> {
>     if (TupleExp te = e.toTupleExp)
>         mtype.sym = new TupleDeclaration(mtype.loc,
>             Identifier.generateId("__aliastup"), cast(Objects*) te.exps);
>     else if (Dsymbol ds = getDsymbol(e))
>         mtype.sym = ds;
> 
>     // detect invalid cases such as 19786 here at worst
> 
>     // if you reach this point with smthg like issue 19786 it's too late
>     else if (Dsymbol ds = getDsymbolWithoutExpCtx(e))
>         mtype.sym = ds;
> 
>     // if you reach this point with an invalid case it's too late
>     else if (Type t = getType(e))
>         result = t.addMod(mtype.mod);
> }
> ---
> 
> Note in reaction to previous comment, `rhs` is not an expression, it's a `VarDeclaration`, so a symbol.

`rhs.x` is an expression, a DotVarExp. x is the var declaration that is returned and the this is implicitly added by the compiler in both cases.

--
April 11, 2019
https://issues.dlang.org/show_bug.cgi?id=19786

--- Comment #6 from Basile-z <b2.temp@gmx.com> ---
I have an excellent news. Si I was rewriting TypeTraits semantic, decomposing all possible Expressions kinds wit the idea to filter out the invalid cases and then realized that TypeTraits semantic is not the issue **at all**.

IN the original report, if you use the old way, i.e `AliasSeq`, then the same problem occurs, see https://run.dlang.io/is/PGzqGp.

The bug more likely lies in __traits semantic.

Sorry if my comment lead you in the wrong direction and good luck with the fix.

--
March 21, 2020
https://issues.dlang.org/show_bug.cgi?id=19786

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|b2.temp@gmx.com             |

--
May 24, 2020
https://issues.dlang.org/show_bug.cgi?id=19786

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b2.temp@gmx.com
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=14128

--
May 24, 2020
https://issues.dlang.org/show_bug.cgi?id=19786

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #7 from Basile-z <b2.temp@gmx.com> ---
you were right in https://issues.dlang.org/show_bug.cgi?id=19786#c3 RazvanN.

*** This issue has been marked as a duplicate of issue 14128 ***

--