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

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D96033#2630978 <https://reviews.llvm.org/D96033#2630978>, @v.g.vassilev wrote:

>>> 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

I see.  So you want to be able to sort of "roll back" Sema to a previous version of the semantic state, and yet you also need IRGen to *not* be rolled back because of lazy emission.  That seems... tough.  I don't think we're really architected to support that goal — frankly, I'm not sure C and C++ are architected to support that goal — and I'm concerned that it might require a ton of extra complexity and risk for us.  I say this not to be dismissive, but to clarify how I see our various responsibilities here.  Clang's primary mission is to be a static compiler, and it's been architected with that in mind, and it's acceptable for us to put that mission above other goals if we think they're in conflict.  So as I see it, your responsibility here is to persuade us of one of the following:

- that you can achieve your goals without introducing major problems for Clang's primary mission,
- that the changes you'll need to make will ultimately have substantial benefits for Clang's primary mission, or
- that we should change how we think about Clang's primary mission.

We probably need to talk about it.

>> 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.

Ah, I sort of remember that conversation.


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

https://reviews.llvm.org/D96033