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

Bug 347719

Summary:

CDT Indexer cannot resolve some symbols in header files in "Includes path"

Product:

[Tools] CDT

Reporter:

Dan Lee <danleepw>

Component:

cdt-indexer

Assignee:

Project Inbox <cdt-indexer-inbox>

Status:

RESOLVED INVALID

QA Contact:

Markus Schorn <mschorn.eclipse>

Severity:

normal

Priority:

CC:

cdtdoug, hrogge, mooroon2, yevshif

Version:

7.0.2

Target Milestone:

---

Hardware:

OS:

Linux

Whiteboard:

Attachments:

Description	Flags
screen cap of local time.h outline	none
screen cap of /usr/include/time.h outline	none
time.h	none

Description Dan Lee

2011-05-31 00:35:02 EDT

Build Identifier: 20110218-0911

In a C/++ project, indexer should be able to resolve all symbols defined in header files in include path. However, some symbols can be resolved but not in correct status. E.g. nanosleep() in /usr/include/time.h are always "inactive". Therefore, the content assist is not working properly.

I have tried to add "_GNU_SOURCE" in the symbols list. But it doesn't help.

I also try to create a self-contained example by copying the time.h to project folder. Indexer works properly this time. nanosleep() is active.

Reproducible: Always

Steps to Reproduce:
1. Create a C project, Executable -> Hello World ANSI C Project
2. in HelloWorld.c, add #include <time.h>
3. Add symbol "_GNU_SOURCE" in the project properties-> C/C++ General -> Paths and Symbols -> Symbols
4. open time.h. In outline view, nanosleep is inactive
5. copy time.h in project folder. Open the local time.h. In outline view, nanolseep is active

Comment 1 Dan Lee

2011-05-31 00:42:36 EDT

Created attachment 196956 [details]
screen cap of local time.h outline

Comment 2 Dan Lee

2011-05-31 00:43:13 EDT

Created attachment 196957 [details]
screen cap of /usr/include/time.h outline

Comment 3 Dan Lee

2011-05-31 02:46:18 EDT

My Linux env is: Fedora 14, 2.6.35.13-91.fc14.i686, gcc 4.5.1

Comment 4 Markus Schorn

2011-05-31 02:51:05 EDT

Please attach time.h and indicate which preprocessor condition causes the code to become inactive. In the project properties, check the indexer setting 'Files parsed up front'.

Comment 5 Dan Lee

2011-05-31 03:02:46 EDT

Files parsed up front: cstdarg, stdarg.h, stddef.h, sys/resource.h, ctime, sys/types.h, signal.h, cstdio

Actually, i don't know which preprocessor condition causes the code
to become inactive since they have different behavior in local and include path.

Comment 6 Dan Lee

2011-05-31 03:03:59 EDT

Created attachment 196960 [details]
time.h

Comment 7 Dan Lee

2011-05-31 04:56:54 EDT

glibc-headers-2.13-1.i686

Comment 8 Markus Schorn

2011-05-31 05:02:17 EDT

(In reply to comment #5)
> Files parsed up front: cstdarg, stdarg.h, stddef.h, sys/resource.h, ctime,
> sys/types.h, signal.h, cstdio
> Actually, i don't know which preprocessor condition causes the code
> to become inactive since they have different behavior in local and include
> path.

Rephrasing the question: The inactive code is shown with a grey background in the editor. The grey section has to start at some preprocessor statement, which one is it?

Comment 9 Dan Lee

2011-05-31 05:11:39 EDT

(In reply to comment #8)
> (In reply to comment #5)
> > Files parsed up front: cstdarg, stdarg.h, stddef.h, sys/resource.h, ctime,
> > sys/types.h, signal.h, cstdio
> > Actually, i don't know which preprocessor condition causes the code
> > to become inactive since they have different behavior in local and include
> > path.
> 
> Rephrasing the question: The inactive code is shown with a grey background in
> the editor. The grey section has to start at some preprocessor statement, which
> one is it?

time.h: line number 130
#ifdef _TIME_H

Comment 10 Dan Lee

2011-06-07 05:47:31 EDT

Hello, any update about this bug?

Comment 11 Markus Schorn

2011-06-29 06:53:37 EDT

(In reply to comment #10)
> Hello, any update about this bug?

You should be able to resolve the issue by adding time.h into the list of files parsed front up. I guess (I have different system headers) it is best to insert it after <ctime>. If this does not work, move it as far to the front as necessary (but not any further):

Try:
cstdarg, stdarg.h, stddef.h, sys/resource.h, ctime, time.h, sys/types.h, signal.h, cstdio

Comment 12 Markus Schorn

2011-08-19 08:22:21 EDT

No response from submitter.

Comment 13 Alexey Loukianov

2011-10-25 01:00:37 EDT

I experience just the same bug using Eclipse 3.7.1 Stable. Should I report a new issue or would it be possible to reopen this one?

Problem is just the same: including time.h in pure-C linux code results in advanced things like nanosleep(), CLOCK_MONOTONIC and struct timespec to be unresolved by indexer. Adding time.h into list of the headers that should be indexed up-front improves situation a bit but still CLOCK_MONOTONIC remains unresolved.

P.S. To enable usage of nanosleep and other fancy features I define _POSIX_C_SOURCE symbol equal to 199309L. Same effect might be achieved by defining _GNU_SOURCE but defining _POSIX_C_SOURCE provides more fine-graided control on what glibc subsets are being exposed so I prefer to use it instead of _GNU_SOURCE.

Comment 14 Alexey Loukianov

2011-10-25 02:58:40 EDT

Update: In my case it had been possible to workaround the problem by setting up-front parse list to this:
cstdarg, stdarg.h, stddef.h, ctime, time.h, sys/resource.h, sys/types.h, signal.h, cstdio

Comment 15 Henning Rogge

2012-02-25 15:48:49 EST

I have the same problem, even with the feature macros set CLOCK_MONOTONIC cannot be resolved.