bnbarham added a comment. 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`, ie. . I don't believe we'd want any difference in parsing in Swift's clang importer use case. > 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 https://github.com/llvm/llvm-project/blob/df6b35e329ebecad6dc3bfb83183e482eb7a0020/clang/lib/Parse/ParseExprCXX.cpp#L4070 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D148997/new/ https://reviews.llvm.org/D148997 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
