Qt5/Mac header finding in KDevelop5 (clang parser??)

[Milian Wolff]

On Tuesday, June 21, 2016 2:02:46 PM CEST René J.V. Bertin wrote:
> On Tuesday June 21 2016 13:44:29 Milian Wolff wrote:
> > ^-- this is unrelated to the code snippet. It looks like an error while
> > parsing parsesession.cpp in the editor, no?
> 
> Yes. This whole thread is about parsing in the editor.

Yes, but first you say:

> I did a search on isystem over both kdevelop and kdevplatform, and saw this, 
in languages/clang/duchain/parsesession.cpp:
>     if (hasQtIncludes(includes.system)) {
<snip>
>     }
> 
> That seems like it might be related.
> 
> FWIW, even on Linux that file didn't get parse correctly initially, with I
> think the main culprit being the fact that <QList> isn't found:

What is "that file" here, the wrapped Qt header file in the code snippet you 
pasted? Note how "that file" would never show up in your editor. It may still 
trigger issues down the route in other headers, but the stuff you pasted is 
unrelated to "that file".

> > It's not an error inside the
> > wrapped Qt header itself (or I'm not seeing it).
> 
> I don't think so, no.

So how is the pasted code snippet related then?

> > > /opt/local/include/qt5/QtCore/qcompilerdetection.h:630:38: error: token
> > > is
> > > not a valid binary operator in a preprocessor subexpression
> > 
> > ^-- what is the contents of that line?
> 
>  623 /* C++11 features, see http://clang.llvm.org/cxx_status.html */
>  624 #  if __cplusplus >= 201103L || defined(__GXX_EXPERIMENTAL_CXX0X__)
>  625     /* Detect C++ features using __has_feature(), see
> http://clang.llvm.org/docs/LanguageExtensions.html#cxx11 */ 626 #    if
> __has_feature(cxx_alignas)
>  627 #      define Q_COMPILER_ALIGNAS
>  628 #      define Q_COMPILER_ALIGNOF
>  629 #    endif
>  630 #    if __has_feature(cxx_atomic) && __has_include(<atomic>)

Interesting, someone should investigate why our embedded clang is not capable 
of parsing this. I've never seen this myself.

>  631 #     define Q_COMPILER_ATOMICS
>  632 #    endif
>  633 #    if __has_feature(cxx_attributes)
>  634 #      define Q_COMPILER_ATTRIBUTES
>  635 #    endif
> 
> > ^-- you are using GCC on Mac? Bad idea, better use clang instead to get
> > the
> > system headers and include paths.
> 
> No, most certainly not;
> 
> > > /usr/lib/gcc/x86_64-linux-gnu/5/include/xmmintrin.h:777:28: error:
> > > cannot
> 
>                  ^^^^^^^^^^^^^^^^
> 
> That whole output snippet was on Linux.

OK, very confusing.

> > use clang instead to get the system headers and include paths.
> 
> Is that supposed to work? It doesn't for me, at least not for the headers
> from the system frameworks.

Again, confusing. Frameworks is a macOS thing, no? Please clarify what you 
mean here.

> And as a side-note, gcc is most likely capable to find those headers too;
> it's always been at least. You basically only get compatibility issues with
> g++, not gcc, because OS X uses libc++ instead of libstdc++. So as long as
> you manage not to mix libraries that use both runtimes you should be fine.
> That's enough of a gamble to avoid g++, of course (certain system SDKs are
> written in C++ or possibly ObjC++).

I don't understand what you want to say with this, so I'm ignoring it for now. 
If it is relevant to the discussions, please rephrase.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de