Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 356062

Summary:	Indexer does not work with stdlib's shared_ptr
Product:	[Tools] CDT	Reporter:	Jussi Pakkanen <jpakkane>
Component:	cdt-build	Assignee:	cdt-build-inbox <cdt-build-inbox>
Status:	RESOLVED WORKSFORME	QA Contact:	Andrew Gvozdev <angvoz.dev>
Severity:	enhancement
Priority:	P3	CC:	cdtdoug
Version:	8.0
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Jussi Pakkanen

2011-08-29 06:31:15 EDT

Build Identifier: I20110613-1736

The C++ parser somehow misparses the standard C++ libraries' header files when attempting to use shared_ptr.

Reproducible: Always

Steps to Reproduce:
Create a new C++ file shared_ptr.cc with the following contents:

-----

#include<memory>

typedef std::shared_ptr<int> dummy;
typedef std::tr1::shared_ptr<int> dummy2;

-----

The C++ indexer will say that the first declaration is invalid whereas the latter is valid. In reality the opposite is true.

Compiling with g++ -c -Wall -o shared_ptr.o shared_ptr.cc gives the following error:

shared_ptr.cc:3:9: error: ‘shared_ptr’ in namespace ‘std’ does not name a type
shared_ptr.cc:4:9: error: ‘tr1’ in namespace ‘std’ does not name a type

This is because shared_ptr was promoted to standard library only with C++0x. Compiling in this mode with g++ -c -Wall -std=c++0x -o shared_ptr.o shared_ptr.cc gives this error:

shared_ptr.cc:4:9: error: ‘tr1’ in namespace ‘std’ does not name a type

Thus GCC says that the tr1 declaration is never valid, whereas CDT says it is. Conversely GCC says that the std:: declaration is valid with C++0x, but CDT says that it is never valid.

Comment 1 Markus Schorn

2011-09-07 03:05:29 EDT

I cannot reproduce the issue, both declarations generate a problem (using the system headers of gcc 4.5.2 for mingw).
When I configure the indexer for c++0x (passing -std=c++0x to the compiler in the discovery options) then the first declaration is ok.

Can you reproduce the issue in a new project that contains just the single file?
Can you navigate (using F3) std::tr1::shared_ptr<int>, where does it take you?

Comment 2 Jussi Pakkanen

2011-09-07 03:19:17 EDT

This happens to me on every project, both with other files present and with an otherwise empty project.

I use Ubuntu natty amd64. The GCC identification string is

gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2

F3 takes me to /usr/include/c++/4.5/tr1/shared_ptr.h.

I added -std=c++0x to discovery options and now it gives an error on both lines. Even if I remove it and force an index rebuild.

Comment 3 Markus Schorn

2011-09-08 08:25:02 EDT

(In reply to comment #2)
> This happens to me on every project, both with other files present and with an
> otherwise empty project.
> I use Ubuntu natty amd64. The GCC identification string is
> gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
> F3 takes me to /usr/include/c++/4.5/tr1/shared_ptr.h.
When I include this file (somewhere in the project), then the second line
gets resolved, which is ok. To figure out where the file gets included in your project you can use the include browser. (Open 'tr1/shared_ptr.h', from the context menu in the editor choose 'Show in - Include Browser'.

> I added -std=c++0x to discovery options and now it gives an error on both
> lines. Even if I remove it and force an index rebuild.
Did the discovery work? If so you'll see '__GXX_EXPERIMENTAL_CXX0X__' in the list of symbols on the 'Paths and Symbols' property page.

Comment 4 Jussi Pakkanen

2011-09-08 09:29:52 EDT

This is very strange.

If I put in -std=c++0x and rebuild the index, then GXX_EXPERIMENTAL... is most definitely NOT in the list of symbols and the indexer gives an error.

If I then remove -std=c++0x from the discovery options and reindex, the definition DOES appear in symbols and the indexer does recognise the shared pointer definition correctly.

When changing discovery options, I click "apply" and then "ok" to ensure change propagation.

Comment 5 Andrew Gvozdev

2011-09-08 09:56:21 EDT

After you change scanner discovery settings it takes a build (i.e. compilation) to trigger scanner discovery, reindex won't do that.

Comment 6 Jussi Pakkanen

2011-09-12 07:31:05 EDT

Ok, I can now get it working as it should.

The only "bug" left is more of a wishlist thing that switching to C++0x mode should be easier.

Comment 7 Markus Schorn

2011-09-16 07:09:09 EDT

We should make it easier for the user to keep the build-settings in sync with the compiler inspection done as part of the scanner discovery. Many of the compiler options influence the predefined macros and/or the predefined include search path. The option -std=c++0x is just an example for that.

There are probably two use cases:
(1) Managed build:
    The user has to add the compiler option for the build and separately
    he needs to adjust the command-line for the compiler inspection.
    Can we reuse the settings specified for the build?
(2) Unmanaged build:
    The option has to be defined somewhere in a makefile.
    Can we grab the compiler options via the build-output parser?

Comment 8 Andrew Gvozdev

2011-09-16 07:42:55 EDT

(In reply to comment #7)
I created separate bug 357927 for that.