https://bugs.kde.org/show_bug.cgi?id=338649
--- Comment #10 from Patric Schmitz <bzk0...@aol.com> --- >> 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 It seems that clang itself has no means of parsing incomplete code fragments and will fail to produce a syntax tree at all if not all types and symbols can be resolved. This is at least what I get out of this post from Clang Developers: > http://clang-developers.42468.n3.nabble.com/Lenient-lexing-parsing-of-code-snippets-td4042786.html There is a GSoC 2014 project mentioned where someone has a similar requirement (for syntax highlighting). Maybe we could look into that, it seems a fuzzy parser has been developed for that project. However I assume we would end up with something comparable to what KDevelop has right now, and could probably also extend the current parser to account for 11/14. >> An alternative could be using some parser generator... > ... > 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] Probably the most reasonable way to go about it after all? > 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 ? Hmm in the case of constexpr I don't see why one would want to model this at all. It is a very specific C++ language feature after all and does not really have an equivalent in the UML standard, no? (I don't know either perfectly so I'm not entirely sure about this). -- You are receiving this mail because: You are watching all bug changes.
