[cfe-dev] No clang::Action no party

[Douglas Gregor]

On Sep 20, 2010, at 12:54 AM, Simone Pellegrini wrote:

>  Dear all,
> I noticed the old clang::Action interface has been wiped out from the 
> new release of clang. This was a big shoot for me as I rely on the 
> virtual dispatch of Actions and Sema to implement a mechanism to attach 
> pragmas to statements.
> 
> My solution was rather simple and effective, a custom class extending 
> Sema where a couple of methods of the Action interface were overloaded 
> (and by reading this mailing list frequently I know this is something 
> several people did for the same kind of problem). Now as the virtual 
> dispatch has been removed my overloaded functions are not called 
> anymore. I temporarily solved the problem by modifying the Sema 
> interface and redeclaring virtual those methods I need to overload. But 
> I would prefer to make my code work without patching clang.
> 
> I know you are rather picky with performance and virtual dispatch was 
> too expensive but you have to give us at least another way to call an 
> overloaded Sema.

Performance wasn't actually the issue, here, and I highly doubt that we gained any measurable performance with the devirtualization itself.

The change was an architectural fix, because there will never be another "Action" that implements enough of C/C++ to be useful. Sema is the only one, and it can grow extension points to allow customization.

> Could be templates an option here?
> 
> template <class Action = clang::Sema>
> class Parser { };
> 
> By using this mechanism you still keep the static method dispatch and 
> the capabilities of providing an overloaded behavior for Sema.

Turning the parser into a template would be a maintenance nightmare. It would then force us to move all of the parser code into a header, making it a compile-time nightmare, too.

> Is there 
> another way to have the behavior I am looking for?

Attaching pragmas to statements seems likely something that Clang should provide a "handler" mechanism for, just as it provides a handler mechanism for parsing the pragmas itself. The would be cleaner and more composable than inheriting from Sema.

	- Doug