Review Request: Add "language features" to the C++ parser

[David Nolden]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104930/#review13782
-----------------------------------------------------------


I don't like the "language features" title too much, I think it's too vague and confusable. Wouldn't it be better to call it "language version"? Then, this could be added more generally into the framework, as it's useful for most languages. For example python will need it to distinguish between python-2 and python-3. I know that C is not an older version of C++, but this is how we model it in our language support.

Also, setting a project-global flag is not really scalable. For example, a project may contain both C and C++ code if it has some library copied into some sub-folder.

Therefore, I think the project-controller should be asked for the language, maybe like this: "QString version = projectController->languageVersionForUrl( url, ILanguage* language )". ILanguage again could supply a list of language-versions, which the project-manager would need to show somewhere in the UI to let the user pick, or could guess automatically.

- David Nolden


On May 13, 2012, 6:41 a.m., Alexandre Courbot wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104930/
> -----------------------------------------------------------
> 
> (Updated May 13, 2012, 6:41 a.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Description
> -------
> 
>    Currently the parser is a pure C++ parser with C++11 elements, without
>     any option to disable C++11 or to make it more C compatible. C
>     compatibility in particular is a big challenge since many C++ tokens can
>     be used as identifiers in C, and C also has some constructs that are not
>     valid in C++ (like designated initializers or casted braced init lists).
>     
>     This patch adds "language features" which are flags that enable specific
>     language support in the parser. Currently flags exist for C99, C++ and
>     C++11. Code that invokes the parser can use the new
>     setLanguageFeatures() method to change the current set of supported
>     features (the default is C++ | C++11). This is useful for instance for
>     C-specific projects.
>     
>     CppLanguageSupport::createParseJob has been modified to check for a
>     "Language" entry in the configuration of the project the parsed file
>     belongs to. Project controllers can set this option if they know that
>     the project is limited to C, C++ or C++11 files. Other means (for
>     instance, based on file extension of Makefile analysis) could be
>     implemented in the future.
> 
> 
> Diffs
> -----
> 
>   languages/cpp/cpplanguagesupport.cpp 4ee1ffe 
>   languages/cpp/cppparsejob.h debb1b0 
>   languages/cpp/cppparsejob.cpp 1e0a51b 
>   languages/cpp/parser/languagefeatures.h PRE-CREATION 
>   languages/cpp/parser/lexer.h 3494cbd 
>   languages/cpp/parser/lexer.cpp 81302d7 
>   languages/cpp/parser/parser.h c519891 
>   languages/cpp/parser/parser.cpp edeab85 
>   languages/cpp/parser/tests/test_parser.h dea9902 
>   languages/cpp/parser/tests/test_parser.cpp 804f379 
>   languages/cpp/preprocessjob.cpp 803c237 
> 
> Diff: http://git.reviewboard.kde.org/r/104930/diff/
> 
> 
> Testing
> -------
> 
> Modified kdev-kernel to set that "Language=C" option to the projects it manages. Checked that C++ keywords like "class", "private" were indeed treated as identifiers. This alone improves kernel parsing quality a great deal.
> 
> Made sure that parsing of C++ projects is not affected in any way by this patch.
> 
> 
> Thanks,
> 
> Alexandre Courbot
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120513/06002a4d/attachment.html>