Review Request 121777: Make it possible to change language standard for the parser

[Sergey Kalinichev]

> On Jan. 2, 2015, 9:34 p.m., Nicolai Hähnle wrote:
> > This seems like a _very_ useful improvement, but the design rubs me the wrong way in several places, which can be summed up with the following observations:
> > 
> > 1. Different compilers support different standards.
> > 2. The standard which is in use is not a property of the _compiler_, but a property of _individual source files_ within a project.
> > 
> > Note how the code design is incompatible with these two observations in a number of important ways:
> > 
> > 1a. There is a globally hardcoded list/enum of standards even though not every compiler will support every standard. I would remove this list and instead add a method `QList<QString> ICompiler::supportedStandards() const`.
> > 
> > 1b. The list of standards changes; in fact, the list of standards is already out of date, since C++14 is a thing.
> > 
> > 2. ICompiler::setStandard() is really bad and dangerous design. SettingsManager::currentCompiler(...) will hand out pointers to a global set of compilers. So it is easily possible that two different projects (or two different parts of the same project!) that use different standards will end up holding pointers to the same ICompiler object, resulting in terrible confusion.
> >  
> > For example, note how the `GccLikeCompiler::defines()` implementation caches the result once it has been obtained, and subsequent changes to the standard will simply be ignored.
> > 
> > I suggest to eliminate `ICompiler::setStandard()`, and instead pass the standard as a parameter to `ICompiler::defines(const QString& standard)` and `ICompiler::includes(const QString& standard)`.
> > 
> > I see two possible alternatives:
> > 
> > 1. Create another class that is layered on top of ICompiler that plays the role of "compiler + standard", or
> > 2. Do away with the current approach entirely and make the standard a property of the ICompiler. In other words, instead of giving the user the choice of "GCC" or "Clang" or whatever compilers, give them a choice between "GCC C++03", "GCC C++11", "GCC C++14", "Clang C++03", etc. compilers. (Personally, I prefer this last alternative because it is the simplest in terms of code changes.)
> 
> Milian Wolff wrote:
>     Excellent review Nicolai, I couldn't say it any better. I also say we should simply add "GCC C++03" or similar "compilers". That is simple to implement code-wise and easy to grasp, UI-wise.

>1a. There is a globally hardcoded list/enum of standards even though not every compiler will support every standard. I would remove this list and instead add a method ICompiler::supportedStandards() const.

That's a valid point. I'll make it a virtual method then

>1b. The list of standards changes; in fact, the list of standards is already out of date, since C++14 is a thing.

That's true too. Still only recent versions of clang/gcc support it. So I thought it's too early to add it here. And yes I agree that we should query compiler for supported standards instead.
Any ideas how to make that? 
I saw: gcc -v --help. But seems like clang doesn't support that...
Also we could compile some file with different standards and see the result.

>SettingsManager::currentCompiler(...) will hand out pointers to a global set of compilers.

Indeed. Thanks for reminding that! I completely forgot about it.

>In other words, instead of giving the user the choice of "GCC" or "Clang" or whatever compilers, give them a choice between "GCC C++03", "GCC C++11", "GCC C++14", "Clang C++03", etc. compilers. (Personally, I prefer this last alternative because it is the simplest in terms of code changes.)

Yes, I think I'll do it that way. The only thing that troubles me is that it works well only if you have 2 compilers. But if you have 4-5 (gcc, clang, android-gcc, mingw, ...) there'll be like ~30 choises. That's not very good IMO. So I'm planning to make just 2 entries for each compiler, e,g,: "GCC c++11", "GCC c99" e.t.c. All other standards could be aded manually. What do you think?


BTW great review, thanks!


> On Jan. 2, 2015, 9:34 p.m., Nicolai Hähnle wrote:
> > languages/plugins/custom-definesandincludes/kcm_widget/projectpathswidget.cpp, lines 74-76
> > <https://git.reviewboard.kde.org/r/121777/diff/1/?file=337642#file337642line74>
> >
> >     As far as I can tell, this is the only "call-site" to ProjectPathsWidget::compilerChanged. I don't quite understand what the code is trying to do, but either this must stay, or compilerChanged must be removed as well.

I have no clue why I did that. Thanks again!


- Sergey


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121777/#review72974
-----------------------------------------------------------


On Jan. 1, 2015, 3:10 p.m., Sergey Kalinichev wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121777/
> -----------------------------------------------------------
> 
> (Updated Jan. 1, 2015, 3:10 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdevelop
> 
> 
> Description
> -------
> 
> Now we can choose different language standards for computing standard include directories/defined macros. 
> Also this feature is very useful for the kdev-clang plugin (Now it's possible to parse plain C projects).
> 
> 
> Diffs
> -----
> 
>   languages/plugins/custom-definesandincludes/kcm_widget/projectpathswidget.ui 3e413b3 
>   languages/plugins/custom-definesandincludes/compilerprovider/compilerprovider.cpp 3643e78 
>   languages/plugins/custom-definesandincludes/compilerprovider/gcclikecompiler.cpp bc99d8d 
>   languages/plugins/custom-definesandincludes/compilerprovider/icompiler.h 3627ebd 
>   languages/plugins/custom-definesandincludes/compilerprovider/icompiler.cpp 0bf6a44 
>   languages/plugins/custom-definesandincludes/compilerprovider/settingsmanager.cpp 229f456 
>   languages/plugins/custom-definesandincludes/kcm_widget/definesandincludesconfigpage.cpp 75f224d 
>   languages/plugins/custom-definesandincludes/kcm_widget/projectpathswidget.h 446ddb5 
>   languages/plugins/custom-definesandincludes/kcm_widget/projectpathswidget.cpp 5b34e75 
> 
> Diff: https://git.reviewboard.kde.org/r/121777/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Sergey Kalinichev
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150105/2fb3cb8f/attachment.html>