[PATCH] D127284: [clang-repl] Support statements on global scope in incremental mode.

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Nov 30 11:25:29 PST 2022


aaron.ballman added inline comments.


================
Comment at: clang/include/clang/Lex/Preprocessor.h:1782-1785
   void enableIncrementalProcessing(bool value = true) {
-    IncrementalProcessing = value;
+    // FIXME: Drop this interface.
+    const_cast<LangOptions &>(getLangOpts()).IncrementalExtensions = value;
   }
----------------
v.g.vassilev wrote:
> aaron.ballman wrote:
> > v.g.vassilev wrote:
> > > aaron.ballman wrote:
> > > > We should be able to drop this as part of this patch, right? (I think you can modify the `IncrementalAction` object so that it calls `CI.getLangOpts().IncrementalExtensions = true;` if needed, but you're passing the cc1 flag to the invocation and so I think you can maybe remove this call entirely.)
> > > I wanted to do this is a separate commit. I am worried of breaking downstream users. I remember long time ago @akyrtzi was using this logic. 
> > > 
> > > There are also a bunch of tests in clang and lldb.
> > > I wanted to do this is a separate commit. I am worried of breaking downstream users. 
> > 
> > Downstream users have no expectation of this interface remaining stable to begin with, so I'd rather we remove the code unless someone speaks up with a concrete technical problem. That said, I'm fine doing it in a separate commit so that it's easier to raise awareness for downstreams if you think this will be disruptive to them.
> I'd prefer doing it in a separate commit. This patch is bulky and we may need to revert it making all bots happy. That'd be probably make downstream consumers green/red for a while and generate a some email traffic ;)
Doing it as a separate commit is fine by me.


================
Comment at: clang/lib/Parse/ParseDecl.cpp:5395-5400
+  // FIXME: Tell the user this is unsupported.
+  if (!Stmts.empty()) {
+    unsigned ID = Actions.getDiagnostics().getCustomDiagID(
+        DiagnosticsEngine::Error, "Unsupported statement on the global scope");
+    Actions.Diag(Stmts.back()->getBeginLoc(), ID);
+  }
----------------
Why is this using a custom diagnostic instead of adding a typical diagnostic to DiagnosticParseKinds.td?


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

https://reviews.llvm.org/D127284



More information about the cfe-commits mailing list