AST bug parsing tags.cpp file?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

AST bug parsing tags.cpp file?

Keane, Erich via cfe-dev
Hi,

On project opentoonz there is a file called:
opentoonz/toonz/sources/image/pli/tags.cp

If I run clang-check, the AST it builds seems wrong.

clang-check -ast-dump /home/opentoonz/toonz/sources/image/pli/tags.cpp | grep -B 1 -A 1 "~ColorTag"

    |-CXXMemberCallExpr 0x22893e8 <line:253:1, col:21> 'void'
    | `-MemberExpr 0x22893a0 <col:1, col:12> '<bound member function type>' ->~ColorTag 0x2274c00
    |   `-CXXThisExpr 0x2289390 <col:11> 'ColorTag *' implicit this

Line 253 appears as a CXXMemberCallExpr instead of a CXXDestructorDecl.

So the AST thinks it is calling an explicit destructor method call although it is a destructor implementation.

clang-check --version
LLVM (http://llvm.org/):
  LLVM version 10.0.0
 
  Optimized build.
  Default target: x86_64-pc-linux-gnu
  Host CPU: nehalem

Is this a bug or am I missing something?

Regards,

Billy.


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: AST bug parsing tags.cpp file?

Keane, Erich via cfe-dev
I think you are not distinguishing properly between the declaration of the destructor and its usage (via a CXXMemberCallExpr) within the implementation/"body" of some other method declaration (this body should be enclosed in a "CompoundStmt"). 

For example, the dump of 

```
struct ColorTag {
  ~ColorTag() {}
  void destroy() {
    ColorTag::~ColorTag();
  }
};
```

looks like this:

```
TranslationUnitDecl
`-CXXRecordDecl <line:1:1, line:5:1> line:1:8 struct ColorTag definition
  ...(Definition data, implicitly-generated declarations)...
  |-CXXDestructorDecl <line:2:5, col:18> col:5 used ~ColorTag 'void () noexcept'
  |-CXXMethodDecl <line:2:5, line:4:5> line:2:10 destroy 'void ()'
  | `-CompoundStmt <col:20, line:4:5>
  |   `-CXXMemberCallExpr <line:3:9, col:29> 'void'
  |     `-MemberExpr <col:9, col:20> '<bound member function type>' ->~ColorTag 0x55790cbbaa40
  |       `-CXXThisExpr <col:19> 'ColorTag *' implicit this
  ...
```

Hope that helps, good luck,

Dave

On Jul 29, 2020, at 10:40 AM, Billy Araujo via cfe-dev <[hidden email]> wrote:

Hi,

On project opentoonz there is a file called:
opentoonz/toonz/sources/image/pli/tags.cp

If I run clang-check, the AST it builds seems wrong.

clang-check -ast-dump /home/opentoonz/toonz/sources/image/pli/tags.cpp | grep -B 1 -A 1 "~ColorTag"

    |-CXXMemberCallExpr 0x22893e8 <line:253:1, col:21> 'void'
    | `-MemberExpr 0x22893a0 <col:1, col:12> '<bound member function type>' ->~ColorTag 0x2274c00
    |   `-CXXThisExpr 0x2289390 <col:11> 'ColorTag *' implicit this

Line 253 appears as a CXXMemberCallExpr instead of a CXXDestructorDecl.

So the AST thinks it is calling an explicit destructor method call although it is a destructor implementation.

clang-check --version
LLVM (http://llvm.org/):
  LLVM version 10.0.0
 
  Optimized build.
  Default target: x86_64-pc-linux-gnu
  Host CPU: nehalem

Is this a bug or am I missing something?

Regards,

Billy.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: AST bug parsing tags.cpp file?

Keane, Erich via cfe-dev
Hi Dave,

Thanks for your reply. I don't think it is a cxxMemberCallExpr().
I think it is parsing issue because this is what happens:

class ColorTag()
{
public:
   ColorTag():
   ~ColorTag();
}

ColorTag()::ColorTag() {
  //...
}

ColorTag::~ColorTag() {}

It is interpreted as: CXXMemberCallExpr() as if ColorTag::~ColorTag() was called inside the constructor. You can see below in the AST output cxxMemberCallExpr parent is CXXConstructorDecl.

`-CXXConstructorDecl 0x2e76988 parent 0x2e60608 prev 0x2e61578 <line:238:1, line:434:2> line:238:11 ColorTag 'void (const ColorTag &)'
  |-ParmVarDecl 0x2e768f8 <col:20, col:36> col:36 used tag 'const ColorTag &'
  |-CXXCtorInitializer 'PliObjectTag'
  | `-CXXConstructExpr 0x2e76b10 <line:239:7, col:39> 'PliObjectTag' 'void (const PliTag::Type)'
  |   `-DeclRefExpr 0x2e76ab0 <col:20, col:28> 'PliTag::Type' EnumConstant 0x2e579e8 'COLOR_NGOBJ' 'PliTag::Type'
  |-CXXCtorInitializer Field 0x2e60e88 'm_style' 'ColorTag::styleType'
  | `-ImplicitCastExpr 0x2e76bd8 <line:240:15, col:19> 'ColorTag::styleType' <LValueToRValue>
  |   `-MemberExpr 0x2e76b88 <col:15, col:19> 'const ColorTag::styleType' lvalue .m_style 0x2e60e88
  |     `-DeclRefExpr 0x2e76b68 <col:15> 'const ColorTag' lvalue ParmVar 0x2e768f8 'tag' 'const ColorTag &'
  |-CXXCtorInitializer Field 0x2e60ee8 'm_attribute' 'ColorTag::attributeType'
  | `-ImplicitCastExpr 0x2e76c88 <line:241:19, col:23> 'ColorTag::attributeType' <LValueToRValue>
  |   `-MemberExpr 0x2e76c38 <col:19, col:23> 'const ColorTag::attributeType' lvalue .m_attribute 0x2e60ee8
  |     `-DeclRefExpr 0x2e76c18 <col:19> 'const ColorTag' lvalue ParmVar 0x2e768f8 'tag' 'const ColorTag &'
  `-CompoundStmt 0x2e76fb0 <line:242:36, line:434:2>
    |-IfStmt 0x2e76d98 <line:243:3, line:249:1>
    | |-OpaqueValueExpr 0x2e76d80 <<invalid sloc>> 'bool'
    | `-CompoundStmt 0x2e76d70 <line:243:28, line:249:1>
    |-CXXMemberCallExpr 0x2e76e68 <line:251:1, col:21> 'void'
    | `-MemberExpr 0x2e76e20 <col:1, col:12> '<bound member function type>' ->~ColorTag 0x2e61670
    |   `-CXXThisExpr 0x2e76e10 <col:11> 'ColorTag *' implicit this

So this:

class ColorTag()
{
public:
   ColorTag():
   ~ColorTag();
}

ColorTag()::ColorTag() {
  //...
}

ColorTag::~ColorTag() {}

Is interpreted like this:

class ColorTag()
{
public:
   ColorTag():
   ~ColorTag();
}

ColorTag()::ColorTag() {
  //...
 ColorTag::~ColorTag() {}
}

Regards,

Billy.




On Thu, Jul 30, 2020 at 1:27 AM David Rector <[hidden email]> wrote:
I think you are not distinguishing properly between the declaration of the destructor and its usage (via a CXXMemberCallExpr) within the implementation/"body" of some other method declaration (this body should be enclosed in a "CompoundStmt"). 

For example, the dump of 

```
struct ColorTag {
  ~ColorTag() {}
  void destroy() {
    ColorTag::~ColorTag();
  }
};
```

looks like this:

```
TranslationUnitDecl
`-CXXRecordDecl <line:1:1, line:5:1> line:1:8 struct ColorTag definition
  ...(Definition data, implicitly-generated declarations)...
  |-CXXDestructorDecl <line:2:5, col:18> col:5 used ~ColorTag 'void () noexcept'
  |-CXXMethodDecl <line:2:5, line:4:5> line:2:10 destroy 'void ()'
  | `-CompoundStmt <col:20, line:4:5>
  |   `-CXXMemberCallExpr <line:3:9, col:29> 'void'
  |     `-MemberExpr <col:9, col:20> '<bound member function type>' ->~ColorTag 0x55790cbbaa40
  |       `-CXXThisExpr <col:19> 'ColorTag *' implicit this
  ...
```

Hope that helps, good luck,

Dave

On Jul 29, 2020, at 10:40 AM, Billy Araujo via cfe-dev <[hidden email]> wrote:

Hi,

On project opentoonz there is a file called:
opentoonz/toonz/sources/image/pli/tags.cp

If I run clang-check, the AST it builds seems wrong.

clang-check -ast-dump /home/opentoonz/toonz/sources/image/pli/tags.cpp | grep -B 1 -A 1 "~ColorTag"

    |-CXXMemberCallExpr 0x22893e8 <line:253:1, col:21> 'void'
    | `-MemberExpr 0x22893a0 <col:1, col:12> '<bound member function type>' ->~ColorTag 0x2274c00
    |   `-CXXThisExpr 0x2289390 <col:11> 'ColorTag *' implicit this

Line 253 appears as a CXXMemberCallExpr instead of a CXXDestructorDecl.

So the AST thinks it is calling an explicit destructor method call although it is a destructor implementation.

clang-check --version
LLVM (http://llvm.org/):
  LLVM version 10.0.0
 
  Optimized build.
  Default target: x86_64-pc-linux-gnu
  Host CPU: nehalem

Is this a bug or am I missing something?

Regards,

Billy.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: AST bug parsing tags.cpp file?

Keane, Erich via cfe-dev
Hi,

Also something else happens if you move
ColorTag::~ColorTag() {}

down to be at line 261 (without changing scope) is now a CXXDestructorDecl but the line numbers are all screwed up.

CXXDestructorDecl 0x269fdc0 <line:307:3, col:13> col:3 ~ColorTag 'void () noexcept'

Regards,

Billy.




On Thu, Jul 30, 2020 at 11:54 AM Billy Araujo <[hidden email]> wrote:
Hi Dave,

Thanks for your reply. I don't think it is a cxxMemberCallExpr().
I think it is parsing issue because this is what happens:

class ColorTag()
{
public:
   ColorTag():
   ~ColorTag();
}

ColorTag()::ColorTag() {
  //...
}

ColorTag::~ColorTag() {}

It is interpreted as: CXXMemberCallExpr() as if ColorTag::~ColorTag() was called inside the constructor. You can see below in the AST output cxxMemberCallExpr parent is CXXConstructorDecl.

`-CXXConstructorDecl 0x2e76988 parent 0x2e60608 prev 0x2e61578 <line:238:1, line:434:2> line:238:11 ColorTag 'void (const ColorTag &)'
  |-ParmVarDecl 0x2e768f8 <col:20, col:36> col:36 used tag 'const ColorTag &'
  |-CXXCtorInitializer 'PliObjectTag'
  | `-CXXConstructExpr 0x2e76b10 <line:239:7, col:39> 'PliObjectTag' 'void (const PliTag::Type)'
  |   `-DeclRefExpr 0x2e76ab0 <col:20, col:28> 'PliTag::Type' EnumConstant 0x2e579e8 'COLOR_NGOBJ' 'PliTag::Type'
  |-CXXCtorInitializer Field 0x2e60e88 'm_style' 'ColorTag::styleType'
  | `-ImplicitCastExpr 0x2e76bd8 <line:240:15, col:19> 'ColorTag::styleType' <LValueToRValue>
  |   `-MemberExpr 0x2e76b88 <col:15, col:19> 'const ColorTag::styleType' lvalue .m_style 0x2e60e88
  |     `-DeclRefExpr 0x2e76b68 <col:15> 'const ColorTag' lvalue ParmVar 0x2e768f8 'tag' 'const ColorTag &'
  |-CXXCtorInitializer Field 0x2e60ee8 'm_attribute' 'ColorTag::attributeType'
  | `-ImplicitCastExpr 0x2e76c88 <line:241:19, col:23> 'ColorTag::attributeType' <LValueToRValue>
  |   `-MemberExpr 0x2e76c38 <col:19, col:23> 'const ColorTag::attributeType' lvalue .m_attribute 0x2e60ee8
  |     `-DeclRefExpr 0x2e76c18 <col:19> 'const ColorTag' lvalue ParmVar 0x2e768f8 'tag' 'const ColorTag &'
  `-CompoundStmt 0x2e76fb0 <line:242:36, line:434:2>
    |-IfStmt 0x2e76d98 <line:243:3, line:249:1>
    | |-OpaqueValueExpr 0x2e76d80 <<invalid sloc>> 'bool'
    | `-CompoundStmt 0x2e76d70 <line:243:28, line:249:1>
    |-CXXMemberCallExpr 0x2e76e68 <line:251:1, col:21> 'void'
    | `-MemberExpr 0x2e76e20 <col:1, col:12> '<bound member function type>' ->~ColorTag 0x2e61670
    |   `-CXXThisExpr 0x2e76e10 <col:11> 'ColorTag *' implicit this

So this:

class ColorTag()
{
public:
   ColorTag():
   ~ColorTag();
}

ColorTag()::ColorTag() {
  //...
}

ColorTag::~ColorTag() {}

Is interpreted like this:

class ColorTag()
{
public:
   ColorTag():
   ~ColorTag();
}

ColorTag()::ColorTag() {
  //...
 ColorTag::~ColorTag() {}
}

Regards,

Billy.




On Thu, Jul 30, 2020 at 1:27 AM David Rector <[hidden email]> wrote:
I think you are not distinguishing properly between the declaration of the destructor and its usage (via a CXXMemberCallExpr) within the implementation/"body" of some other method declaration (this body should be enclosed in a "CompoundStmt"). 

For example, the dump of 

```
struct ColorTag {
  ~ColorTag() {}
  void destroy() {
    ColorTag::~ColorTag();
  }
};
```

looks like this:

```
TranslationUnitDecl
`-CXXRecordDecl <line:1:1, line:5:1> line:1:8 struct ColorTag definition
  ...(Definition data, implicitly-generated declarations)...
  |-CXXDestructorDecl <line:2:5, col:18> col:5 used ~ColorTag 'void () noexcept'
  |-CXXMethodDecl <line:2:5, line:4:5> line:2:10 destroy 'void ()'
  | `-CompoundStmt <col:20, line:4:5>
  |   `-CXXMemberCallExpr <line:3:9, col:29> 'void'
  |     `-MemberExpr <col:9, col:20> '<bound member function type>' ->~ColorTag 0x55790cbbaa40
  |       `-CXXThisExpr <col:19> 'ColorTag *' implicit this
  ...
```

Hope that helps, good luck,

Dave

On Jul 29, 2020, at 10:40 AM, Billy Araujo via cfe-dev <[hidden email]> wrote:

Hi,

On project opentoonz there is a file called:
opentoonz/toonz/sources/image/pli/tags.cp

If I run clang-check, the AST it builds seems wrong.

clang-check -ast-dump /home/opentoonz/toonz/sources/image/pli/tags.cpp | grep -B 1 -A 1 "~ColorTag"

    |-CXXMemberCallExpr 0x22893e8 <line:253:1, col:21> 'void'
    | `-MemberExpr 0x22893a0 <col:1, col:12> '<bound member function type>' ->~ColorTag 0x2274c00
    |   `-CXXThisExpr 0x2289390 <col:11> 'ColorTag *' implicit this

Line 253 appears as a CXXMemberCallExpr instead of a CXXDestructorDecl.

So the AST thinks it is calling an explicit destructor method call although it is a destructor implementation.

clang-check --version
LLVM (http://llvm.org/):
  LLVM version 10.0.0
 
  Optimized build.
  Default target: x86_64-pc-linux-gnu
  Host CPU: nehalem

Is this a bug or am I missing something?

Regards,

Billy.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: AST bug parsing tags.cpp file?

Keane, Erich via cfe-dev
If you’re still having an issue, can you provide a link to the actual code generating that dump?  I’m not sure what those line numbers refer into.

From your dump it seems as if you called the destructor explicitly in the constructor body for some reason.  Perhaps what was intended to be a destructor declaration instead made it into constructor body, due to a misplaced closing brace, thus appearing as a destructor call?  Maybe caused by macro wizardry gone awry?  Hard to say for sure without seeing the original code.

The reduced code you reference below dumps as expected for me; there is no CXXMemberCallExpr anywhere.  Specifically:

```
class ColorTag {
public:
  ColorTag();
  ~ColorTag();
};
ColorTag::ColorTag() {
  //...
}
ColorTag::~ColorTag() {}
```

dumps to:

```
TranslationUnitDecl
|-CXXRecordDecl <line:2:1, line:7:1> line:2:7 class ColorTag definition
| |-DefinitionData empty standard_layout has_user_declared_ctor can_const_default_init
| | |-DefaultConstructor exists non_trivial user_provided defaulted_is_constexpr
| | |-CopyConstructor simple trivial has_const_param implicit_has_const_param
| | |-MoveConstructor
| | |-CopyAssignment trivial has_const_param needs_implicit implicit_has_const_param
| | |-MoveAssignment
| | `-Destructor non_trivial user_declared
| |-CXXRecordDecl <col:1, col:7> col:7 implicit referenced class ColorTag
| |-AccessSpecDecl <line:4:1, col:7> col:1 public
| |-CXXConstructorDecl <line:5:4, col:13> col:4 ColorTag 'void ()'
| |-CXXDestructorDecl <line:6:4, col:14> col:4 ~ColorTag 'void () noexcept'
| `-CXXConstructorDecl <line:2:7> col:7 implicit constexpr ColorTag 'void (const ColorTag &)' inline default trivial noexcept-unevaluated 0x557709f2c028
| `-ParmVarDecl <col:7> col:7 'const ColorTag &'
|-CXXConstructorDecl parent 0x557709f2bb70 prev 0x557709f2bdc8 <line:9:1, line:11:1> line:9:11 ColorTag 'void ()'
| `-CompoundStmt <col:22, line:11:1>
`-CXXDestructorDecl parent 0x557709f2bb70 prev 0x557709f2beb8 <line:13:1, col:24> col:11 ~ColorTag 'void () noexcept'
`-CompoundStmt <col:23, col:24>
```


On Jul 30, 2020, at 7:02 AM, Billy Araujo <[hidden email]> wrote:

Hi,

Also something else happens if you move
ColorTag::~ColorTag() {}

down to be at line 261 (without changing scope) is now a CXXDestructorDecl but the line numbers are all screwed up.

CXXDestructorDecl 0x269fdc0 <line:307:3, col:13> col:3 ~ColorTag 'void () noexcept'

Regards,

Billy.




On Thu, Jul 30, 2020 at 11:54 AM Billy Araujo <[hidden email]> wrote:
Hi Dave,

Thanks for your reply. I don't think it is a cxxMemberCallExpr().
I think it is parsing issue because this is what happens:

class ColorTag()
{
public:
   ColorTag():
   ~ColorTag();
}

ColorTag()::ColorTag() {
  //...
}

ColorTag::~ColorTag() {}

It is interpreted as: CXXMemberCallExpr() as if ColorTag::~ColorTag() was called inside the constructor. You can see below in the AST output cxxMemberCallExpr parent is CXXConstructorDecl.

`-CXXConstructorDecl 0x2e76988 parent 0x2e60608 prev 0x2e61578 <line:238:1, line:434:2> line:238:11 ColorTag 'void (const ColorTag &)'
  |-ParmVarDecl 0x2e768f8 <col:20, col:36> col:36 used tag 'const ColorTag &'
  |-CXXCtorInitializer 'PliObjectTag'
  | `-CXXConstructExpr 0x2e76b10 <line:239:7, col:39> 'PliObjectTag' 'void (const PliTag::Type)'
  |   `-DeclRefExpr 0x2e76ab0 <col:20, col:28> 'PliTag::Type' EnumConstant 0x2e579e8 'COLOR_NGOBJ' 'PliTag::Type'
  |-CXXCtorInitializer Field 0x2e60e88 'm_style' 'ColorTag::styleType'
  | `-ImplicitCastExpr 0x2e76bd8 <line:240:15, col:19> 'ColorTag::styleType' <LValueToRValue>
  |   `-MemberExpr 0x2e76b88 <col:15, col:19> 'const ColorTag::styleType' lvalue .m_style 0x2e60e88
  |     `-DeclRefExpr 0x2e76b68 <col:15> 'const ColorTag' lvalue ParmVar 0x2e768f8 'tag' 'const ColorTag &'
  |-CXXCtorInitializer Field 0x2e60ee8 'm_attribute' 'ColorTag::attributeType'
  | `-ImplicitCastExpr 0x2e76c88 <line:241:19, col:23> 'ColorTag::attributeType' <LValueToRValue>
  |   `-MemberExpr 0x2e76c38 <col:19, col:23> 'const ColorTag::attributeType' lvalue .m_attribute 0x2e60ee8
  |     `-DeclRefExpr 0x2e76c18 <col:19> 'const ColorTag' lvalue ParmVar 0x2e768f8 'tag' 'const ColorTag &'
  `-CompoundStmt 0x2e76fb0 <line:242:36, line:434:2>
    |-IfStmt 0x2e76d98 <line:243:3, line:249:1>
    | |-OpaqueValueExpr 0x2e76d80 <<invalid sloc>> 'bool'
    | `-CompoundStmt 0x2e76d70 <line:243:28, line:249:1>
    |-CXXMemberCallExpr 0x2e76e68 <line:251:1, col:21> 'void'
    | `-MemberExpr 0x2e76e20 <col:1, col:12> '<bound member function type>' ->~ColorTag 0x2e61670
    |   `-CXXThisExpr 0x2e76e10 <col:11> 'ColorTag *' implicit this

So this:

class ColorTag()
{
public:
   ColorTag():
   ~ColorTag();
}

ColorTag()::ColorTag() {
  //...
}

ColorTag::~ColorTag() {}

Is interpreted like this:

class ColorTag()
{
public:
   ColorTag():
   ~ColorTag();
}

ColorTag()::ColorTag() {
  //...
 ColorTag::~ColorTag() {}
}

Regards,

Billy.




On Thu, Jul 30, 2020 at 1:27 AM David Rector <[hidden email]> wrote:
I think you are not distinguishing properly between the declaration of the destructor and its usage (via a CXXMemberCallExpr) within the implementation/"body" of some other method declaration (this body should be enclosed in a "CompoundStmt"). 

For example, the dump of 

```
struct ColorTag {
  ~ColorTag() {}
  void destroy() {
    ColorTag::~ColorTag();
  }
};
```

looks like this:

```
TranslationUnitDecl
`-CXXRecordDecl <line:1:1, line:5:1> line:1:8 struct ColorTag definition
  ...(Definition data, implicitly-generated declarations)...
  |-CXXDestructorDecl <line:2:5, col:18> col:5 used ~ColorTag 'void () noexcept'
  |-CXXMethodDecl <line:2:5, line:4:5> line:2:10 destroy 'void ()'
  | `-CompoundStmt <col:20, line:4:5>
  |   `-CXXMemberCallExpr <line:3:9, col:29> 'void'
  |     `-MemberExpr <col:9, col:20> '<bound member function type>' ->~ColorTag 0x55790cbbaa40
  |       `-CXXThisExpr <col:19> 'ColorTag *' implicit this
  ...
```

Hope that helps, good luck,

Dave

On Jul 29, 2020, at 10:40 AM, Billy Araujo via cfe-dev <[hidden email]> wrote:

Hi,

On project opentoonz there is a file called:
opentoonz/toonz/sources/image/pli/tags.cp

If I run clang-check, the AST it builds seems wrong.

clang-check -ast-dump /home/opentoonz/toonz/sources/image/pli/tags.cpp | grep -B 1 -A 1 "~ColorTag"

    |-CXXMemberCallExpr 0x22893e8 <line:253:1, col:21> 'void'
    | `-MemberExpr 0x22893a0 <col:1, col:12> '<bound member function type>' ->~ColorTag 0x2274c00
    |   `-CXXThisExpr 0x2289390 <col:11> 'ColorTag *' implicit this

Line 253 appears as a CXXMemberCallExpr instead of a CXXDestructorDecl.

So the AST thinks it is calling an explicit destructor method call although it is a destructor implementation.

clang-check --version
LLVM (http://llvm.org/):
  LLVM version 10.0.0
 
  Optimized build.
  Default target: x86_64-pc-linux-gnu
  Host CPU: nehalem

Is this a bug or am I missing something?

Regards,

Billy.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev