I'm trying to create an AST, not by parsing a file, but by calling function from within a program. It seems reasonable to do what the Clang parser does, which is creating a Sema and calling methods on it. For example, create an AST for x + y by calling CreateBuiltinBinOp() and BuildDeclRefExpr().
However, Sema.h isn't in the include directory, but rather the lib directory, which makes me think it's not "public facing." Is that right? If so, why? It seems to have well defined functionality and should be reusable.
Yes, that is correct. We meant for Sema to be an internal interface, because while it's functionality is well-defined at a very high level, it's details are rather messy and are very likely to change. Sema should really be split into several coordinating subclasses that isolate parser callbacks from semantic analysis from template instantiation from overloading and so on.
All that said, I'm not really opposed to making Sema.h public. It's not like our AST headers offer stable interfaces, either, it's just that Sema is even less stable.
Sema should really be split into several coordinating subclasses that
isolate parser callbacks from semantic analysis from template instantiation
from overloading and so on.
Do you know if this has happened, or what the status is of such
developments? I'm interested in performing semantic analysis for a variety
of things e.g. detection of certain idioms/patterns (double checked lock and
singleton spring to mind) followed by automated refactoring of both
definition and call sites.
I'm familiar with walking the AST using clang, it's just that I suspect that
these types of analysis would be perhaps more naturally expressible at the
higher level of abstraction that Sema may provide.
OK - I see I had the structure of clang wrong: sema is actually used to
construct the AST. I'm already working at the correct abstraction level!
Sorry to waste your time!