[cfe-dev] AST bug parsing tags.cpp file?
David Rector via cfe-dev
cfe-dev at lists.llvm.org
Thu Jul 30 07:31:41 PDT 2020
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 <billyaraujo at gmail.com> 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 <billyaraujo at gmail.com <mailto:billyaraujo at gmail.com>> 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 <davrecthreads at gmail.com <mailto:davrecthreads at gmail.com>> 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 <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> 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/ <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
>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200730/5fccf9dc/attachment-0001.html>
More information about the cfe-dev
mailing list