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

[Simone Pellegrini]

  On 09/20/2010 04:46 PM, Douglas Gregor wrote:
> 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.
I actually do not agree with this statement. Clang actually does a very 
poor job (no offense) when it comes to pragmas. I actually spent some 
time in designing a framework to handle pragmas on top of clang and 
there are a couple of core changes which I need to do and for that I had 
to patch clang.

For example in OpenMP the standard allows C expressions to be written as 
part of the pragmas. For example someone can write:

#pragma omp parallel omp_threads(3*2+1)

For anyone interested in implement the full OpenMP standard this would 
require to re-implement a parser for C expressions (among other things), 
and this seems a duplication of work since the Clang parser already does 
it pretty well. In order to do that I had to make my pragma handler 
class friend of the clang::Parser; in this way I can directly use the 
private ParseExpression() method.

So, for short, custom pragma handlers need low level access to the 
Parser! (or some methods in the Parser should be made public).

Secondly when the pragma handler is called the attached statement has 
not yet being created by the parser so the association cannot be done by 
the handler but someone else has to take care of it (that's the reason 
why the Action interface was useful).
Either someone keeps a list of pragmas and do the matching at the end in 
the ASTConsumer, or for a more efficient solution which minimize the 
number of checks Sema should take care of it.

Anyway, if there is an interest in making pragma handling more flexible 
and powerful in clang I could contribute with some ideas and code (of 
course).

cheers, Simone



> 	- Doug