Well I did find one case in which this will not work, maybe you can help me with this.
So lets say that pragmaInclude.h was changed to this:
#if
_MSC_VER > 1000
#pragma once
#endif
#ifndef PRAGMAINCLUDE_H_
#define PRAGMAINCLUDE_H_
#define SYMBOL 0
#endif
The code that I wrote will not skip over the #pragma once in this case. The only variables that I have in this function is the Lexer of the code, so I am not
really sure how I can ascertain that I need to process this line or not.
Any Ideas?
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergey Prigogin
Sent: Monday, September 30, 2013 3:01 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Help with Indexer Bug
On Mon, Sep 30, 2013 at 11:37 AM, Joseph Henry <Joseph.Henry@xxxxxxx> wrote:
Ok,
So I have implemented a solution that seems to solve this problem.
What I did was in IncludeGuardDetection.findIncludeGuard I added a some logic to skip the first #pragma
once (if it exists).
This seems to work without messing up anything.
What is the next step? How would I go about possibly contributing this fix?
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergey Prigogin
Sent: Sunday, September 22, 2013 1:42 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Help with Indexer Bug
The attached project is quite more complex than what was discussed in this email thread so far. Is the problem reproducible with the code quoted in this email thread?
On Fri, Sep 20, 2013 at 8:40 PM, Joseph Henry <Joseph.Henry@xxxxxxx> wrote:
It is. I have attached a project that reproduces this case in both bugs named in this thread.
Sent from my iPhone
On Fri, Sep 20, 2013 at 1:47 PM, Joseph Henry <Joseph.Henry@xxxxxxx> wrote:
When CPreprocessor encounters #include "header.h" in b.c it should include content from both, header.h
and stddef.h. header.h may be included from the index or as a source.
But it does not. When header.h is read from the index, it contains nothing, except what is defined
in header.h
Lets say that header.h looks like this.
#ifndef _HEADER
#define _HEADER
#include “stddef.h”
#endif
And lets say stddef.h looks like this
#pragma once
#define NULL 0
In the function processInclusionFromIndex in CPrepocessor, the InternalFileContent is read from the
index. When it calls getMacroDefinitions(), this returns only 1 definition which is _HEADER. If the #pragma once is not there this returns 2 definitions which are _HEADER and NULL
There seems to be a gap between discussion in this email and the actual reproducible case. Is the problem reproducible with stddef.h qouted in this email?
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergey Prigogin
Sent: Friday, September 20, 2013 4:07 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Help with Indexer Bug
On Fri, Sep 20, 2013 at 12:44 PM, Joseph Henry <Joseph.Henry@xxxxxxx> wrote:
Honestly I am not really sure.
This is what I saw when stepping though the code in the debugger.
File stddef.h has this structure:
#pragma once
#ifndef __STD
#define __STD
…..
#endif
I have a File with the following structure:
a.c
|_ stddef.h
|_ header.h
|_ stddef.h
and there is another File with the following structure:
b.c
|_ header.h
| |_ stddef.h
Now this is what I know happens:
When b.c is parsed, it finds the #include “header.h” and executes that statement.
When it looks for header.h it finds it, and its location is in the index.
Now header.h is included from the index, but it does not contain any instance of stddef.h.
A header stored in the index never contains content from another header. Each header is stored separately. When CPreprocessor encounters #include "header.h" in b.c it should include
content from both, header.h and stddef.h. header.h may be included from the index or as a source. This depends on significant macros of header.h.
What I don’t understand is why (or where) header.h is stored in the index without any instance of
stddef.h. It seems like a #pragma once should be treated just like a #ifndef #define #endif block. So from b.c since this file has not been encountered, it should be included.
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergey Prigogin
Sent: Friday, September 20, 2013 3:12 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Help with Indexer Bug
On Fri, Sep 20, 2013 at 11:22 AM, Joseph Henry <Joseph.Henry@xxxxxxx> wrote:
Ok,
After further looking into this, is seems that these are 2 separate issues. If you look at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=413768#c2 it shows a use case that supposedly should work, but that is the exact use case that is broken for me (with one minor change). I will explain.
Basically I have this situation:
a.c
|_ stddef.h (version S1)
|_ header.h
|_ stddef.h (version S2)
|_ use declaration found in S1
And these another source file that contains header.h
b.c
|_ header.h
| |_ stddef.h (version S1)
|_ use declaration found in S1
The problem comes into play where stddef.h has a #pragma once in it at the top of the file like:
If stddef.h had #pragma once, there would not be S2, would it?
Did you mean something like
a.c
|_ stddef.h (version S1)
|_ header.h
|_ stddef.h (version S1)
|_ use declaration found in S1
b.c
|_ header.h
| |_ stddef.h (version S2)
|_ use declaration found in S2
?
#pragma once
#ifndef __STDDEF__
#define __STDDEF__
…….
#define NULL 0
……
#endif
The #pragma once is what is causing the problem. Since it is outside of the #ifndef block, it seems
like the version of stddef.h that is included in header.h is just simply not put in the index. So from b.c, the definition of NULL cannot be found.
Maybe this explains my problem a bit more.
Any help would be great.
Thanks,
Joseph Henry.
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergey Prigogin
Sent: Friday, September 20, 2013 1:08 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Help with Indexer Bug
On Fri, Sep 20, 2013 at 9:50 AM, Joseph Henry <Joseph.Henry@xxxxxxx> wrote:
Hi all,
I have filed bug
417193, which seems to be related to bug
413768.
I have not gotten much response on either of these bugs and was wondering if someone could point me in the right direction to fix this. I really need this bug fixed so I have been
looking into it, but cant seem to make any headway.
If anyone could point me in the right direction that would be great.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
