[cfe-dev] Decls are not synonyms for the symbols they represent
kremenek at apple.com
Wed Sep 17 12:46:23 PDT 2008
On Sep 17, 2008, at 12:19 PM, steve naroff wrote:
> I guess we could, however I'm still not sure it's the right thing to
> do (since it goes against our tenet of keeping the AST simple and
> reflective of the source). From the compiler's perspective, the 3
> DeclRefExprs *should* bind to 3 different VarDecls.
I agree with Steve here. The three separate declarations really are
separate declarations that should be represented explicitly in the AST.
> For this example, I'd like to know why/when we care if all these
> VarDecls refer to the same variable? Since each VarDecl is "extern",
> it's the linkers job to bind the actual
> variable definition (which isn't in this particular translation unit).
This is somewhat of a bad example; it was mainly to illustrate a
point. However, there are cases for this example where clients do
care that they refer to the same variable. For example, the static
analyzer, when analyzing these functions, may wish to know that these
three declarations represent the same global variable. Where that
variable is actually instantiated is irrelevant; the linker just takes
care of making sure their is storage slotted for that variable in some
translation unit. In other words,
we know that there is a global variable 'x' whose storage lies in some
other translation unit; if the program were to link and run, it will
be an actual variable in memory, so it doesn't really matter where it
> The "meta issue" here is how we preserve aspects of Sema's knowledge
> without bloating/contorting the AST's. Like everything else we've
> been doing with clang, it needs to be driven by actual clients. As
> clang clients evolve, we need to consider API's that enable our
> AST's to be used conveniently. Asking clients to re-implement
> complex Sema merging/checking/etc. isn't practical. Note that
> ImplicitCastExpr was added to make the code generators life more
> convenient - without it, the code generator would have to be in the
> type conversion business (which Chris/I wanted to avoid, given C's
> arcane rules). So, changes to the AST's are certainly not out of the
> question...we just need to be clear on the cost/benefit.
My thoughts exactly. It would be great if some of this information
could be stored in external data structures; clients who wish to keep
that information could do so, and otherwise it could get thrown away
once Sema is done with it.
More information about the cfe-dev