D5491: Improve detection of builtin defines from compiler command

[Aaron Puchert]

aaronpuchert added inline comments.

INLINE COMMENTS

> gcclikecompiler.cpp:45
>  
> -QStringList languageOptions(const QString& arguments)
> +QStringList languageOptions(const QStringList& arguments)
>  {

This function is pretty complex and full of hacks, even before this change. But what bothers me most: why do we try to guess the language here?

As far as I can see, it's only used in `GccLikeCompiler::defines` and `GccLikeCompiler::includes`, which are used in `CompilerProvider::defines` and `CompilerProvider::includes`, respectively. But there we know the language (it's just `languageType`), so why do we try to detect it again?

I think this can be made a lot easier by redesigning some of the methods a bit.

> gcclikecompiler.cpp:63
> +                language = minusXCL();
> +            } else if (standardVersion.startsWith(QLatin1String("cuda"))) {
> +                language = minusXCuda();

There is no standard beginning with `cuda`, as far as I know. (See the Clang documentation <http://clang.llvm.org/docs/UsersManual.html#differences-between-various-standard-modes>.) It seems that Cuda just uses the already known C and C++ standards, if we are to believe the comments in D5210: Proper CUDA handling <https://phabricator.kde.org/D5210>. I don't think we can detect Cuda from the arguments, but I also think we don't need to. (See my other comment.)

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D5491

To: arichardson, #kdevelop, kfunk, mwolff
Cc: skalinichev, aaronpuchert, kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20170813/14f0bf08/attachment.html>