[umbrello-devel] [umbrello] [Bug 338649] Extend C++ import for C++11

[Ralf Habacker via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=338649

--- Comment #9 from Ralf Habacker <ralf.habacker at freenet.de> ---
(In reply to Patric Schmitz from comment #8)
> On 01/03/2016 01:01 AM, Ralf Habacker via KDE Bugzilla wrote:
> > ...clang, which needs to be called similar to a compiler
> > building the related source code
> 
> I actually see this as a major problem. Requiring people to have a full
> build set up would severely limed the usefulness of the tool. I might not
> even have complete sourcetree available, but just get a bunch of related cpp
> files from "somewhere" (a collaborator, some old project which no longer
> builds, ...) and want to import the classes into umbrello.
This is the advantage of the recent parser :-)

>From recent observations at least all related classes should not be undefined.
Here is a simple example with llvm 3.7:
1. Variant
class QFont;
class Test {
public:
    Test(QFont *font) : m_font(font) {}
    QFont *m_font;
};

running  'clang-check test1.cpp -ast-dump  --' returns
TranslationUnitDecl 0xb75da0 <<invalid sloc>> <invalid sloc>
|-TypedefDecl 0xb762d8 <<invalid sloc>> <invalid sloc> implicit __int128_t
'__int128'
|-TypedefDecl 0xb76338 <<invalid sloc>> <invalid sloc> implicit __uint128_t
'unsigned __int128'
|-TypedefDecl 0xb76718 <<invalid sloc>> <invalid sloc> implicit
__builtin_va_list '__va_list_tag [1]'
|-CXXRecordDecl 0xb76768
</home/ralf/src/umbrello-master/unittests/test.cpp:2:1, col:7> col:7 referenced
class QFont
`-CXXRecordDecl 0xb76820 <line:4:1, line:10:1> line:4:7 class Test definition
  |-CXXRecordDecl 0xb76930 <col:1, col:7> col:7 implicit referenced class Test
  |-AccessSpecDecl 0xb769c0 <line:5:1, col:7> col:1 public
  |-CXXConstructorDecl 0xbc2060 <line:6:5, col:39> col:5 Test 'void (class
QFont *)'
  | |-ParmVarDecl 0xb76a28 <col:10, col:17> col:17 used font 'class QFont *'
  | |-CXXCtorInitializer Field 0xbc2138 'm_font' 'class QFont *'
  | | `-ImplicitCastExpr 0xbc2200 <col:32> 'class QFont *' <LValueToRValue>
  | |   `-DeclRefExpr 0xbc21a8 <col:32> 'class QFont *' lvalue ParmVar 0xb76a28
'font' 'class QFont *'
  | `-CompoundStmt 0xbc2248 <col:38, col:39>
  `-FieldDecl 0xbc2138 <line:8:5, col:12> col:12 m_font 'class QFont *'
-> no errors, complete AST

2. variant, using incomplete class QFont
class QFont;
class Test {
public:
    Test(const &QFont font) : m_font(font) {}
    QFont m_font; 
};

running  'clang-check test2.cpp -ast-dump  --' returns
TranslationUnitDecl 0x15afda0 <<invalid sloc>> <invalid sloc>
|-TypedefDecl 0x15b02d8 <<invalid sloc>> <invalid sloc> implicit __int128_t
'__int128'
|-TypedefDecl 0x15b0338 <<invalid sloc>> <invalid sloc> implicit __uint128_t
'unsigned __int128'
|-TypedefDecl 0x15b0718 <<invalid sloc>> <invalid sloc> implicit
__builtin_va_list '__va_list_tag [1]'
|-CXXRecordDecl 0x15b0768
</home/ralf/src/umbrello-master/unittests/test.cpp:2:1, col:7> col:7 referenced
class QFont
`-CXXRecordDecl 0x15b0820 <line:4:1, line:11:1> line:4:7 invalid class Test
definition
  |-CXXRecordDecl 0x15b0930 <col:1, col:7> col:7 implicit referenced class Test
  |-AccessSpecDecl 0x15b09c0 <line:5:1, col:7> col:1 public
  |-CXXConstructorDecl 0x15fc060 <line:6:5, col:45> col:5 invalid Test 'void
(const int &)'
  | |-ParmVarDecl 0x15b0a30 <col:10, col:17> col:17 used invalid QFont 'const
int &'
  | `-CompoundStmt 0x15fc618 <col:44, col:45>
  `-FieldDecl 0x15fc4c0 <line:9:5, col:11> col:11 invalid m_font 'class QFont'
> 4 errors generated, incomplete AST.

> If this is a basic limitation to using clang, is this really the way the project should go? 
> Maybe it is possible to separate only the parser parts without the whole semantics and error checking from clang? 
I don' know yet; it need to be evaluated
> An alternative could be using some parser generator such as antlr or bison
> to get a syntax tree? 
In theory yes, but ... 
> I looked around (for maybe half an hour) some weeks ago 
> but it seemed there is nothing yet which would properly parse c++11/14  syntax.
switching to such a generated parser requires refactoring (=new write) of the
parsed output to UML model mapping.

The third alternative is to extend the recent parser, which is not very
complicated. It has good debugging support (see category 'cppparser' in debug
dock window) . [1]

Beside the parser stuff there is the need to design how these features should
be mapped to the UML model. 
As an example there is the question how 'constexpr'
(https://en.wikipedia.org/wiki/C%2B%2B11#constexpr_.E2.80.93_Generalized_constant_expressions)
should be modeled ?  
Should it be modeled as stereotype 'constexpr', which requires only little
refactoring on cpp import/codegeneration (setup stereotype after creating
UMLOperation instance and write out 'constexpr' depending on presence of
'constexpr' stereotype) or as operation attribute similar to 'static', which
requires extending the class UMLOperation (setter/getter,xmi save/load,
property dialog). 

[1] According to the given example there it is only required to add a new lexer
token TOKEN_const_expr and to extend CppTree2Uml::parseFunctionDefinition() to
be able to setup the related UMLOperation instance.

My proposal for an implementation of this feature is 
1. Design how the related C+11 features at 
https://en.wikipedia.org/wiki/C%2B%2B11 should be modeled in umbrello
2. Implement the required changes in the UML model and properties dialogs
3. Create test cases from the code fragments at
https://en.wikipedia.org/wiki/C%2B%2B11 and extend the related lexer, parser 
and parser stuff.

-- 
You are receiving this mail because:
You are the assignee for the bug.