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

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

In D96033#2632848 <https://reviews.llvm.org/D96033#2632848>, @rjmccall wrote:

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

The state should match the state of Sema (at least that's the current case for cling).

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 have, over the years, deliberately have taken a very conservative stance and we have tried to achieve that goal without major modifications in clang in general. Cling has been ou-of-tree so clang design changes were not on the table then and now. In my opinion, we have managed to go long way using this set of changes <https://github.com/vgvassilev/clang/compare/release_90...cling-patches> in clang which in my view is fairly minimal considering the case we enable. My understanding of clang is limited so I cannot really judge if the approach we took is sustainable but over the years we have mostly suffered from having to selectively reset CodeGen state across incremental inputs. Plus some state in Sema which comes from another feature which requires recursive parsing but I would not consider that feature central for this particular discussion.

> We probably need to talk about it.

+1. Do you use discord/slack/skype?

In D96033#2633479 <https://reviews.llvm.org/D96033#2633479>, @rjmccall wrote:

> To be clear, what I'm trying to say is that — absent consensus that it's a major architecture shift is appropriate — we need to consider what functionality is reasonably achievable without it.  I'm sure that covers most of what you're trying to do; it just may not include everything.

I understand and would like to thank you for bringing this up! I concur with that preference.

> One of the fortunate things about working in a REPL is that many ABI considerations go completely out the window.  The most important of those is the abstract need for symbol-matching; that is, there's practically no reason why a C REPL needs to use the simple C symbol mangling, because nobody expects code written outside the REPL to link up with user-entered declarations.  So we can be quite aggressive about how we emit declarations "behind the scenes"; C mode really just means C's user-level semantics, calling convention, and type layout, but not any of C's ordinary interoperation/compatibility requirements.

I have never thought about ABI being a bi-directional problem, and indeed we can probably define away one direction. Do I understand that correctly? If I do, that would mean we can still embed the C REPL into third party code and be able to call compiled code from libraries?


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

https://reviews.llvm.org/D96033