[PATCH] D148997: [clang] Add a new annotation token: annot_repl_input_end

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

In D148997#4561015 <https://reviews.llvm.org/D148997#4561015>, @bnbarham wrote:

> In D148997#4559788 <https://reviews.llvm.org/D148997#4559788>, @v.g.vassilev wrote:
>
>> I'd prefer to avoid adding a new flag. Is there a way to see how does the diff looks like?
>
> You mean for a new flag? I don't have one prepared, but it would basically just be adding an extra check where `isIncrementalProcessingEnabled` is currently used to skip resetting `CurLexer` and `TUScope`. I don't believe we'd want any difference in parsing in Swift's clang importer use case.

I meant that I'd like to figure out if we could use the `annot_repl_input_end` before considering a new flag.

>> Maybe it would make more sense to use the `annot_repl_input_end` token? If the token name does not capture well the generic use-case I am happy to change it to something better.
>
> The issue is that all these actions (and the parser checks) can run with and without `isIncrementalProcessingEnabled`, so they would need to check both `eof` and `annot_repl_input_end`. For some concrete locations (but no where near complete):
> https://github.com/llvm/llvm-project/blob/df6b35e329ebecad6dc3bfb83183e482eb7a0020/clang/lib/Frontend/FrontendActions.cpp#L82
> https://github.com/llvm/llvm-project/blob/df6b35e329ebecad6dc3bfb83183e482eb7a0020/clang/lib/Frontend/FrontendActions.cpp#L955
> https://github.com/llvm/llvm-project/blob/df6b35e329ebecad6dc3bfb83183e482eb7a0020/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp#L542

These three seem to be useful for `clang-repl` too, so we might want to extend it with like `!(eof || annot_repl_input_end)`

> https://github.com/llvm/llvm-project/blob/df6b35e329ebecad6dc3bfb83183e482eb7a0020/clang/lib/Parse/ParseExprCXX.cpp#L4070

That looks a bit obscure to me. Looks like we are trying to reach some error recovery anchor but do you happen to have some use case at hand? In principle we could do the same as for the other 3.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148997/new/

https://reviews.llvm.org/D148997