[cfe-dev] Patch to allow comment translators implementation
abramobagnara at tin.it
Fri Jan 15 09:17:10 CST 2010
Il 12/01/2010 22:40, Chris Lattner ha scritto:
>> The only proposal I see that would not change a lot of things is to
>> remove Token argument from CommentHandler and to specify that they
>> always shall use EnterTokenStream also when they need to insert only one
>> Then at end of Preprocessor::HandleComment if any of the comment
>> handlers has informed the caller to have inserted some tokens the first
>> one available is fetched and returned by Preprocessor::HandleComment.
> Yes, I think this is a good plan.
You find attached a revised patch (based on r93512) that work as designed.
The patch passes all clang tests.
>>> I think it's okay if the HandleComment protocol can be simplified a bit
>>> and if it is documented, although I'd like to hear from Chris. I'd feel
>>> much better if we actually had some kind of use of this code path within
>>> Clang itself. For example, would it be possible for the keep-comments
>>> mode to be implemented outside of the lexer using your changes to
>>> HandleComment? That might actually simplify the lexer while making it
>>> more general.
>> ... hmmm, probably it's feasible, but I'm not so sure it's a good idea
>> because this means we should always have a CommentHandler loaded and we
>> have the problem of CommentHandler execution order, as only the first
>> CommentHandler that want to return a first Token is allowed to do that
>> (unless we implement the variant above).
> I don't think it's necessary to reimplement -C. This functionality
> would be useful to implement the OpenMP pragma language, for example.
> What do you plan to use this for? Would any of it be coming back to
> mainline at some point?
We intend to have some specially formed comments that could be
translated on demand into tokens to be parsed together with original
source while being transparent to each other compiler.
This could be used for program annotations, constraints for programming
by contract, instrumentation directives, special purpose assertions or
Although I think that the availability of this service in the clang
library is indeed valuable, I currently don't see a specific application
of this service suitable for current clang mainline.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6875 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100115/0fc595e5/attachment.bin
More information about the cfe-dev