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

Thu Jan 22 09:20:49 UTC 2015

> On Jan. 16, 2015, 2:40 a.m., Kevin Funk wrote:
> > I just briefly skimmed the patch. I think we need to overthink this completely:
> > 
> > What do we actually want?
> > - We'd like to be able to select the language standard for our *internal* parser.
> >   - This has nothing to do with binaries installed on the system
> >   - This has nothing to do with the specific compiler either (MSVC, GCC, ...)
> > 
> > Proposal:
> > - Add this setting to a language-specific settings page instead. I.e. a "C/C++/Obj" settings page
> >   - I already have multiple other ideas that I could add to this page afterwards
> >     (like making our auto-complete options configurable, for instance whether to add 'override' to a virtual function overload, etc.)
> > 
> > So in fact I'm proposing to move the "language standard" feature directly to kdev-clang instead. 
> > 
> > Opions?
> 
> Sergey Kalinichev wrote:
>     >Add this setting to a language-specific settings page instead. I.e. a "C/C++/Obj" settings page. So in fact I'm proposing to move the "language standard" feature directly to kdev-clang instead. 
>     
>     There are a couple of reasons, why it's IMO not very good:
>     a) There is no such page yet.
>     b) The oldcpp can use that standard feature too. Actually I've seen a bug report about not configurable include directories (i.e. c++11 only)
>     c) Even if we do that. Then we have to move compiler setting to that page too. Otherwise  it'd be inconvenient to select compiler on one page and standard on another. 
>     d) Also, is this "C/C++/Obj" settings page per project? If it's project wide, then ok, otherwise it won't work. As language standard can be set per project.
>     
>     So I'm suggesting to leave it as is. And give it more thinking when we finally get rid of oldcpp plugin.
> 
> Milian Wolff wrote:
>     a) the page can be created
>     b) oldcpp is not supporting different standards anyways, and will die sooner or later. so thats not an argument
>     c) this is a valid point we need to figure out how to handle
>     d) also true
>     
>     anyhow, any comments to what I said? simplifying it all by letting the user specify the command line?
> 
> Sergey Kalinichev wrote:
>     I don't know. Obviously not all users know what commands to pass. Also it's simple to misspell the options.
>     And I think that auto-detection feature still makes sense, as in most cases users want it to work out of the box without spending time on configuring compilers.
> 
> Kevin Funk wrote:
>     c) True. But right now the Compiler Settings page is confusing already. Adding more options doesn't make it better. The user doesn't know what he's configuring. Is he configuring the compiler used to built his project or the internal parser?
>     We need to design that UI carefully, as it's already starting to become confusing IMO.
>     d) Yes. I was thinking about making this project-specific.
>     
>     e) Now that this feature would be added to the IADM settings page => oldcpp would ignore that settings => confuses users as well.
>     
>     Honestly, I'm unsure how to handle all this, need to think about it more.
> 
> Sergey Kalinichev wrote:
>     >Adding more options doesn't make it better.
>     
>     Maybe, but it makes it more flexible. Actually this patch doesn't add additional options. Before you could choose: "gcc", "clang". Now: "gcc c99", "gcc c++11" e.t.c. That's the only difference.
>     
>      >The user doesn't know what he's configuring. Is he configuring the compiler used to built his project or the internal parser?
>     
>     Are there really such users? I mean, the page is called "Custom defines and includes". Also there is a text label explaining what it's for. How could anyone confuse it with a compiler used for building the project?
>     Actually it'd be great to use the same compiler for both (project building and parser), but it's not always possible.
>     
>     >Now that this feature would be added to the IADM settings page => oldcpp would ignore that settings => confuses users as well.
>     
>     I wouldn't say so. Yes, due to it bugs oldcpp can't parse all plain C projects. But this setting affects standard include directories/macros used by the oldcpp, so it doesn't ignore this feature.
> 
> Craig Tenenbaum wrote:
>     I think I may have some ideas about a potential compromise. I'm kind of motivated to see progress on this issue because I work with a codebase of mixed C++03, C++11, and C++14 code, where our leadership is unduly paranoid about simply building up our legacy, C++03 code segments to later specs. So, this can be kind of a perilous environment for really robust parsing/highlighting. Not to mention, I had been kind of cheating kdev-clang into properly parsing C++14 library features (language features like `decltype(auto)` and `auto`-return functions with no trailing specifier still don't work without proper C++14 support) by adding `__cplusplus 201403L` to the IADM, but this finally broke (as I always knew it would) with some of the recent performance enhancements to import processing.
>     
>     So, okay, the compromise: in CMake-based projects, KDevelop already (I believe) passes `CMAKE_EXPORT_COMPILE_COMMANDS=ON`, which generates a `compile_commands.json` file that can be used by Clang's CompilationDatabase functionality to automatically extract per-file/per-configuration compiler arguments. I think this would be the ideal way to handle this particular problem in the instances where a project is CMake-based and doesn't use a generator which doesn't support compilation databases (not all do, I'm under the distinct impression Ninja only just recently had this added; I'm on CMake 2.8.12.2 myself and I seem to be able to generate compilation databases with Ninja just fine).
>     
>     The above approach has the extreme benefit of making it possible for a mixed-standard project to be properly parsed and flagged for potential issues/errors in exactly the fashion as one would expect during compilation. Sadly, there are some downsides:
>     1. Not all generators yet support compilation databases, and projects not using CMake would still be kind of hung-up to dry, although, there exists a tool which may yet ameliorate this: [bear](https://github.com/rizsotto/Bear). Still not exactly clean or ideal, and who wants to add **more** dependencies?
>     2. I think that the biggest generator missing compilation databases is the native MSVC one, and bear is aimed squarely at *NIX.
>     3. Added complexity from the compilation database API itself: an individual source file can return multiple potential configurations depending on differences in compilation options in different targets.
>     4. I'm not sure if this breaks certain of the recent performance enhancements made to the IADM, and/or possibly exacerbates the `llvm::opt::Option::matches()` hot spot.
>     
>     Lastly, for "dumb" project managers, we may be forced to fall back on some kind of user-configurable parser database, much of the machinery for which could probably be wheedled in to the IADM seeing that it already supports the notion of per-file imports/defines. In fact, the two approaches, both the "smart" CMake-based approach and the basic, "dumb" approach need not necessarily be mutually exclusive: much as the current IADM machinery seems to now encode some basic information regarding the "quality" of the source of import/define information, this approach could probably be extended to do the same for parsing options and override or ignore information as necessary. Since I have no idea as to the scope of other major kdev-clang wishes, I'm not sure how this proposal might fit in with the overall vision for the plugin, but I think there's some serious merit to setting this issue apart from other, configurable functionality as this issue has a direct impact on usability and code correctness.
>     
>     I apologize in advance if this was longer or wordier than it should have been, or if it was inappropriate to discuss such a drastically different approach in this particular review.
> 
> Milian Wolff wrote:
>     @ Craig: For CMake yes, this would work. We actually use that already to find defines and include paths. But no other build tool I know of has this feature. So we still need a generic solution for that. And we cannot use the CompilationDatabase API from clang because of that :( Bear is certainly interesting, but won't work on Windows (not sure about Windows) (b/c it's using LD_PRELOAD).
> 
> Craig Tenenbaum wrote:
>     Yeah, for the most general case, it's still going to come down to basically letting the user specify the options to use. The way I had been thinking of it was, in addition to the imports and defines tabs in IADM, we might just add another tab to allow the user to pick from various language standards. Basically, your earlier suggestion would always be necessary in the most general case, that is, allowing the user to directly specify the parser options. Honestly, while the smart solution is ideal, being able to just specify the options manually would go a long way to resolving a significant source of daily frustration, for me.

I think that it's a good idea. Sadly, it's not cross-platform.

>allowing the user to directly specify the parser options.

We could definitely add an "additional options" section.
But I think that it'll only complicate things. Can't you pass additional options trough a script? I.e. add a new compiler in DAIM, and select there your script that invokes needed compiler with additional options.

>making it possible for a mixed-standard project to be properly parsed.

I think that it makes sense to have compiler/standard per project by default and also have an ability to set language standard for each file/folder individually. It shouldn't be so hard to implement. I'll try to do it.

- Sergey

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

On Jan. 19, 2015, 2:38 p.m., Sergey Kalinichev wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121777/
> -----------------------------------------------------------
> 
> (Updated Jan. 19, 2015, 2:38 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/compilerswidget.ui 0c90cee 
>   languages/plugins/custom-definesandincludes/kcm_widget/projectpathswidget.cpp 5b34e75 
>   languages/plugins/custom-definesandincludes/kcm_widget/projectpathswidget.ui 06a6c51 
>   languages/plugins/custom-definesandincludes/compilerprovider/msvccompiler.cpp fcd9db7 
>   languages/plugins/custom-definesandincludes/compilerprovider/settingsmanager.cpp 229f456 
>   languages/plugins/custom-definesandincludes/kcm_widget/compilerswidget.cpp aebbf5a 
>   languages/plugins/custom-definesandincludes/compilerprovider/compilerfactories.h 00042fb 
>   languages/plugins/custom-definesandincludes/compilerprovider/compilerfactories.cpp 8d47690 
>   languages/plugins/custom-definesandincludes/compilerprovider/compilerprovider.cpp 24d711d 
>   languages/plugins/custom-definesandincludes/compilerprovider/gcclikecompiler.h 079b78d 
>   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/icompilerfactory.h 3849bcb 
>   languages/plugins/custom-definesandincludes/compilerprovider/msvccompiler.h a59a6b7 
> 
> 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/20150122/823f3ad9/attachment-0001.html>