Can newFrontendActionFactory be allowed to take arbitrary arguments?

Clang Frontend
#1

Hi,

In a lot of the examples, a clang tool is invoked in the following way:

Tool.run(newFrontendActionFactory().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
std::unique_ptr newFrontendActionFactory() {
class SimpleFrontendActionFactory : public FrontendActionFactory {
public:
clang::FrontendAction *create() override { return new T; }
};

return std::unique_ptr(
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?

Manasij Mukherjee

#2

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

#3

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