Community
Participate
Working Groups
GCC implements C++11 type traits metafunctions like std::is_pod using corresponding compiler intrinsics like __is_pod. In order for CDT to correctly index code using these type traits metafunctions, it needs to be able to recognize and evaluate these instrinsics. Here is an example of code that currently gives a false positive error: template <bool> struct foo {}; template <> struct foo<true> { typedef int type; }; typedef foo<__is_pod(int)>::type t; // ERROR HERE (Here I unwrapped the use of std::is_pod and used the intrinsic directly, but the error is the same if you use std::is_pod). The error is: "Type 'foo<__is_pod(int)>::type' could not be resolved" (because CDT does not realize that __is_pod(int) evaluates to true, and so looks in the main template 'foo' rather than the specialization 'foo<true>', and the main template does not have a 'type' member). I have already reported bug 367993 for a more complex use case that also needs support for dependent expressions; however, simple use cases like the above don't need support for dependent expressions. Here is a list of type traits intrinsics used by GCC as of version 4.7: __is_pod __is_trivial __is_standard_layout __is_literal_type __is_enum __is_union __is_class __is_empty __is_polymorphic __is_abstract __is_base_of __has_trivial_constructor __has_trivial_copy __has_trivial_assign __has_trivial_destructor __has_nothrow_constructor __has_nothrow_copy __has_nothrow_assign __has_virtual_destructor (I assume it would be a bit of overkill to file a bug for each one...)
I should mention that the specifications for the type traits that these intrinsics implement can be found in the C++11 standard, sections 20.9.4 and 20.9.6.
The intrinsics are supported by CDT (bug 342683), however the evaluation of such expressions is not implemented.
Using CDT-9.4 (Oxygen.2rc2), it looks like the original issue from comment #0 is resolved. At least the sample code doesn't error out any more. And I see some implementation in GNUCPPSourcerParser.parseTypeTrait() . So this bug can probably be closed now. As a follow-up: indexing a simple project with just #include <iostream> on Ubuntu 17 shows 3 errors like this in the log: Indexer: unresolved name at /usr/include/c++/6/type_traits(1361); A template id provides illegal arguments for the instantiation: integral_constant On investigation, it turns out that this is due to the following missing builtin: __is_trivially_constructible As a workaround, I went to Project Properties > C/C++ > Preprocessor Include Paths, Macros etc > GNU C++ > CDT User Settings Entries, and added a "Preprocessor Macros File" in my workspace. The file name is "eclipse-indexer-workarounds.h" and it has following line: #define __is_trivially_constructible(A, ...) (true)
The bug remains open to track implementation of some remaining type trait intrinsics like __is_trivially_constructible. I edited the bug title to clarify that we're just talking about type trait intrinsics in this bug, not other kinds of intrinsics.
I implemented evaluation of __is_trivially_constructible in bug 528072. Other intrinsics whose evaluation needs to be implemented are: __has_nothrow_assign __has_nothrow_copy __has_nothrow_constructor __has_trivial_assign __has_trivial_constructor __has_trivial_destructor __is_literal_type __is_trivially_assignable Once those are implemented as well, this bug can be closed.
