[Issue 23913] __traits(getMember) fails for some C symbols

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=23913

--- Comment #4 from Dlang Bot  ---
dlang/dmd pull request #15238 "merge stable" was merged into master:

- 16ec7b681bf314b42a685428ce91d3234459405f by Walter Bright:
  fix Issue 23913 - __traits(getMember) fails for some C symbols (#15234)

https://github.com/dlang/dmd/pull/15238

--

[Issue 23913] __traits(getMember) fails for some C symbols

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=23913

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Dlang Bot  ---
dlang/dmd pull request #15234 "fix Issue 23913 - __traits(getMember) fails for
some C symbols" was merged into stable:

- 441885f9e5f329219c7de3a3e98da0ed8912dd20 by Walter Bright:
  fix Issue 23913 - __traits(getMember) fails for some C symbols

https://github.com/dlang/dmd/pull/15234

--

[Issue 23913] __traits(getMember) fails for some C symbols

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=23913

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Dlang Bot  ---
@WalterBright created dlang/dmd pull request #15234 "fix Issue 23913 -
__traits(getMember) fails for some C symbols" fixing this issue:

- fix Issue 23913 - __traits(getMember) fails for some C symbols

https://github.com/dlang/dmd/pull/15234

--

[Issue 23913] __traits(getMember) fails for some C symbols

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=23913

Andrej Mitrovic  changed:

   What|Removed |Added

   Keywords|betterC |ImportC

--- Comment #1 from Andrej Mitrovic  ---
Corrected wrong keyword.

--

[Issue 23913] New: __traits(getMember) fails for some C symbols

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=23913

  Issue ID: 23913
   Summary: __traits(getMember) fails for some C symbols
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: betterC
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: andrej.mitrov...@gmail.com

This works in v2.102.0 but fails in v2.013.x:

library.c:

```
typedef enum SomeEnum
{
foo = 0,
bar = -1,
} SomeEnum;
```

mod.d:

```
module mod;

import library;

alias x = __traits(getMember, library, "SomeEnum");
```

```
$ dmd -c library.c mod.d
[1]28653 illegal hardware instruction (core dumped)  dmd -c library.c mod.d
core.exception.AssertError@src/dmd/expressionsem.d(13055): Assertion failure
```

Specifically:
https://github.com/dlang/dmd/blob/a45f4e9f43e9fdbf0b666175e5e66b1ce4f561f6/compiler/src/dmd/expressionsem.d#L13054

It seems to only fail for typedef'ed enums like this.

--

[Issue 20941] __traits(getMember) should not allow safe code to access private fields

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=20941

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P4

--

[Issue 17124] dmd segfaults on __traits(getMember, ...)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17124

RazvanN  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #6 from RazvanN  ---
I also cannot reproduce this. Why was this reopened?

--

[Issue 12223] __traits(getMember,...) needed for aliases

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12223

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |FIXED

--- Comment #8 from RazvanN  ---
This issue has been fixed by: https://github.com/dlang/dmd/pull/11442

--

[Issue 23241] __traits getMember breaks compilation when hit an alias

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=23241

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Dlang Bot  ---
dlang/dmd pull request #14298 "Fix Issue 23241 - Consider types with no symbol
(e.g. int) to have no…" was merged into master:

- 251dbdf030280add92afea6fef45482926cc955d by mhh:
  Fix Issue 23241 - Consider types with no symbol (e.g. int) to have no
attributes

https://github.com/dlang/dmd/pull/14298

--

[Issue 23241] __traits getMember breaks compilation when hit an alias

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=23241

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Dlang Bot  ---
@maxhaton created dlang/dmd pull request #14298 "Fix Issue 23241 - Consider
types with no symbol (e.g. int) to have no…" fixing this issue:

- Fix Issue 23241 - Consider types with no symbol (e.g. int) to have no
attributes

https://github.com/dlang/dmd/pull/14298

--

[Issue 23241] New: __traits getMember breaks compilation when hit an alias

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=23241

  Issue ID: 23241
   Summary: __traits getMember breaks compilation when hit an
alias
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ryuukk@gmail.com

```
onlineapp.d(12): Error: first argument is not a symbol
```

```
module a;
import std;

@("hi")
void main()
{
alias THIS_MODULE = a;
static foreach (member; __traits(allMembers, THIS_MODULE))
{
writeln("member: ", member);
static foreach (attr; __traits(getAttributes, __traits(getMember,
THIS_MODULE, member))) 
{
writeln("\tattribute: ", attr);
}
}
}

enum :int
{
A, B, C
}

// commenting this out fixes it
alias MyEnum = int;
``` 

Expected behavior:

It should ignore either ignore the alias and compile, or support the alias

--

[Issue 21008] dmd segfaults because of __traits(getMember, ...) and virtual function overriding

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21008

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Dlang Bot  ---
dlang/dmd pull request #13724 "fix Issue 21008 - dmd segfaults because of
__traits(getMember, ...) a…" was merged into master:

- 088d11bb2497c7ca4a6d58652f940a643fc95a39 by Walter Bright:
  fix Issue 21008 - dmd segfaults because of __traits(getMember, ...) and
virtual function overriding

https://github.com/dlang/dmd/pull/13724

--

[Issue 21008] dmd segfaults because of __traits(getMember, ...) and virtual function overriding

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21008

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #4 from Dlang Bot  ---
@WalterBright created dlang/dmd pull request #13724 "fix Issue 21008 - dmd
segfaults because of __traits(getMember, ...) a…" fixing this issue:

- fix Issue 21008 - dmd segfaults because of __traits(getMember, ...) and
virtual function overriding

https://github.com/dlang/dmd/pull/13724

--

[Issue 21008] dmd segfaults because of __traits(getMember, ...) and virtual function overriding

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21008

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #3 from Walter Bright  ---
Smaller test case (without templates):

class Base
{
bool after();

mixin(handleMiddlewareAnnotation);
}

class C : Base
{
override bool after();
}

string handleMiddlewareAnnotation()
{
foreach (member; __traits(allMembers, C))
{
__traits(getMember, C, member);
}
}

--

[Issue 15371] __traits(getMember) should bypass the protection

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15371

--- Comment #11 from Dlang Bot  ---
dlang/dmd pull request #12135 "[dmd-cxx] Fix Issue 15371 - __traits(getMember)
should bypass the protection" was merged into dmd-cxx:

- 286cb9c2f46610bc3874301dae9264f28939051f by Iain Buclaw:
  [dmd-cxx] Fix Issue 15371 - __traits(getMember) should bypass the protection

https://github.com/dlang/dmd/pull/12135

--

[Issue 12223] __traits(getMember,...) needed for aliases

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12223

--- Comment #7 from Dlang Bot  ---
dlang/dmd pull request #12093 "[dmd-cxx] Backport more recent traits to the C++
port" was merged into dmd-cxx:

- 1474ca231a6e9cf6a76c918661495242464b646e by Richard Manthorpe:
  [dmd-cxx] Fix Issue 12223 - __traits(getMember,...) needed for aliases

https://github.com/dlang/dmd/pull/12093

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15094

--- Comment #10 from Dlang Bot  ---
dlang/dmd pull request #12093 "[dmd-cxx] Backport more recent traits to the C++
port" was merged into dmd-cxx:

- 542f9a47d165eb27b2d3b937cadd119c779b07fe by JinShil:
  [dmd-cxx] Fix Issue 15094 - __traits(getMember) fails when the source is a
struct/class field

https://github.com/dlang/dmd/pull/12093

--

[Issue 12223] __traits(getMember,...) needed for aliases

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12223

--- Comment #6 from Dlang Bot  ---
@ibuclaw created dlang/dmd pull request #12093 "[dmd-cxx] Backport more recent
traits to the C++ port" mentioning this issue:

- [dmd-cxx] Fix Issue 12223 - __traits(getMember,...) needed for aliases

https://github.com/dlang/dmd/pull/12093

--

[Issue 12223] __traits(getMember,...) needed for aliases

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12223

--- Comment #5 from Dlang Bot  ---
dlang/dmd pull request #11442 "Fix Issue 12223 - __traits(getMember,...) needed
for aliases" was merged into master:

- da1a31509f43547a89fd7cd694499548ba345ee0 by Richard Manthorpe:
  Issue 12223 - __traits(getMember,...) needed for aliases

  Add `__traits(child, p, c)` to interpret `c` with the `this` context set to
`p`.
  This is the opposite of `__traits(parent, c)`. `c` should be a symbol mising
it's
  `this` context, such an an alias to a member of `p`.

https://github.com/dlang/dmd/pull/11442

--

[Issue 12223] __traits(getMember,...) needed for aliases

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12223

--- Comment #4 from Dlang Bot  ---
@rmanthorpe created dlang/dmd pull request #11442 "Issue 12223 -
__traits(getMember,...) needed for aliases" mentioning this issue:

- Issue 12223 - __traits(getMember,...) needed for aliases

  Add `__traits(child, p, c)` to interpret `c` with the `this` context set to
`p`.
  This is the opposite of `__traits(parent, c)`. `c` should be a symbol mising
it's
  `this` context, such an an alias to a member of `p`.

https://github.com/dlang/dmd/pull/11442

--

[Issue 21008] dmd segfaults because of __traits(getMember, ...) and virtual function overriding

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21008

Basile-z  changed:

   What|Removed |Added

   Keywords||ice

--

[Issue 21008] dmd segfaults because of __traits(getMember, ...) and virtual function overriding

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21008

--- Comment #2 from moonlightsenti...@disroot.org ---
Slightly different stack trace for current HEAD
(3c8b519cbc30935e0b66d97d04663156bbd3dc63):

core.exception.RangeError@dmd/root/array.d(259): Range violation

??:? _d_arrayboundsp [0x7f1929da2a75]
dmd/root/array.d:259 _ZN5ArrayIP7DsymbolEixEm [0x7f1929be65d6]
dmd/dsymbolsem.d:3724
_ZN22DsymbolSemanticVisitor23funcDeclarationSemanticEP15FuncDeclaration
[0x7f1929b55d7e]
dmd/dsymbolsem.d:4114 _ZN22DsymbolSemanticVisitor5visitEP15FuncDeclaration
[0x7f1929b57194]
dmd/func.d:2558 _ZN15FuncDeclaration6acceptEP7Visitor [0x7f1929bbd8e5]
dmd/dsymbolsem.d:564 _Z15dsymbolSemanticP7DsymbolP5Scope [0x7f1929b4be75]
dmd/typesem.d:4305 dmd.expression.Expression dmd.typesem.dotExp(dmd.mtype.Type,
dmd.dscope.Scope*, dmd.expression.Expression, dmd.identifier.Identifier,
int).visitClass(dmd.mtype.TypeClass) [0x7f1929c8fe5a]
dmd/typesem.d:4350 dmd.expression.Expression dmd.typesem.dotExp(dmd.mtype.Type,
dmd.dscope.Scope*, dmd.expression.Expression, dmd.identifier.Identifier, int)
[0x7f1929c8b346]
dmd/expressionsem.d:11890 dmd.expression.Expression
dmd.expressionsem.semanticY(dmd.expression.DotIdExp, dmd.dscope.Scope*, int)
[0x7f1929bb656f]
dmd/expressionsem.d:6151 _ZN25ExpressionSemanticVisitor5visitEP8DotIdExp
[0x7f1929ba4b55]
dmd/expression.d:4574 _ZN8DotIdExp6acceptEP7Visitor [0x7f1929b8a59d]
dmd/expressionsem.d:11488 _Z18expressionSemanticP10ExpressionP5Scope
[0x7f1929bb4d2f]
dmd/traits.d:1002 dmd.expression.Expression
dmd.traits.semanticTraits(dmd.expression.TraitsExp, dmd.dscope.Scope*)
[0x7f1929c7e029]
dmd/expressionsem.d:5288 _ZN25ExpressionSemanticVisitor5visitEP9TraitsExp
[0x7f1929ba1b6c]
dmd/expression.d:4009 _ZN9TraitsExp6acceptEP7Visitor [0x7f1929b88dd1]
dmd/expressionsem.d:11488 _Z18expressionSemanticP10ExpressionP5Scope
[0x7f1929bb4d2f]
dmd/statementsem.d:186 _ZN24StatementSemanticVisitor5visitEP12ExpStatement
[0x7f1929c669d1]
dmd/statement.d:750 _ZN12ExpStatement6acceptEP7Visitor [0x7f1929c6243d]
dmd/statementsem.d:131 _Z17statementSemanticP9StatementP5Scope [0x7f1929c668bb]
dmd/statementsem.d:244 _ZN24StatementSemanticVisitor5visitEP17CompoundStatement
[0x7f1929c66c93]
dmd/statement.d:938 _ZN17CompoundStatement6acceptEP7Visitor [0x7f1929c62cb9]
dmd/statementsem.d:131 _Z17statementSemanticP9StatementP5Scope [0x7f1929c668bb]
dmd/statementsem.d:445 _ZN24StatementSemanticVisitor5visitEP14ScopeStatement
[0x7f1929c677e1]
dmd/statement.d:1045 _ZN14ScopeStatement6acceptEP7Visitor [0x7f1929c630b9]
dmd/statementsem.d:131 _Z17statementSemanticP9StatementP5Scope [0x7f1929c668bb]
dmd/statementsem.d:419
_ZN24StatementSemanticVisitor5visitEP21UnrolledLoopStatement [0x7f1929c676b1]
dmd/statement.d:1003 _ZN21UnrolledLoopStatement6acceptEP7Visitor
[0x7f1929c62f59]
dmd/statementsem.d:131 _Z17statementSemanticP9StatementP5Scope [0x7f1929c668bb]
dmd/statementsem.d:1165 _ZN24StatementSemanticVisitor5visitEP16ForeachStatement
[0x7f1929c68607]
dmd/statement.d:1320 _ZN16ForeachStatement6acceptEP7Visitor [0x7f1929c638b1]
dmd/statementsem.d:131 _Z17statementSemanticP9StatementP5Scope [0x7f1929c668bb]
dmd/statementsem.d:244 _ZN24StatementSemanticVisitor5visitEP17CompoundStatement
[0x7f1929c66c93]
dmd/statement.d:938 _ZN17CompoundStatement6acceptEP7Visitor [0x7f1929c62cb9]
dmd/statementsem.d:131 _Z17statementSemanticP9StatementP5Scope [0x7f1929c668bb]
dmd/semantic3.d:575 _ZN16Semantic3Visitor5visitEP15FuncDeclaration
[0x7f1929c5c712]
dmd/func.d:2558 _ZN15FuncDeclaration6acceptEP7Visitor [0x7f1929bbd8e5]
dmd/semantic3.d:81 _Z9semantic3P7DsymbolP5Scope [0x7f1929c5b14d]
dmd/func.d:455 _ZN15FuncDeclaration17functionSemantic3Ev [0x7f1929bb85b1]
dmd/func.d:429 _ZN15FuncDeclaration16functionSemanticEv [0x7f1929bb84c6]
dmd/expressionsem.d:918 dmd.expression.Expression
dmd.expressionsem.symbolToExp(dmd.dsymbol.Dsymbol, ref const(dmd.globals.Loc),
dmd.dscope.Scope*, bool) [0x7f1929b932c8]
dmd/expressionsem.d:3331 _ZN25ExpressionSemanticVisitor5visitEP8ScopeExp
[0x7f1929b9a813]
dmd/expression.d:3320 _ZN8ScopeExp6acceptEP7Visitor [0x7f1929b872f9]
dmd/expressionsem.d:11488 _Z18expressionSemanticP10ExpressionP5Scope
[0x7f1929bb4d2f]
dmd/expressionsem.d:101 bool dmd.expressionsem.expressionsToString(ref
dmd.root.outbuffer.OutBuffer, dmd.dscope.Scope*,
dmd.root.array.Array!(dmd.expression.Expression).Array*) [0x7f1929b90e62]
dmd/dsymbolsem.d:2101
_ZN22DsymbolSemanticVisitor9compileItEP18CompileDeclaration [0x7f1929b50ef4]
dmd/dsymbolsem.d:2131 _ZN22DsymbolSemanticVisitor5visitEP18CompileDeclaration
[0x7f1929b5115f]
dmd/attrib.d:1344 _ZN18CompileDeclaration6acceptEP7Visitor [0x7f1929ad31a5]
dmd/dsymbolsem.d:564 _Z15dsymbolSemanticP7DsymbolP5Scope [0x7f1929b4be75]
dmd/dsymbolsem.d:5369 void
dmd.dsymbolsem.DsymbolSemanticVisitor.visit(dmd.dclass.ClassDeclaration).__lambda10!(dmd.dsymbol.Dsymbol).__lambda10(dmd.dsymbol.Dsymbol)
[0x7f1929b5bf0f]
dmd/dsymbol.d:99 void
dmd.dsymbol.foreachDsymbol(dmd.root.array.Array!(dmd.dsymbol.Dsymbol).Array*,

[Issue 21008] dmd segfaults because of __traits(getMember, ...) and virtual function overriding

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21008

moonlightsenti...@disroot.org changed:

   What|Removed |Added

 CC||moonlightsentinel@disroot.o
   ||rg
   Hardware|x86 |All

--- Comment #1 from moonlightsenti...@disroot.org ---
Reduced test case:

==
class ControllerBase(T)
{
bool after() {}

mixin(handleMiddlewareAnnotation!T);
}

class DemoController : ControllerBase!DemoController
{
bool after() {}
}

string handleMiddlewareAnnotation(T)()
{
foreach (memberName; __traits(allMembers, T))
__traits(getMember, T, memberName);
}
==

Running a debug dmd yields the following trace:

dmd -c -o- test.d

---
ERROR: This is a compiler bug.
Please report it via https://issues.dlang.org/enter_bug.cgi
with, preferably, a reduced, reproducible example and the information below.
DustMite (https://github.com/CyberShadow/DustMite/wiki) can help with the
reduction.
---
DMD v2.092.1

predefs   DigitalMars Posix linux ELFv1 CRuntime_Glibc CppRuntime_Gcc
LittleEndian D_Version2 all D_SIMD D_InlineAsm_X86_64 X86_64 D_LP64 D_PIC
assert D_ModuleInfo D_Exceptions D_TypeInfo D_HardFloat
binary../generated/linux/debug/64/dmd
version   v2.092.1

config../generated/linux/debug/64/dmd.conf
DFLAGS-I../generated/linux/debug/64/../../../../../druntime/import
-I../generated/linux/debug/64/../../../../../phobos
-L-L../generated/linux/debug/64/../../../../../phobos/generated/linux/debug/64
-L--export-dynamic -fPIC
---
core.exception.RangeError@dmd/root/array.d(251): Range violation

??:? _d_arrayboundsp [0x7fc38279b939]
dmd/root/array.d:251 _ZN5ArrayIP7DsymbolEixEm [0x7fc3825e1bda]
dmd/dsymbolsem.d:3724
_ZN22DsymbolSemanticVisitor23funcDeclarationSemanticEP15FuncDeclaration
[0x7fc382551656]
dmd/dsymbolsem.d:4115 _ZN22DsymbolSemanticVisitor5visitEP15FuncDeclaration
[0x7fc382552aa4]
dmd/func.d:2564 _ZN15FuncDeclaration6acceptEP7Visitor [0x7fc3825b900d]
dmd/dsymbolsem.d:564 _Z15dsymbolSemanticP7DsymbolP5Scope [0x7fc38254774d]
dmd/typesem.d:4298 dmd.expression.Expression dmd.typesem.dotExp(dmd.mtype.Type,
dmd.dscope.Scope*, dmd.expression.Expression, dmd.identifier.Identifier,
int).visitClass(dmd.mtype.TypeClass) [0x7fc38268a516]
dmd/typesem.d:4343 dmd.expression.Expression dmd.typesem.dotExp(dmd.mtype.Type,
dmd.dscope.Scope*, dmd.expression.Expression, dmd.identifier.Identifier, int)
[0x7fc382685a02]
dmd/expressionsem.d:11889 dmd.expression.Expression
dmd.expressionsem.semanticY(dmd.expression.DotIdExp, dmd.dscope.Scope*, int)
[0x7fc3825b1cbb]
dmd/expressionsem.d:6150 _ZN25ExpressionSemanticVisitor5visitEP8DotIdExp
[0x7fc3825a02a1]
dmd/expression.d:4577 _ZN8DotIdExp6acceptEP7Visitor [0x7fc382585d59]
dmd/expressionsem.d:11487 _Z18expressionSemanticP10ExpressionP5Scope
[0x7fc3825b047b]
dmd/traits.d:1002 dmd.expression.Expression
dmd.traits.semanticTraits(dmd.expression.TraitsExp, dmd.dscope.Scope*)
[0x7fc38267876d]
dmd/expressionsem.d:5284 _ZN25ExpressionSemanticVisitor5visitEP9TraitsExp
[0x7fc38259d2a8]
dmd/expression.d:4012 _ZN9TraitsExp6acceptEP7Visitor [0x7fc38258458d]
dmd/expressionsem.d:11487 _Z18expressionSemanticP10ExpressionP5Scope
[0x7fc3825b047b]
dmd/statementsem.d:186 _ZN24StatementSemanticVisitor5visitEP12ExpStatement
[0x7fc382661179]
dmd/statement.d:750 _ZN12ExpStatement6acceptEP7Visitor [0x7fc38265cc61]
dmd/statementsem.d:131 _Z17statementSemanticP9StatementP5Scope [0x7fc382661063]
dmd/statementsem.d:244 _ZN24StatementSemanticVisitor5visitEP17CompoundStatement
[0x7fc38266143b]
dmd/statement.d:938 _ZN17CompoundStatement6acceptEP7Visitor [0x7fc38265d4dd]
dmd/statementsem.d:131 _Z17statementSemanticP9StatementP5Scope [0x7fc382661063]
dmd/statementsem.d:445 _ZN24StatementSemanticVisitor5visitEP14ScopeStatement
[0x7fc382661f89]
dmd/statement.d:1045 _ZN14ScopeStatement6acceptEP7Visitor [0x7fc38265d8dd]
dmd/statementsem.d:131 _Z17statementSemanticP9StatementP5Scope [0x7fc382661063]
dmd/statementsem.d:419
_ZN24StatementSemanticVisitor5visitEP21UnrolledLoopStatement [0x7fc382661e59]
dmd/statement.d:1003 _ZN21UnrolledLoopStatement6acceptEP7Visitor
[0x7fc38265d77d]
dmd/statementsem.d:131 _Z17statementSemanticP9StatementP5Scope [0x7fc382661063]
dmd/statementsem.d:1165 _ZN24StatementSemanticVisitor5visitEP16ForeachStatement
[0x7fc382662daf]
dmd/statement.d:1320 _ZN16ForeachStatement6acceptEP7Visitor [0x7fc38265e0d5]
dmd/statementsem.d:131 _Z17statementSemanticP9StatementP5Scope [0x7fc382661063]
dmd/statementsem.d:244 _ZN24StatementSemanticVisitor5visitEP17CompoundStatement
[0x7fc38266143b]
dmd/statement.d:938 _ZN17CompoundStatement6acceptEP7Visitor [0x7fc38265d4dd]
dmd/statementsem.d:131 _Z17statementSemanticP9StatementP5Scope [0x7fc382661063]
dmd/semantic3.d:577

[Issue 17124] dmd segfaults on __traits(getMember, ...)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17124

Heromyth  changed:

   What|Removed |Added

 CC||bitwo...@qq.com

--- Comment #5 from Heromyth  ---
See here: https://issues.dlang.org/show_bug.cgi?id=21008.

--

[Issue 17124] dmd segfaults on __traits(getMember, ...)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17124

--- Comment #4 from zoujiaqing  ---
This issue needed : https://github.com/huntlabs/hunt-framework/issues/153

--

[Issue 17124] dmd segfaults on __traits(getMember, ...)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17124

zoujiaqing  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||zoujiaq...@gmail.com
 Resolution|WORKSFORME  |---

--- Comment #3 from zoujiaqing  ---
how to fix it?

--

[Issue 21008] New: dmd segfaults because of __traits(getMember, ...) and virtual function overriding

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21008

  Issue ID: 21008
   Summary: dmd segfaults because of __traits(getMember, ...) and
virtual function overriding
   Product: D
   Version: D2
  Hardware: x86
OS: All
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bitwo...@qq.com

When compiling the test code with dmd, the compiler will crash.

Test with dmd 2.092.0 and 2.088.1 on Windows and Linux.


Here is the code:
==
void main() {}

import std.traits;

abstract class Controller {
bool after();
}

abstract class ControllerBase(T) : Controller {
override bool after() {
return true;
}

mixin(handleMiddlewareAnnotation!(T));
}

class DemoController : ControllerBase!DemoController {

// Bug mark A
override bool after() {
return true;
}
}

string handleMiddlewareAnnotation(T)() {

foreach (memberName; __traits(allMembers, T)) {
alias currentMember = __traits(getMember, T, memberName); // Bug mark B
}

return "";
}
==

After commenting out the mark A or the mark B, the compiling will pass.

--

[Issue 20941] __traits(getMember) should not allow safe code to access private fields

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=20941

Stanislav Blinov  changed:

   What|Removed |Added

 CC||stanislav.bli...@gmail.com

--- Comment #1 from Stanislav Blinov  ---
For clarity, you mean modifying `tag` like so?

void unsafe() @safe
{
S s;
__traits(getMember, s, "tag") = 2; // should be error
s.set(42);
}

--

[Issue 20941] New: __traits(getMember) should not allow safe code to access private fields

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=20941

  Issue ID: 20941
   Summary: __traits(getMember) should not allow safe code to
access private fields
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

This is taken from DIP 1035:

struct S {
private union {
int x;
int* y;
}
private int tag; // x if 0, y if 1
// public @trusted interface follows
void set(int rhs) @trusted {
if (tag == 0) x = rhs;
else *y = rhs;
}

}

Allowing safe code to modify tag from @safe code, followed by calling set(),
results in unsafe code from safe functions.

This could be relaxed to restrict access only for types that have @trusted
functions.

--

[Issue 19786] alias to __traits(getMember) wrongfully always binds to this

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19786

Basile-z  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from Basile-z  ---
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 ***

--

[Issue 19786] alias to __traits(getMember) wrongfully always binds to this

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19786

Basile-z  changed:

   What|Removed |Added

 CC||b2.t...@gmx.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=14128

--

[Issue 17124] dmd segfaults on __traits(getMember, ...)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17124

Basile-z  changed:

   What|Removed |Added

 CC|b2.t...@gmx.com |

--

[Issue 19786] alias to __traits(getMember) wrongfully always binds to this

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19786

Basile-z  changed:

   What|Removed |Added

 CC|b2.t...@gmx.com |

--

[Issue 15371] __traits(getMember) should bypass the protection

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15371

Dlang Bot  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Dlang Bot  ---
dlang/dmd pull request #9585 "Fix Issue 15371 - __traits(getMember) should
bypass the protection" was merged into master:

- bd44bc789d98baf85d2b07cf6858c573c9be by RazvanN7:
  Fix Issue 15371 - __traits(getMember) should bypass the protection

https://github.com/dlang/dmd/pull/9585

--

[Issue 19786] alias to __traits(getMember) wrongfully always binds to this

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19786

--- Comment #6 from Basile-z  ---
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.

--

[Issue 15371] __traits(getMember) should bypass the protection

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15371

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #9 from Dlang Bot  ---
@RazvanN7 created dlang/dmd pull request #9585 "Fix Issue 15371 -
__traits(getMember) should bypass the protection" fixing this issue:

- Fix Issue 15371 - __traits(getMember) should bypass the protection

https://github.com/dlang/dmd/pull/9585

--

[Issue 19786] alias to __traits(getMember) wrongfully always binds to this

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19786

--- Comment #5 from RazvanN  ---
(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.

--

[Issue 19786] alias to __traits(getMember) wrongfully always binds to this

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19786

--- Comment #4 from Basile-z  ---
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.

--

[Issue 19786] alias to __traits(getMember) wrongfully always binds to this

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19786

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #3 from RazvanN  ---
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.

--

[Issue 19786] alias to __traits(getMember) wrongfully always binds to this

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19786

Basile-z  changed:

   What|Removed |Added

 CC||b2.t...@gmx.com
   Hardware|x86_64  |All
 OS|Linux   |All
   Severity|enhancement |normal

--- Comment #2 from Basile-z  ---
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

--

[Issue 19786] alias to __traits(getMember) wrongfully always binds to this

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19786

--- Comment #1 from Andrei Alexandrescu  ---
Very ironically I'm assigning this to Edi :o).

--

[Issue 19786] alias to __traits(getMember) wrongfully always binds to this

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19786

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com
   Assignee|nob...@puremagic.com|edi33...@gmail.com

--

[Issue 19786] New: alias to __traits(getMember) wrongfully always binds to this

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19786

  Issue ID: 19786
   Summary: alias to __traits(getMember) wrongfully always binds
to this
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: edi33...@gmail.com

Give the following code example
```
struct S
{
void foo(const ref S rhs)
{
alias thisMember = __traits(getMember, this, "x");
alias rhsMember = __traits(getMember, rhs, "x");

pragma(msg, thisMember.stringof);
pragma(msg, rhsMember.stringof);
pragma(msg, __traits(getMember, rhs, "x").stringof);
}

int x;
}
```

This outputs
```
this.x
this.x
rhs.x
```

As you can see, `rhsMember.stringof` evaluates to `this.x` instead of `rhs.x`

--

[Issue 15371] __traits(getMember) should bypass the protection

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15371

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=19761

--

[Issue 19717] ICE/segfault when using __traits(getMember) on overloaded function with "undefined identifier" error

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19717

--- Comment #1 from Basile-z  ---
That's a forward ref not detected. If you put the enum decl after foo()
overloads it exits with a normal program error.

--

[Issue 19717] ICE/segfault when using __traits(getMember) on overloaded function with "undefined identifier" error

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19717

Basile-z  changed:

   What|Removed |Added

   Keywords||ice
 CC||b2.t...@gmx.com

--

[Issue 19717] New: ICE/segfault when using __traits(getMember) on overloaded function with "undefined identifier" error

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19717

  Issue ID: 19717
   Summary: ICE/segfault when using __traits(getMember) on
overloaded function with "undefined identifier" error
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: elpenguin...@gmail.com

Reduced code:
```
enum bar = __traits(getMember, mixin(__MODULE__), "foo");

auto foo() {
return foo();
}

void foo(Foo) {}
```
This also prints a misleading error: `Error: cannot overload both property and
non-property functions`

The error appears to have been introduced after DMD 2.070.2.

--

[Issue 18601] alias m = __traits(getMember, ...) doesn't work

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18601

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||simen.kja...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #4 from Simen Kjaeraas  ---


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

--

[Issue 17571] Cannot create alias of __traits(getMember, ...)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17571

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||simen.kja...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #4 from Simen Kjaeraas  ---


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

--

[Issue 18601] alias m = __traits(getMember, ...) doesn't work

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18601

--- Comment #3 from Manu  ---
I'm trolling my Blizzard colleagues by trying to get them interested in D...
but the quality bar needs to be a LOT higher here to be convincing compared to
my former workplaces.

--

[Issue 18601] alias m = __traits(getMember, ...) doesn't work

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18601

--- Comment #2 from Manu  ---
Indeed, I am aware of the workaround, but that doesn't make the problem any
better.
People don't expect to have to wrap a thing in an Alias!() statement for no
logical reason... so it's just a gotcha that looks bad to new users (case in
question).

--

[Issue 18601] alias m = __traits(getMember, ...) doesn't work

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18601

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #1 from Jonathan M Davis  ---
It can be trivially worked around by wrapping the __traits expression in a
std.meta.Alias, but I don't understand why that should be necessary. Certainly,
it seems like it shouldn't be necessary.

--

[Issue 18601] New: alias m = __traits(getMember, ...) doesn't work

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18601

  Issue ID: 18601
   Summary: alias m = __traits(getMember, ...) doesn't work
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

It's annoying that this doesn't work:

```
struct S
{
int x;
}

void f()
{
S s;
alias m = __traits(getMember, s, "x");
}
```

> Error: basic type expected, not `__traits`
> Error: semicolon expected to close `alias` declaration


I'm pretty sure this could be trivially supported...?

I feel like that __traits statement should be semantically identical to:
   alias m = s.x;

The __traits(getMember) docs make you feel like that's true...

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15094

--- Comment #9 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/89c900316c02d7e845b151e02a460d89631a9d07
Fix Issue 15094 - __traits(getMember) fails when the source is a struct/class
field

https://github.com/dlang/dmd/commit/c9d988ebc0eca6137551eaacb961400acb2e7752
Merge pull request #7341 from JinShil/fix_15094

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15094

--- Comment #8 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/89c900316c02d7e845b151e02a460d89631a9d07
Fix Issue 15094 - __traits(getMember) fails when the source is a struct/class
field

https://github.com/dlang/dmd/commit/c9d988ebc0eca6137551eaacb961400acb2e7752
Merge pull request #7341 from JinShil/fix_15094

Fix Issue 15094 - __traits(getMember) fails when the source is a struct/class
field

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15094

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 17571] Cannot create alias of __traits(getMember, ...)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17571

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--- Comment #3 from Vladimir Panteleev  ---
It is a limitation of the current grammar. It's probably fixable by changing
the grammar, which I think would make sense.

--

[Issue 17571] Cannot create alias of __traits(getMember, ...)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17571

--- Comment #2 from Shachar Shemesh  ---
(In reply to Vladimir Panteleev from comment #1)
> It is a syntax issue. See:
> https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-
> nothing/

I'm sorry, I don't understand. Are you saying that because it is a syntax issue
it is not a bug?

Shachar

--

[Issue 17571] Cannot create alias of __traits(getMember, ...)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17571

Vladimir Panteleev <dlang-bugzi...@thecybershadow.net> changed:

   What|Removed |Added

   Hardware|x86_64  |All
Summary|Cannot create alias of  |Cannot create alias of
   |__traits(getMember  |__traits(getMember, ...)
 OS|Linux   |All

--- Comment #1 from Vladimir Panteleev <dlang-bugzi...@thecybershadow.net> ---
It is a syntax issue. See:
https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/

--

[Issue 17571] New: Cannot create alias of __traits(getMember

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17571

  Issue ID: 17571
   Summary: Cannot create alias of __traits(getMember
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: shac...@weka.io

Consider the following program:
import unistd = core.sys.posix.unistd;

alias func = __traits(getMember, unistd, "write");

When trying to compile:
test.d(3): Error: basic type expected, not __traits
test.d(3): Error: semicolon expected to close alias declaration
test.d(3): Error: declaration expected, not '__traits'

Since unistd.write is a function, there is no reason for me not to be able to
create an alias of it.

The only reason I'm marking this as a minor issue is because there is a
workaround:
import unistd = core.sys.posix.unistd;
import std.meta;

alias func = Alias!(__traits(getMember, unistd, "write"));

This, however, goes outside the definition of what std.meta.Alias was meant
for. It was meant for aliasing non-aliasable objects, not for aliasing
functions (which is what is happening in this case).

--

[Issue 17545] [REG2.072] __traits(getMember, mod, name) evaluates enum to value prematurely

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17545

johanenge...@weka.io changed:

   What|Removed |Added

   Keywords||industry

--

[Issue 17545] New: [REG2.072] __traits(getMember, mod, name) evaluates enum to value prematurely

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17545

  Issue ID: 17545
   Summary: [REG2.072] __traits(getMember, mod, name) evaluates
enum to value prematurely
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: johanenge...@weka.io

The following code used to compile with DMD 2.071, but fails for >=2.072.

```
module example;

import std.meta: staticIndexOf;

struct Attrib {}

@Attrib enum TEST = 123;

pragma(msg, __traits(getAttributes, 
     __traits(getMember, example, "TEST")));

```

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15094

Eyal  changed:

   What|Removed |Added

 CC||e...@weka.io

--- Comment #7 from Eyal  ---
This bit us in several places in the weka codebase.

--

[Issue 15371] __traits(getMember) should bypass the protection

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15371

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---

--

[Issue 17124] dmd segfaults on __traits(getMember, ...)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17124

Martin Krejcirik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Martin Krejcirik  ---
Can't reproduce it, either. Reopen, if new information.

--

[Issue 17124] dmd segfaults on __traits(getMember, ...)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17124

b2.t...@gmx.com changed:

   What|Removed |Added

 CC||b2.t...@gmx.com

--- Comment #1 from b2.t...@gmx.com ---
Neither 2.073 nor 2.074 alpha, with linux x86_64, crash with your code.
Did you forget a line of code or something else ?

--

[Issue 17124] New: dmd segfaults on __traits(getMember, ...)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17124

  Issue ID: 17124
   Summary: dmd segfaults on __traits(getMember, ...)
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: john.loughran.col...@gmail.com

// test.d
alias BS = BSPu;
alias BS = BSPr;
template BSPu() { }
template BSPr() { }
enum blah = is(typeof(__traits(getMember, test, "BS")));

running `dmd test.d` segfaults, here's the backtrace:

* thread #1: tid = 0x42286e, 0x00010008072e
dmd`resolvePropertiesOnly(Scope*, Expression*) + 798, queue =
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
frame #0: 0x00010008072e dmd`resolvePropertiesOnly(Scope*, Expression*)
+ 798
dmd`resolvePropertiesOnly:
->  0x10008072e <+798>: cmpb   $0x5, 0x8(%rcx)
0x100080732 <+802>: jne0x100080797   ; <+903>
0x100080734 <+804>: cmpl   $0x0, 0x7c(%rdi)
0x100080738 <+808>: jne0x10008074c   ; <+828>
(lldb) bt all
* thread #1: tid = 0x42286e, 0x00010008072e
dmd`resolvePropertiesOnly(Scope*, Expression*) + 798, queue =
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
  * frame #0: 0x00010008072e dmd`resolvePropertiesOnly(Scope*, Expression*)
+ 798
frame #1: 0x0001000f1555 dmd`TypeTypeof::resolve(Loc, Scope*,
Expression**, Type**, Dsymbol**, bool) + 213
frame #2: 0x0001000f1841 dmd`TypeTypeof::semantic(Loc, Scope*) + 65
frame #3: 0x0001000e25b2 dmd`Type::trySemantic(Loc, Scope*) + 66
frame #4: 0x00010009184e dmd`IsExp::semantic(Scope*) + 182
frame #5: 0x0001000cbdbe dmd`ExpInitializer::inferType(Scope*) + 38
frame #6: 0x00010003742e dmd`VarDeclaration::semantic(Scope*) + 334
frame #7: 0x0001000585de dmd`Module::semantic(Scope*) + 118
frame #8: 0x0001000df926 dmd`D4ddmd4mars7tryMainFmPPxaZi + 13494
frame #9: 0x00013273 dmd`_Dmain + 39
frame #10: 0x0001002438cc
dmd`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 40
frame #11: 0x0001002437f4
dmd`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv + 32
frame #12: 0x000100243871
dmd`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv + 45
frame #13: 0x0001002437f4
dmd`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv + 32
frame #14: 0x000100243767 dmd`_d_run_main + 459
frame #15: 0x0001330c dmd`main + 16
frame #16: 0x000118b4 dmd`start + 52

--

Re: __traits(getMember)

[Márcio Martins via Digitalmars-d]

On Wednesday, 2 November 2016 at 19:49:24 UTC, Jacob Carlborg 
wrote:

On 2016-11-02 17:30, Márcio Martins wrote:

Can we get a getMember and a getOverloads that won't check for
visibility or anything else?

__traits appears really powerful, but every-time I try to use 
it for
anything other than a toy example or very simple 
serialization, it seems
like everything falls apart due to some detail... and I end up 
having to
hack it up with string mixins and static if(is(typeof(() { 
some_code; }))).


For serialization, where you most likely only need to access 
the fields, you can use .tupleof which will bypass the 
protection.


@Jonathan I am on 2.072.0, but good to know it's coming.
@Jacob Thanks, that's good to know!

Re: __traits(getMember)

[Jacob Carlborg via Digitalmars-d]

On 2016-11-02 17:30, Márcio Martins wrote:

Can we get a getMember and a getOverloads that won't check for
visibility or anything else?

__traits appears really powerful, but every-time I try to use it for
anything other than a toy example or very simple serialization, it seems
like everything falls apart due to some detail... and I end up having to
hack it up with string mixins and static if(is(typeof(() { some_code; }))).


For serialization, where you most likely only need to access the fields, 
you can use .tupleof which will bypass the protection.


--
/Jacob Carlborg

Re: __traits(getMember)

[Jonathan M Davis via Digitalmars-d]

On Wednesday, November 02, 2016 16:30:04 Márcio Martins via Digitalmars-d 
wrote:
> Can we get a getMember and a getOverloads that won't check for
> visibility or anything else?

That's coming. There was a big discussion on it after the import rules were
changed. But IIRC, it was decided that we wouldn't just switch to that
immediately (maybe because it was a point release?). I don't remember the
details now, so I guess that I'm not very helpful. I'd suggest trying
2.072.0, now that it's out, and seeing if that fixes your problem. If not,
2.073.0 probably will when we get it - which wouldn't be very helpful now,
but at least you'd know that the change was coming.

- Jonathan M Davis

__traits(getMember)

[Márcio Martins via Digitalmars-d]

Can we get a getMember and a getOverloads that won't check for 
visibility or anything else?


__traits appears really powerful, but every-time I try to use it 
for anything other than a toy example or very simple 
serialization, it seems like everything falls apart due to some 
detail... and I end up having to hack it up with string mixins 
and static if(is(typeof(() { some_code; }))).



Also, I found this bug:

import std.datetime;
import std.stdio;
import std.traits;
import std.meta;

template staticIota(int start, int stop, int step = 1) {
  static if(start < stop) {
alias staticIota = AliasSeq!(start, staticIota!(start + step, 
stop, step));

  } else {
alias staticIota = AliasSeq!();
  }
}

struct M {
  void test(T)(T x) {
enum MemberName = "day";
foreach (i; staticIota!(0, __traits(getOverloads, x, 
MemberName).length)) {
  alias Member = Alias!(__traits(getOverloads, x, 
MemberName)[i]);
  alias MemberType = typeof(&__traits(getOverloads, x, 
MemberName)[i]);


  static if (is(FunctionTypeOf!(Member)) && 
(__traits(getProtection, Member) == "public")) {
auto addr =  //Error: this for day needs to be 
type Date not type M

pragma(msg, MemberName, MemberType);
writeln("addr: ", addr);
  }
}
  }
}

void main() {
  Date x;
  M m;
  m.test(x);
}

// output:
errocase.d(23): Error: this for day needs to be type Date not 
type M

dayubyte delegate() const pure nothrow @property @safe
errocase.d(23): Error: this for day needs to be type Date not 
type M

dayvoid delegate(int day) pure @property @safe
errocase.d(34): Error: template instance errocase.M.test!(Date) 
error instantiating



It works fine if test(T)() is not a member function...

[Issue 15371] __traits(getMember) should bypass the protection

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15371

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #8 from b2.t...@gmx.com ---
With the direction took by https://github.com/dlang/dmd/pull/6078 this
improvement is now impossible.

--

[Issue 15371] __traits(getMember) should bypass the protection

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15371

--- Comment #7 from b2.t...@gmx.com ---
related https://issues.dlang.org/show_bug.cgi?id=10267

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15094

Ali Cehreli  changed:

   What|Removed |Added

   Keywords||industry
 CC||acehr...@yahoo.com

--

[Issue 15371] __traits(getMember) should bypass the protection

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15371

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #6 from Martin Nowak  ---
(In reply to b2.temp from comment #3)
> Also if a template would be instantiated in the module that use it...

Well, there are plenty of reasons to not do that, foremost being that template
instantiations should be independent of instantiation scope.
That's why we have mixin template as an alternative.

--

[Issue 15371] __traits(getMember) should bypass the protection

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15371

Jacob Carlborg  changed:

   What|Removed |Added

 CC||d...@me.com

--- Comment #5 from Jacob Carlborg  ---
A pointer can be used as well to bypass the protection. It works for other
symbols than fields.

--

[Issue 15371] __traits(getMember) should bypass the protection

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15371

--- Comment #4 from b2.t...@gmx.com ---
In the meantime, when the trait code is for a struct or a class it's possible
to use its '.tupleof' property. It's not affected by the visibility.

Instead of all member:

import std.meta: aliasSeqOf;
import std.range: iota;
foreach(i;  aliasSeqOf!(iota(0, T.tupleof.length)))
{
alias MT = typeof(T.tupleof[i]);
...
}
This is not exactly the same but when the trait code is to inspect the variable
types or UDAs it works fine.

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15094

Johan Engelen  changed:

   What|Removed |Added

 CC||jbc.enge...@gmail.com

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15094

--- Comment #6 from Eyal Lotem <eyal.lo...@gmail.com> ---
Even after applying the PR
(https://github.com/D-Programming-Language/dmd/pull/5215):

```
struct S { int i; }
S s;

unittest {
import std.meta : Alias;

alias GetMember1 =
Alias!(__traits(getMember, mixin(__MODULE__), "s"));
alias GetMember2 =
    Alias!(__traits(getMember, GetMember1, "i"));
alias GetMember3 =
    Alias!(__traits(getMember,
    __traits(getMember, mixin(__MODULE__), "s"),
"i"));

// Works:
auto a1 = 
// Fails:
auto a2 = 
// Fails:
auto a3 = 
// Works:
auto a4 =
    &__traits(getMember,
  __traits(getMember, mixin(__MODULE__), "s"),
  "i");
}
```

fails (in a2, a3).

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15094

Eyal Lotem <eyal.lo...@gmail.com> changed:

   What|Removed |Added

 CC||eyal.lo...@gmail.com

--- Comment #5 from Eyal Lotem <eyal.lo...@gmail.com> ---
Even after applying the PR
(https://github.com/D-Programming-Language/dmd/pull/5215):

```
struct S { int i; }
S s;

unittest {
import std.meta : Alias;

alias GetMember1 =
    Alias!(__traits(getMember, mixin(__MODULE__), "s"));
alias GetMember2 =
    Alias!(__traits(getMember, GetMember1, "i"));
alias GetMember3 =
    Alias!(__traits(getMember,
    __traits(getMember, mixin(__MODULE__), "s"),
"i"));

// Works:
auto a1 = 
// Fails:
auto a2 = 
// Fails:
auto a3 = 
    // Works:
auto a4 =
    &__traits(getMember,
  __traits(getMember, mixin(__MODULE__), "s"),
  "i");
}
```

fails (in a2, a3).

--

[Issue 15371] __traits(getMember) should bypass the protection

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15371

--- Comment #3 from b2.t...@gmx.com ---
Also if a template would be instantiated in the module that use it...

--

[Issue 15371] __traits(getMember) should bypass the protection

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15371

--- Comment #2 from bb.t...@gmx.com ---
https://github.com/D-Programming-Language/dmd/pull/5289


On n'est jamais mieux servi que par soi-même.

--

[Issue 15371] New: __traits(getMember) should bypass the protection

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15371

  Issue ID: 15371
   Summary: __traits(getMember) should bypass the protection
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bb.t...@gmx.com

"__traits(getMember,...)" should always work, whatever is the member protection
(as long as the symbol is a valid one).

The current limitation is problematic because it prevents to write functions
related to traits in a separate dedicated modules (e.g mylib.traits)

Every time a "__traits(getMember,...)" has to be used the only solution to make
it works with a private member is to write again and again the code (or to warp
the function in a mixin template).

Since there is also the traits verb "getProtection", it still would be possible
to respect the protection or not.

In case this wouldn't be clear, more concretly:

==
module mylib.traits;

mixin template ScopedReachability()
{
bool isMemberReachableGood(T, string member)()
if (is(T==class) || is(T==struct))
{
return __traits(compiles, __traits(getMember, T, member));
}
}
bool isMemberReachableBad(T, string member)()
if (is(T==class) || is(T==struct))
{
 return __traits(compiles, __traits(getMember, T, member));
}

=
module somemodule;

class Foo
{
private: 
uint a,b,c;
public:
this()
{
foreach(member; __traits(allMembers, Foo))
static if (isMemberReachableBad!(Foo, member)) {/*a,b,c not detected*/}

import mylib.traits;
mixin ScopedReachability; // isMemberReachableGood is now a local func. 
static if (isMemberReachableGood!(Foo, member)) {/*a,b,c detected*/} 
}
}

=

With a relaxed protection policy on the "getMember" verb, it would be possible
to write reusable functions related to traits. Actually the problem prevents a
lot of good template that would simplify the traits usage to be written.

=

see also:

- https://issues.dlang.org/show_bug.cgi?id=15335
- http://forum.dlang.org/post/xrrptwihnvlxabswn...@forum.dlang.org

--

[Issue 15371] __traits(getMember) should bypass the protection

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15371

--- Comment #1 from bb.t...@gmx.com ---
something like that:

https://github.com/Blumerline/dmd/commit/53419e71b93b0870574d93cbb83ebb7ccbb5e325

or maybe change in the Scope struct the module that indicates where the
template should be instantiated (since it function that contains traits code
will always be a template).

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15094

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #4 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5215

--

[Issue 15094] [REG2.063] __traits(getMember) fails when the source is a struct/class field

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15094

Kenji Hara  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #2 from Kenji Hara  ---
(In reply to Vladimir Panteleev from comment #1)
> This appears to be a regression.
> 
> Introduced in https://github.com/D-Programming-Language/dmd/pull/1687

Not correct. With 2.062, compiling example code with `dmd -c` will make:

test.d(16): Error: need 'this' to access member foo

PR 1687 had moved many "need this" errors in glue layer to front-end, but such
the field access is not yet supported. I think it's a reject-valid bug.

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15094

Vladimir Panteleev <thecybersha...@gmail.com> changed:

   What|Removed |Added

Summary|[REG2.063]  |__traits(getMember) fails
   |__traits(getMember) fails   |when the source is a
   |when the source is a|struct/class field
   |struct/class field  |

--- Comment #3 from Vladimir Panteleev <thecybersha...@gmail.com> ---
(In reply to Kenji Hara from comment #2)
> PR 1687 had moved many "need this" errors in glue layer to front-end, but
> such the field access is not yet supported. I think it's a reject-valid bug.

Oh, OK.

--

[Issue 15094] [REG2.063] __traits(getMember) fails when the source is a struct/class field

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15094

Vladimir Panteleev <thecybersha...@gmail.com> changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com
Summary|__traits(getMember) fails   |[REG2.063]
   |when the source is a    |__traits(getMember) fails
   |struct/class field  |when the source is a
   ||struct/class field

--- Comment #1 from Vladimir Panteleev <thecybersha...@gmail.com> ---
This appears to be a regression.

Introduced in https://github.com/D-Programming-Language/dmd/pull/1687

--

[Issue 15094] New: __traits(getMember) fails when the source is a struct/class field

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15094

  Issue ID: 15094
   Summary: __traits(getMember) fails when the source is a
struct/class field
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: initrd...@gmail.com

Attempting to use `__traits(getMember)` with a sub-struct/field fails with a
`need 'this'` error.

Example code:


import std.stdio;

struct Foo {
int i;
}

struct Bar {
Foo foo;
}

void main() {
Bar bar;
writeln(__traits(getMember, bar.foo, "i"));
}

Output:

$ rdmd ~/test.d
/home/col/test.d(14): Error: need 'this' for 'i' of type 'int'
Failed: ["dmd", "-v", "-o-", "/home/col/test.d", "-I/home/col"]

It's possible, but annoying, to work around this by storing a local pointer to
the field first.

auto foo = 
writeln(__traits(getMember, foo, "i"));

--

Re: __traits getMember is context sensetive?

[John Colvin via Digitalmars-d-learn]

On Sunday, 14 June 2015 at 09:46:56 UTC, JDemler wrote:

On Sunday, 14 June 2015 at 05:52:00 UTC, ketmar wrote:
oh, seems that i managed to make everything even less 
understandable...


Your code works perfectly and makes at least some sense to me. 
Thank you.


If i understand it correctly: __traits-time = 
templateinstatiation-time = pragma-time before ctfe-time?


Not really. These things are just (conceptually) done as/when 
they are required. If a template instantiation needs to do ctfe 
to calculate it's result, it does it. If some code running in 
ctfe needs the result of a template, it instantiates it.


The only distinction you have to think about is compile-time vs 
run-time, with the caveat that ctfe code is run as if it were 
run-time, but the result can be used at compile-time. If you 
imagine ctfe as being compiling the function, running it, 
getting the answer and copying it in to your code then even that 
distinction goes away and you just have ct vs rt.

Re: __traits getMember is context sensetive?

[anonymous via Digitalmars-d-learn]

On Sunday, 14 June 2015 at 10:10:51 UTC, ketmar wrote:
i.e. when it need a value in compile time. the interpreter is 
invoked, it evaluates (interprets) the given code (function or 
template instantiation), and then it returns result (or raises 
an error).


One important thing I didn't see stated clearly by anyone in here:

CTFE may run at compile time but it follows the same rules as run 
time evaluation (plus some restrictions).


This means, you can't use dynamic values (e.g. function 
parameters) in static contexts (e.g. __traits).


Example:

int f(int x)
{
if (__ctfe)
{
enum e = x; /* nope, not even during CTFE */
alias t = some_template!x; /* nope */
pragma(msg, x); /* nope */
}
return x;
}

enum result = f(1); /* CTFE-ing f */

Re: __traits getMember is context sensetive?

[ketmar via Digitalmars-d-learn]

On Sun, 14 Jun 2015 10:29:08 +, anonymous wrote:

 One important thing I didn't see stated clearly by anyone in here:
 
 CTFE may run at compile time but it follows the same rules as run time
 evaluation (plus some restrictions).
 
 This means, you can't use dynamic values (e.g. function parameters) in
 static contexts (e.g. __traits).

yes, i managed to write a wall of text escaping to talk about the main 
issue of the thread. ;-)

signature.asc
Description: PGP signature

Re: __traits getMember is context sensetive?

[ketmar via Digitalmars-d-learn]

On Sun, 14 Jun 2015 09:46:54 +, JDemler wrote:

 On Sunday, 14 June 2015 at 05:52:00 UTC, ketmar wrote:
 oh, seems that i managed to make everything even less understandable...
 
 Your code works perfectly and makes at least some sense to me.
 Thank you.
 
 If i understand it correctly: __traits-time = templateinstatiation-time
 = pragma-time before ctfe-time?

not quite right. there is no dedicated CTFE time. compiler triggers CTFE 
when it needs to, i.e. when it sees something like this:

  enum myval = myfunction(); // or mytemplate!(...)

i.e. when it need a value in compile time. the interpreter is invoked, it 
evaluates (interprets) the given code (function or template 
instantiation), and then it returns result (or raises an error).

so CTFE can occur at any stage of semantic analysis.

to be clear: compiler goes (roughly) thru this stages:

1. parsing and building AST.

2. semantic analysis.

3. generating code.

at the stage (1) only syntax is checked, and source is converted to 
internal representation (AST).

at the state (2) compiler tries to actually make sense of your code. it 
deducing types, checking type correctness and such. if it need to 
instantiate some template, it does that here. it does semantic for each 
function (note: not for templates or eponymous templates!), one by one.

and here compiler may step on something that needs CTFE. it invokes 
interpreter on this stage. so there is no dedicated CTFE time, compiler 
does it while it busy with semantic analysis, on demand. this way it 
avoids evaluating CTFE values that never used, which is good for compile 
speed. ;-)

pragmas and traits are executed by the very same CTFE engine, on demand 
too. i.e. when compiler hits pragma or traits during semantic analysis, 
compiler executes that.

overal semantic stage is more complex, of course, but i hope you get the 
idea.

signature.asc
Description: PGP signature

Re: __traits getMember is context sensetive?

[JDemler via Digitalmars-d-learn]

On Sunday, 14 June 2015 at 10:29:09 UTC, anonymous wrote:

On Sunday, 14 June 2015 at 10:10:51 UTC, ketmar wrote:
i.e. when it need a value in compile time. the interpreter is 
invoked, it evaluates (interprets) the given code (function or 
template instantiation), and then it returns result (or raises 
an error).


One important thing I didn't see stated clearly by anyone in 
here:


CTFE may run at compile time but it follows the same rules as 
run time evaluation (plus some restrictions).


This means, you can't use dynamic values (e.g. function 
parameters) in static contexts (e.g. __traits).


Example:

int f(int x)
{
if (__ctfe)
{
enum e = x; /* nope, not even during CTFE */
alias t = some_template!x; /* nope */
pragma(msg, x); /* nope */
}
return x;
}

enum result = f(1); /* CTFE-ing f */



So if i want to use parameters in a static context at compile 
time i have to pass them as template parameters?


That would explain my problems. Thanks

Re: __traits getMember is context sensetive?

[anonymous via Digitalmars-d-learn]

On Sunday, 14 June 2015 at 10:41:24 UTC, JDemler wrote:
So if i want to use parameters in a static context at compile 
time i have to pass them as template parameters?


Yes, template parameters are fine.

Re: __traits getMember is context sensetive?

[JDemler via Digitalmars-d-learn]

On Sunday, 14 June 2015 at 05:52:00 UTC, ketmar wrote:
oh, seems that i managed to make everything even less 
understandable...


Your code works perfectly and makes at least some sense to me. 
Thank you.


If i understand it correctly: __traits-time = 
templateinstatiation-time = pragma-time before ctfe-time?

Re: __traits getMember is context sensetive?

[JDemler via Digitalmars-d-learn]

On Sunday, 14 June 2015 at 10:04:35 UTC, John Colvin wrote:

On Sunday, 14 June 2015 at 09:46:56 UTC, JDemler wrote:

On Sunday, 14 June 2015 at 05:52:00 UTC, ketmar wrote:
oh, seems that i managed to make everything even less 
understandable...


Your code works perfectly and makes at least some sense to me. 
Thank you.


If i understand it correctly: __traits-time = 
templateinstatiation-time = pragma-time before ctfe-time?


Not really. These things are just (conceptually) done as/when 
they are required. If a template instantiation needs to do ctfe 
to calculate it's result, it does it. If some code running in 
ctfe needs the result of a template, it instantiates it.


The only distinction you have to think about is compile-time vs 
run-time, with the caveat that ctfe code is run as if it were 
run-time, but the result can be used at compile-time. If you 
imagine ctfe as being compiling the function, running it, 
getting the answer and copying it in to your code then even 
that distinction goes away and you just have ct vs rt.


If that is the case then i really do not get why my first example 
compiles and my second does not.


The compiler sees the pragma(msg, test(e)) and runs test(e).
If test uses __traits it does not work if it does not it works.

If __traits is just another ctfe function i dont see the 
difference.

Re: __traits getMember is context sensetive?

[John Colvin via Digitalmars-d-learn]

On Sunday, 14 June 2015 at 10:16:24 UTC, JDemler wrote:

On Sunday, 14 June 2015 at 10:04:35 UTC, John Colvin wrote:

[...]


If that is the case then i really do not get why my first 
example compiles and my second does not.


The compiler sees the pragma(msg, test(e)) and runs test(e).
If test uses __traits it does not work if it does not it works.

If __traits is just another ctfe function i dont see the 
difference.


An easy to remember rule: If it won't work at runtime, it won't 
work in ctfe.

Re: __traits getMember is context sensetive?

[JDemler via Digitalmars-d-learn]

I have another one :)

module test;

struct S{
  string member1;
  int member2;
}

string test(string[] a)
{
  const S s = { member1:It is also important to go to Mars!};
  const string y = a[0];
  return y;
}

void main()
{
  enum e = [member1,member2];
  pragma(msg, e[0]);
  pragma(msg, test(e));
}

Compiles, works fine while

module test;

struct S{
  string member1;
  int member2;
}

string test(string[] a)
{
  const S s = { member1:It is also important to go to Mars!};
  const string y = a[0];
  return __traits(getMember, s, y);
}

void main()
{
  enum e = [member1,member2];
  pragma(msg, e[0]);
  pragma(msg, test(e));
}

spits out following:

test.d(11): Error: variable a cannot be read at compile time
test.d(12):while evaluating y.init
test.d(12): Error: string expected as second argument of __traits 
getMember instead of __error
test.d(12): Error: cannot implicitly convert expression (false) 
of type bool to string

member1
test.d(19): Error: CTFE failed because of previous errors in test
test.d(19):while evaluating pragma(msg, test([member1, 
member2]))


If i use member1 directly it works.

What am I missing here?

Thanks for your help

Re: __traits getMember is context sensetive?

[ketmar via Digitalmars-d-learn]

oh, seems that i managed to make everything even less understandable...

signature.asc
Description: PGP signature