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

Bug 370265

Summary:	Symbol resolution has stopped working between Juno M4/M5
Product:	[Tools] CDT	Reporter:	Michael Woski <woskimi>
Component:	cdt-codan	Assignee:	CDT Codan Inbox <cdt-codan-inbox>
Status:	CLOSED WORKSFORME	QA Contact:	Elena Laskavaia <elaskavaia.cdt>
Severity:	major
Priority:	P3	CC:	cdtdoug, yevshif, zeratul976
Version:	8.1.0
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Michael Woski

2012-01-31 14:21:07 EST

I have multiple projects in my workspace, where I very cautiously try to encapsulate & export my stuff using the export settings. So when I reference projects symbols and includes are automatically set.

Since I updated to M5 I suddenly get symbol resolution errors all over the place. The symbols are all from other projects and I think that they are all typedef'ed enum's.

Now, the compiler itself works like a charm and does not complain about anything (well it does but not about those symbols ;-) even when I set the weirdest warning levels. Also F3 and macro expansion does what it should do.

Another thing that I don't quite get is the following:
In project A I have a header that declares some global types and it also includes <stdint.h>. The libc is not being explicitely exported in the build settings and neither do I import it in the other projects. What I do though is, I #include my global type file which means stdint.h should be visible there too. And in fact the compiler gets it all right. It's again codan that is doing funny things.

I might say that I have only tried with cross-compiler settings and each of my projects have more than one such build setting.

Comment 1 Michael Woski

2012-02-02 14:02:50 EST

another thing that I've discovered is that error markers are getting refreshed only after changing to another EditorPart and returning back to the editor in question.
All in all I must admit I find the indexer a beast that has always given me headaches :-(

Comment 2 Andrew Gvozdev

2012-02-02 14:57:39 EST

Did you try reindexing? Your report is a bit vague to work with. If you can post reproducible example that would be useful. This could be bug 368045 or something different.

Comment 3 Michael Woski

2012-02-03 03:04:52 EST

first of all, I switched back to a recent 8.0.0 maintenance version, which solved the issue for me. So there is definitely something wrong in the last milestone build.

Maybe I try to explain again:

Project A:
* on the Include-Path: some cross-libc, /include(exported)
* mytypes.h includes (stdint.h), uses uint8_t, declares typedef enum {TEST1, TEST2} x_t

Project B:
* reference to Project A in project settings -> /include from Project A appears in the include path
* myfile1.c includes mytypes.h
        -> everytime I use x_t I get an error about "symbol TEST1 can't be resolved"
* myfile2.c includes mytypes.h -> does not use any of the typedefs in mytypes.h but uses unit8_t
        -> now I get an error about uint8_t not being defined

The compiler, on the other hand, runs smoothly and does not complain about any of the errors mentioned above.

is that clearer now?

Comment 4 Nathan Ridge

2013-07-17 21:53:27 EDT

Do you still experience these issues with CDT 8.2 (Kepler)?

Comment 5 Michael Woski

2013-07-18 05:19:06 EDT

(In reply to comment #4)
> Do you still experience these issues with CDT 8.2 (Kepler)?

no, the problem seems to have vanished.

Comment 6 Elena Laskavaia

2014-06-18 20:15:17 EDT

closing as it seems to resolve itself