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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits