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

Vassil Vassilev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Aug 4 12:41:21 PDT 2023


v.g.vassilev added a comment.

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

> In D148997#4561577 <https://reviews.llvm.org/D148997#4561577>, @v.g.vassilev wrote:
>
>>> My other concern here is that it seems our use cases are somewhat different, eg. we wouldn't want any parsing differences and while I don't know why this is yet, the removal of:
>>
>> I think I understand now. We basically want a mode which keeps some of the clang objects alive and ready to process more input. And on top, for clang-repl we want to enable some special parsing mode for the top-level statement declarations.
>
> Yeah, I'd say that sums it up pretty well.
>
>>>   // Skip over the EOF token, flagging end of previous input for incremental
>>>   // processing
>>>   if (PP.isIncrementalProcessingEnabled() && Tok.is(tok::eof))
>>>     ConsumeToken();
>>>
>>> is causing issues for us as well.
>>
>> Yes, that now seems to be moved on the user side as we thought it would be dead code. We can bring that one back if that's the only issue you see with that approach.
>
> I think it would make sense to bring it back under the mode you spoke about above, yeah 👍

So, in that case we should bring back the boolean flag for incremental processing and keep the `IncrementalExtensions` LanguageOption separate. In that case `IncrementalExtensions` would mean that we must turn on incremental processing for managing lifetime and only use the language option when extending the parsing logic. However, I think the problem would be what to do with the `tok::eof` and `tok::annot_repl_input_end`? I'd probably need @aaron.ballman or @rsmith here...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148997



More information about the cfe-commits mailing list