[cfe-commits] r52879 - in /cfe/trunk/lib/Sema: Sema.h SemaDeclAttr.cpp

[Eli Friedman]

On Tue, Jul 1, 2008 at 1:35 PM, Argiris Kirtzidis <akyrtzi at gmail.com> wrote:
> Chris Lattner wrote:
>> On Tue, 1 Jul 2008, Argiris Kirtzidis wrote:
>>>>  I'm not sure what you mean.  Since the Sema class is private to the
>>>> Sema  library, I'm fine with all of its members being public.  Is
>>>> that what you  mean?
>>>
>>> I'm talking about having Sema class "public" to client code, meaning
>>> moving Sema.h from 'lib/Sema' into 'include/clang/Sema'. Are there
>>> issues with this approach ?
>>
>> What is the advantage of that?  I would think most clients that would
>> want to build off Sema could just be AST consumers?
>
> There are some things that the AST is missing, like source locations for
> type identifiers. i.e for
>
> class A {};
> A x;
> class B { const A y; };
>
> get the source locations for A,B occurances.

If that's necessary for some uses (like rewriting the types of
variables?), we should figure out a way to encode it into the AST.
The AST is intended to encode all the information needed for source
analysis/rewriting tools.  (If I recall correctly, this isn't the
first time someone has asked about this.)

A few possibilities: Maybe add another SourceLocation to ScopedDecl?
Or maybe some sort of DeclChainDecl to act as a container for
declarations which chain, like variable declarations?  Or maybe just a
helper method to figure it out from the surrounding context, if that's
feasible?  (I'm just throwing out ideas here; I haven't really thought
it through.)

> One way to get semantic analysis *and* type locations is by subclassing
> the Sema class. Is there a better way for this ?

I think making Sema itself public is a bad idea. It likely will never
be stable enough to become a public interface.  We don't want to
commit to making it usefully subclassable, both because of the the
potential performance cost and the instability of Sema. And we don't
want outside code messing with its internal codeflow and data
structures: it would likely lead to subtle bugs in the semantic
analysis.

If seeing the calls between Parser and Sema is useful, we could add a
sort of listener which lets outside code see what calls the Parser is
making into Sema.  That said, I can't imagine it being useful except
in situations where the AST is missing useful information, and I'm not
sure we want to commit to anything about what exactly Sema returns to
the Parser.  We don't want to allow outside code to interfere with the
Parser-Sema interaction because it's likely to cause bugs in the
semantic analysis.

-Eli