[cfe-commits] [cfe-dev] Libclang and Objective-C headers

[Sean Hunt]

On 11-01-01 06:28 PM, Ted Kremenek wrote:
> Suppose FOO is defined by the including source file, or by *another header* that includes that header.  Sometimes headers aren't fully self-contained; they are intended to be used in the context of other headers.  One can argue whether that is good or bad practice, but it does happen.  Thus context matters here as well; in this case, it can change what is actually valid source code defined by the header, and what isn't.
>
> Another example is a header that can be included by both an Objective-C or Objective-C++ source file.  In one case it is Objective-C code, and in the other case it is Objective-C++ code.  The difference can really matter in some cases.
>
> Ultimately, no source file, whether it is a header or a vanilla .c file, has any intrinsic semantics until is parsed, in the full proper context, by the compiler.  That context includes all the -I and -D flags, etc.  Since headers are inherently tied to the preprocessor, they can be used in all sorts of ways, and so ultimately their semantics are determined by the file that includes the header.  That said, you can often skirt the issue with approximations, but if you are interested in replicating the semantics of a header that is seen by the actual developer in their project, headers need to be analyzed in the context of how they are actually used.

Given that there is all this context sensitivity, why don't we obey the 
caller when the caller tells us that a given file is C++, and instead go 
"oh, it is .h, it must be C"?

Sean