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

[Milian Wolff]

> On May 13, 2012, 2:57 p.m., David Nolden wrote:
> > 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.
> 
> Alexandre Courbot wrote:
>     Hi David,
>     
>     Working with "features" over "versions" makes more sense actually, because some of the features may apply to different versions of the languages (for instance, compiler flags that enable some construct that works with both C and C++). If we work with version, we are restraining ourselves to a linear progression of features, which is quite limiting. LLVM/CLang works with something similar to these "features", and that's for a good reason.
>     
>     I totally agree that using the project controller to get the list of supported features is the best idea. My project-global flag was mostly for testing purposes, I will try and adapt it to use the controller instead. But I really do think we should keep the features as they are.
> 
> Milian Wolff wrote:
>     I'm with Alexandre here - flags are simple to check and implement and by far more powerful.  But:
>     
>     The issue will lie in creating a useable interface/generalization for these actions such that they are useful for other plugins... people might "enable" different features for C++ while for other languages they can only pick between different versions (you cannot be both, python 2 and 3).
> 
> Alexandre Courbot wrote:
>     Does it need to be generalized to other plugins? Right now the implementation is 100% internal to the C++ plugin and it looks fine this way. Actually I would not even know which interface class should implement this generalization.

Personally I wouldn't say it's too bad if we first get a proper solution for c++ and then think about generalization if we find another language where it would be helpful. Not sure if Sven wants to support two different versions of Python, but I'm pretty sure that I don't want to keep backwards compatibility in PHP.


- Milian


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


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/20120528/cf4c9c86/attachment.html>