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