Clang has a very good C++ parser and AST generator. It is also up to date with all of the c++11 and c++14 standards. Using the clang tools will be more robust and easier to maintain. Reproducible: Always
Created attachment 101353 [details] ClassImport inheritance diagram
Created attachment 101354 [details] TreeParser inheritance
Created attachment 101355 [details] CodeImportWizard sequence
Attached are some diagrams. It looks we should extend the TreeParser and the ClassImport classes with Clang equivalents. Then in the wizard we can select which parser to use. I agree with you, Ralf. I am going to start by creating some test cases. Should I just do that in my fork and send pull requests? Also, your llvmparser test case looks like what we should use to traverse the Clang AST. Those classes look like a good starting point. Is there any place I can stick these diagrams? I am a big fan of diagrams and will keep creating them for my own understanding. I'll be happy to organize them somewhere for others as well. I don't mind writing some technical documentation. Do we need to create some new Jenkins jobs for qt5? I don't see them anywhere. Comments/questions always welcome.
(In reply to Shawn McKenney from comment #2) > Created attachment 101354 [details] > TreeParser inheritance From the testllvmparse unit test you can see that clang provides the template class RecursiveASTVisitor for exactly that purpose. See class FindNamedClassVisitor, which already uses a subset of the provided methods like bool VisitStmt(Stmt *s) bool VisitCXXRecordDecl(CXXRecordDecl *Declaration) this may change your proposed design in this area.
(In reply to Shawn McKenney from comment #1) > Created attachment 101353 [details] > ClassImport inheritance diagram This looks good
(In reply to Shawn McKenney from comment #3) > Created attachment 101355 [details] > CodeImportWizard sequence This sequence diagram shows the state in case clang support has been finished. Until clang support is finished it is required to provide clang cpp import as alternative way to not break the current (stable) way people may depends on. This can be archived for example by adding a checkbox in umbrello setting "Use clang based c++ import" or by providing additional (context) menu entries with dedicated clang import. The related menu entries are Sourcecode->Import from Directory, Sourcecode->Import Wizard and context menu of Logical view in the tree view.
(In reply to Shawn McKenney from comment #4) > Should I just do that in my fork and send pull requests? see https://community.kde.org/Infrastructure/Github_Mirror
clang-parser is geared towards compiling and requires visibility to the header files transitively #included (all the way to the system's header files). Umbrello's C++ parser does not have this constraint; it deals with incomplete sources.