[cfe-dev] Can newFrontendActionFactory be allowed to take arbitrary arguments?

Manasij Mukherjee manasij7479 at gmail.com
Mon Dec 22 12:56:43 PST 2014


Nice.
I tried to do the perfect forwarding by storing a 'bound' wrapper function
which calls new and got linker errors for a few tools.
Your idea seems better anyway.
I will try to use your patch locally.

Thanks


On Tue, Dec 23, 2014 at 1:26 AM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Mon, Dec 22, 2014 at 11:32 AM, Manasij Mukherjee <manasij7479 at gmail.com
> > wrote:
>>
>> Hi,
>> In a lot of the examples, a clang tool is invoked in the following way:
>>
>> Tool.run(newFrontendActionFactory<ActionType>().get());
>>
>> The problem is that this does not allow the user to construct their
>> object with arguments.
>> The solution is implementing a FrontendActionFactory and overriding
>> create.
>>
>> This is overkill in my opinion and can be easily integrated into the
>> SimpleFrontendActionFactory class defined in the library function as
>> follows.
>>
>> template <typename T>
>> std::unique_ptr<FrontendActionFactory> newFrontendActionFactory() {
>>   class SimpleFrontendActionFactory : public FrontendActionFactory {
>>   public:
>>     clang::FrontendAction *create() override { return new T; }
>>   };
>>
>>   return std::unique_ptr<FrontendActionFactory>(
>>       new SimpleFrontendActionFactory);
>> }
>>
>> This can be adapted to to use variadic templates, store the arguments
>> somehow and use them when constructing the new T.
>>
>> Is that a viable idea?
>>
>
> I have a patch somewhere that provides a couple of more generalized
> utilities that accept lambdas...
>
> (see this thread:
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140915/115084.html
>  and the 'makeTrivialFrontendActionFactory" and
> "makeLessTrivialFrontendActionFactory" - clearly some naming improvements
> would be in order at least - this all got mixed up along with some other
> refactoring I was doing at the time & I couldn't really settle on how to
> separate it due to some unresolved underlying design issues)
>
> Perfect forwarding is tricky here - since the values would need to be
> stashed into the SimpleFrontendActionFactory, then used in the construction
> of the new T object. That's why I went with something more general, the
> lambda, so the state capturing was clearer/more flexible.
>
> - David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141223/11fbb342/attachment.html>


More information about the cfe-dev mailing list