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