[clang] Remove dead incremental Parser code

[hahnjo]

When incremental processing is enabled, the Parser will never report tok::eof but tok::annot_repl_input_end. However, that case is already taken care of in IncrementalParser::ParseOrWrapTopLevelDecl() so this check was never executing.

[llvmbot]

@llvm/pr-subscribers-clang

Author: Jonas Hahnfeld (hahnjo)

Changes

When incremental processing is enabled, the Parser will never report tok::eof but tok::annot_repl_input_end. However, that case is already taken care of in IncrementalParser::ParseOrWrapTopLevelDecl() so this check was never executing.

---

Full diff: https://github.com/llvm/llvm-project/pull/102450.diff

1 Files Affected:

• (modified) clang/lib/Parse/Parser.cpp (-5)

diff --git a/clang/lib/Parse/Parser.cpp b/clang/lib/Parse/Parser.cpp
index 5ebe71e496a2e8..04c2f1d380bc48 100644
--- a/clang/lib/Parse/Parser.cpp
+++ b/clang/lib/Parse/Parser.cpp
@@ -629,11 +629,6 @@ bool Parser::ParseTopLevelDecl(DeclGroupPtrTy &Result,
                                Sema::ModuleImportState &ImportState) {
   DestroyTemplateIdAnnotationsRAIIObj CleanupRAII(*this);
 
-  // Skip over the EOF token, flagging end of previous input for incremental
-  // processing
-  if (PP.isIncrementalProcessingEnabled() && Tok.is(tok::eof))
-    ConsumeToken();
-
   Result = nullptr;
   switch (Tok.getKind()) {
   case tok::annot_pragma_unused:

[vgvassilev]

Your reasoning sounds right to me. Can we make sure we are not breaking clang -fincremental-extensions, too?

[hahnjo]

Your reasoning sounds right to me. Can we make sure we are not breaking clang -fincremental-extensions, too?

As far as I can tell, -fincremental-extensions should set the language option IncrementalExtensions which in turn is the default for Preprocessor::IncrementalProcessing. The few tests we have with -fincremental-extensions pass with this change.

[vgvassilev]

Lgtm!

[bnbarham]

As far as I can tell, -fincremental-extensions should set the language option IncrementalExtensions which in turn is the default for Preprocessor::IncrementalProcessing.

It is true that it is the default, but it's possible for clients to have one without the other. This is the case in Swift in particular (see #65683).

The few tests we have with -fincremental-extensions pass with this change.

I couldn't think of a great way to test this at the time. If anyone has any ideas though... 😅. Otherwise we could add a comment here to explain why it's needed?

[hahnjo]

As far as I can tell, -fincremental-extensions should set the language option IncrementalExtensions which in turn is the default for Preprocessor::IncrementalProcessing.

It is true that it is the default, but it's possible for clients to have one without the other. This is the case in Swift in particular (see #65683).

The few tests we have with -fincremental-extensions pass with this change.

I couldn't think of a great way to test this at the time. If anyone has any ideas though... 😅. Otherwise we could add a comment here to explain why it's needed?

If I understand correctly, you are manually calling Preprocessor::enableIncrementalProcessing? This should be added as a unittest because right now skipping tokens is not exercised in that scenario... (enableIncrementalProcessing is called in clang/unittests/Frontend/FrontendActionTest.cpp, I missed that at first)