Bug 417193 - Incorrect Symbol <X> could not be found
Summary: Incorrect Symbol <X> could not be found
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-indexer (show other bugs)
Version: 8.2.1   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-13 10:15 EDT by Joseph Henry CLA
Modified: 2020-09-04 15:18 EDT (History)
5 users (show)

See Also:


Attachments
Project for recreate the bug (5.46 KB, application/octet-stream)
2013-09-13 10:15 EDT, Joseph Henry CLA
no flags Details
Simpler project to reproduce the bug (3.44 KB, application/octet-stream)
2013-09-23 09:08 EDT, Joseph Henry CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Henry CLA 2013-09-13 10:15:44 EDT
Created attachment 235466 [details]
Project for recreate the bug

When having muliple levels of inlcudes, and a bottom level include has a "#pragma once" you can end up with a Semantic Error of (Symbol <X> could not be found).

I have attached the project that I created to reproduce this, but you can recreate it by just using the files in the project.

1.) Create a new MingW C project
2.) Add S1.c, S2.c, Main.c
3.) Make sure that A1.h, B1.h, C1.h, D1.h, DEF.h, and DEF_2.h are in your inlcude path
4.) build, and make sure indexer is up to date.

Problem.

Opening S1.c, you can see that the symbol NULL2 is properly resolved.
Opening S2.c you can see that NULL2 is not properly resolved and you see the error 

Description	Resource	Path	Location	Type
Symbol 'NULL2' could not be resolved	S2.c	/MDBug	line 10	Semantic Error


It seems that if you remove the #pragma once from the file DEF.h, then this problem goes away.
Comment 1 Andrew Eidsness CLA 2013-09-16 09:49:11 EDT
I think this is caused by the same issues described in Bug 413768.  While investigating that one I often came across 'Undefined Symbol' errors.
Comment 2 Joseph Henry CLA 2013-09-18 11:46:47 EDT
Yes,

This looks exactly like what I was seeing, and the explanation from Markus Schorn is exactly what I was seeing while debugging the problem


Should I close this as a duplicate?

Also I noticed that if the "#pragma once" was surrounded by a #ifndef #define #nedif, then the problem does not happen.

Also, is there a proposed solution to this problem?
Comment 3 Joseph Henry CLA 2013-09-23 09:08:22 EDT
Created attachment 235717 [details]
Simpler project to reproduce the bug

This is a much simpler case to rep this bug.

Just open b.c and notice that SYMBOL is not defined.
Comment 4 Joseph Henry CLA 2013-09-23 13:08:51 EDT
Changed version to next since it is reproducible in the current release as well as  nightly.
Comment 5 Sergey Prigogin CLA 2013-09-23 13:12:12 EDT
(In reply to Joseph Henry from comment #4)
"Next" should not be used in the version field for bugs that are affecting released versions.
Comment 6 Sergey Prigogin CLA 2013-09-23 17:01:37 EDT
The problem is caused by CPreprocessor not recognizing that

#ifndef PRAGMAINCLUDE_H_
#define PRAGMAINCLUDE_H_
#endif /* PRAGMAINCLUDE_H_ */

statements in pragmaInclude.h constitute an include guard. This happens due to presence of "#pragma once" before the guard. CPreprocessor should allow "#pragma once" before an include guard similar to how IncludeOrganizer.getNumberOfIncludeGuardStatementsToSkip(IASTTranslationUnit) does it.
Comment 7 Eclipse Genie CLA 2016-06-02 15:48:52 EDT
New Gerrit change created: https://git.eclipse.org/r/74466