[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

Vassil Vassilev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Mar 17 00:55:56 PDT 2021


v.g.vassilev added a comment.

>> I'm nervous in general about the looming idea of declaration unloading, but the fact that it's been working in Cling for a long time gives me some confidence that we can do that in a way that's not prohibitively expensive and invasive.
>
> I don't really know the jargon here.

"Code unloading" is mentioned here https://reviews.llvm.org/D96033?id=323531#inline-911819

> The biggest problem that I foresee around having a full-featured C REPL is the impossibility of replacing existing types — you might be able to introduce a *new* struct with a particular name, break the redeclaration chain, and have it shadow the old one, and we could probably chase down all the engineering problems that that causes in the compiler, but it's never going to be a particularly satisfying model.

Indeed. Cling did not have this feature until recently. We indeed "shadow" the reachable declaration maintaining (using inline namespaces) the redecl chain invariants (relevant code here <https://github.com/vgvassilev/cling/blob/899b3337fc25cb06d6b82d5451c5040515d94416/lib/Interpreter/DefinitionShadower.cpp#L73-L94>). I am not sure that approach can work outside C++.

> If we don't have to worry about that, then I feel like the largest problem is probably the IRGen interaction — in particular, whether we're going to have to start serializing IRGen state the same way that Sema state has to be serialized across PCH boundaries.  But I'm sure the people who are working on this have more knowledge of what issues they're seeing than I can just abstractly anticipate.

We find ourselves patching often that area in CodeGen when upgrading llvm (eg. here <https://github.com/vgvassilev/clang/commit/7274af0e10e0569ad3c685269814a458b9d49ad0>). The current cling model requires the state to be transferred to subsequent calls of IRGen. We briefly touched that topic in https://reviews.llvm.org/D34444#812418 (and onward) and I thought we had a plan how to move forward.


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

https://reviews.llvm.org/D96033



More information about the cfe-commits mailing list