Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

[Alexis Murzeau]

Le 05/03/2020 à 00:03, Lisandro Damián Nicanor Pérez Meyer a écrit :
> Hi again.
> 
> On Wed, 4 Mar 2020 at 19:45, Alexis Murzeau <amubtdx at gmail.com> wrote:
>>
>> Le 04/03/2020 à 22:46, Lisandro Damián Nicanor Pérez Meyer a écrit :
>>> Hi!
>>>
>>> El mié., 4 mar. 2020 18:11, Alexis Murzeau <amubtdx at gmail.com> escribió:
>>>
>>>> Hi,
>>>>
>>>> I've a question about whether libclang1-X should depend on
>>>> libclang-common-X-dev to always have the clang's builtin headers
>>>> available when libclang is installed.
>>>>
>>>
>>> Definitely not. Headers should depend upon the library, not the other way
>>> around.
>>>
>>>>
>>>
>>
>> Why do you think that ?
> 
> Because development files should depend upon the libraries they
> provide the headers for, not the other way around. It's the basics of
> library packaging.

libclang-common-X-dev contains clang's builtin headers which are not the
same as libclang API headers.

clang's builtin headers are not the ones providing the API of libclang
but compiler builtin functions like _mm_sqrt_ps using clang's specific
functions like __builtin_ia32_sqrtps.

The package that contains libclang's API headers is libclang-X-dev, not
libclang-common-X-dev.

So to sum up, clang has:
 - libclang-X-dev: libclang's API headers containing functions available
in libclang to manipulate AST, compile code, ... (for example
ASTMutationListener.h, CompilerInstance.h, CXCompilationDatabase.h, ...)

 - libc++-X-dev: clang's libc++ standard library headers (for example
vector, unordered_map, ...)

 - libc6-dev: GNU C standard library headers (for example stdlib.h,
stdio.h, ...)

 - libclang-common-X-dev: clang's builtin headers (for example,
immintrin.h, stddef.h, x86intrin.h, ...)

And there is also libllvm API headers:
 - libllvm-X-dev: llvm's API headers (for example IRReader.h,
LinkTimeOptimizer.h, ...)

> 
> [snip]
>> If libclang1-X should not depend on libclang-common-X-dev, then users of
>> libclang1-X (like QtCreator, kdevelop, ...) that use libclang to compile
>> code from source should depend themselves on libclang-common-X-dev as it
>> is required for them to work correctly.
> 
> And then again, wrong. Making an IDE show the header a compiler is
> **NOT** using it's plain **WRONG**. I already expressed that in the
> bug upstream and in Qt Creator's bug. Note that I did even stress the
> question in upstream's bug just to show that nobody could say
> otherwise. Neither Marko nor Thiago denied that.

This may be wrong, but having parse errors because of issues like "fatal
error: 'stddef.h' file not found" is not better. It makes qtcreator's
code model to fail to parse code, which is one of the key feature of an
IDE like this.

It's better have the IDE use clang's builtin headers than not being able
to parse code because of missing builtin headers.

> 
> So if you want a fix make clang understand other compiler's headers,
> or provide a better code parser.


Currently, whatever if this is right or wrong, the only way to fix
"fatal error: 'stddef.h' file not found" when using qtcreator or
kdevelop on Debian is to install the appropriate libclang-common-X-dev.



The toolchain used to parse the code model for qtcreator and the
toolchain used to actually compile the code can be different, but that
doesn't matter because clang already provide the appropriate *builtin*
headers to make other compilers specific functions also available with
clang.

For example, gcc provides the non standard function _get_ssp available
from immintrin.h [0], clang also does provide it in cetintrin.h builtin
header which is included by its own immintrin.h builtin header.

MSVC provides _InterlockedCompareExchange_HLEAcquire function (which is
specific to MSVC as said in [1]), clang also provides it in the same
immintrin.h builtin header (even on linux, these builtin headers are in
libclang-common-X-dev package. Or maybe guarded with some #ifdef).


So while clang support other compilers specifics, it still needs to have
its matching *builtin* headers (which are mostly only intrinsics or
platform specific stuff) as builtin headers of each compilers are
probably highly specific to the compiler they are made for (which are
different from API headers or C and C++ standard library headers).



> 
> Regards, Lisandro.
> 
> 

[0]
https://gcc.gnu.org/onlinedocs/gcc/x86-control-flow-protection-intrinsics.html#x86-control-flow-protection-intrinsics
[1]
https://docs.microsoft.com/fr-fr/cpp/intrinsics/interlockedcompareexchange-intrinsic-functions?view=vs-2019


-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-llvm-team/attachments/20200305/96dd5b63/attachment-0001.sig>