AFAICT this is all dead code. Unless someone is using it out of tree? There is a way to register repl support for various languages, but no code in tree is actually doing this. It’s possible I’m just not finding the code though.
It appears this code was all added about 18 months ago, and if it hasn’t found any use in that time frame, it would be great to remove it to reduce technical debt.
That said, if it’s actually being used in tree somewhere and I’m just overlooking it, let me know.
It's used in the swift lldb, https://github.com/apple/swift-lldb
The idea is to have any non-swift specific code in llvm.org; the github repository for swift specific additions.
Thanks, I had a suspicion it might be used in Swift. Given that swift seems to be the only consumer, and there are no plans for support for any other languages, would it be reasonable to say that it’s a swift-specific addition and could be in the swift repo?
If not, I will need to come up with a good way to get REPL.h to not #include code from the source tree (and ideally, not #include code from Commands at all).
I don't follow REPL issues very closely but I think some people may have hopes of doing a repl in a language other than swift in the future which is why it was upstreamed to llvm.
J
Not having written or debugged swift before, what does it give you that a ScriptInterpreter plugin doesn’t? It seems like ScriptInterpreterPython is, in fact, just a kind of REPL, albeit one that interacts with the debugger itself rather a particular target. I’m wondering if anyone who wanted this kind of thing in the future could just do it as a ScriptInterpreter plugin
There's no reason why you couldn't do a C REPL, so having the framework for it in llvm.org seems reasonable. Just the generic part is enough trickery it is worth sharing.
I'm not sure why you care about the fact that Repl.h includes something from Command, but if you do then probably the easiest way to sort that out is to move REPL.h and REPL.cpp into Commands. The REPL is really a modification of the expr command anyway (you can access it at any time in a swift debug session by "expr --repl -- " and the interactive REPL just does some setup and runs lldb expressions in the repl mode.
So even though it is a feature of expressions, and the actual implementation of the REPL is properly somewhere in the Swift tree, it would be equally valid to consider the generic REPL code an extension of the CommandObjectExpression, so living in Commands and #including "CommandObjectExpression" seem reasonable.
Jim
ScriptInterpreters are about providing a way to script lldb.
The REPL in lldb is about giving users an interactive way to play with a compiled language with no requirement that it bind to lldb in particular.
The two seem fairly different concepts.
Jim
There's no reason why you couldn't do a C REPL, so having the framework for it in llvm.org seems reasonable. Just the generic part is enough trickery it is worth sharing.
I'm not sure why you care about the fact that Repl.h includes something from Command, but if you do then probably the easiest way to sort that out is to move REPL.h and REPL.cpp into Commands. The REPL is really a modification of the expr command anyway (you can access it at any time in a swift debug session by "expr --repl -- " and the interactive REPL just does some setup and runs lldb expressions in the repl mode.
So even though it is a feature of expressions, and the actual implementation of the REPL is properly somewhere in the Swift tree, it would be equally valid to consider the generic REPL code an extension of the CommandObjectExpression, so living in Commands and #including "CommandObjectExpression" seem reasonable.
Note you would still have to do some trickery because REPL.h can't live in source/Commands, so you would have to make REPL::SetCommandOptions take an opaque object and then cast it in the .cpp file where you can include CommandObjectExpression.h and figure out the real type.
Jim
There’s no reason why you couldn’t do a C REPL, so having the framework for it in llvm.org seems reasonable. Just the generic part is enough trickery it is worth sharing.
I’m not sure why you care about the fact that Repl.h includes something from Command, but if you do then probably the easiest way to sort that out is to move REPL.h and REPL.cpp into Commands. The REPL is really a modification of the expr command anyway (you can access it at any time in a swift debug session by "expr --repl – " and the interactive REPL just does some setup and runs lldb expressions in the repl mode.
Mostly for the reasons that have been discussed before about breaking cycles, leading to faster builds, lower binary size, and enabling c++ modules. Currently Expression and Command depend on each other. But only because of this 1 include. Without this include, Command depends on Expression but not vice versa.
I’m still curious what unique functionality REPL provides that cannot be accomplished with ScriptInterpreter, but mostly as a curiosity since it’s not my immediate problem
ScriptInterpreters are about providing a way to script lldb.
The REPL in lldb is about giving users an interactive way to play with a compiled language with no requirement that it bind to lldb in particular.
The two seem fairly different concepts.
Sure, but isn’t that just a side effect of the fact that we only have 1, and that’s what it happens to do? It still enters a REPL when you type “script”, the fact that it manipulates lldb itself seems like just an implementation detail.
There’s no reason why you couldn’t do a C REPL, so having the framework for it in llvm.org seems reasonable. Just the generic part is enough trickery it is worth sharing.
I’m not sure why you care about the fact that Repl.h includes something from Command, but if you do then probably the easiest way to sort that out is to move REPL.h and REPL.cpp into Commands. The REPL is really a modification of the expr command anyway (you can access it at any time in a swift debug session by "expr --repl – " and the interactive REPL just does some setup and runs lldb expressions in the repl mode.
So even though it is a feature of expressions, and the actual implementation of the REPL is properly somewhere in the Swift tree, it would be equally valid to consider the generic REPL code an extension of the CommandObjectExpression, so living in Commands and #including “CommandObjectExpression” seem reasonable.
Note you would still have to do some trickery because REPL.h can’t live in source/Commands, so you would have to make REPL::SetCommandOptions take an opaque object and then cast it in the .cpp file where you can include CommandObjectExpression.h and figure out the real type.
Also there is currently no Commands header directory, so I would probably need to create one with a single file. Kinda unfortunate I guess, but it works
>
> There's no reason why you couldn't do a C REPL, so having the framework for it in llvm.org seems reasonable. Just the generic part is enough trickery it is worth sharing.
>
> I'm not sure why you care about the fact that Repl.h includes something from Command, but if you do then probably the easiest way to sort that out is to move REPL.h and REPL.cpp into Commands. The REPL is really a modification of the expr command anyway (you can access it at any time in a swift debug session by "expr --repl -- " and the interactive REPL just does some setup and runs lldb expressions in the repl mode.
>
> So even though it is a feature of expressions, and the actual implementation of the REPL is properly somewhere in the Swift tree, it would be equally valid to consider the generic REPL code an extension of the CommandObjectExpression, so living in Commands and #including "CommandObjectExpression" seem reasonable.Note you would still have to do some trickery because REPL.h can't live in source/Commands, so you would have to make REPL::SetCommandOptions take an opaque object and then cast it in the .cpp file where you can include CommandObjectExpression.h and figure out the real type.
Also there is currently no Commands header directory, so I would probably need to create one with a single file. Kinda unfortunate I guess, but it works
Either that or leave REPL.h in Expression and just move the .cpp file. Since you're going to have to make REPL.h pass types from Commands as opaque objects, it doesn't really need to live in Commands....
Jim
ScriptInterpreters are about providing a way to script lldb.
The REPL in lldb is about giving users an interactive way to play with a compiled language with no requirement that it bind to lldb in particular.
The two seem fairly different concepts.
Sure, but isn't that just a side effect of the fact that we only have 1, and that's what it happens to do? It still enters a REPL when you type "script", the fact that it manipulates lldb itself seems like just an implementation detail.
They have sufficiently different purposes that requiring the ScriptInterpreter to be a good "fool around with a supposedly compiled language interactively" or the "REPL" to be good at programming lldb seems like it would hamstring both to no clear purpose.
Jim
Long term I wonder if we should have a plugin library that contains headers and registration interfaces for every type of plugin lldb supports, but no actual implementations. All the specific plugins could link against it, and everything else in lldb could too to get interface definitions for each type of plugin. Then, than would be a natural place to put this, and specific implementations could live in Plugins/REPL
That seems reasonable, but I don't think it would solve your immediate problem.
The problem here is that the REPL has two parts, the part that is extensible to support the actual language you want to write a REPL for, and a part that is "any particular REPL is just an extension of the expression command." These two roles are currently filled by the same class, and the latter half of the REPL's nature properly relies on details of the expression command that you probably don't want to plugin-ize. The correct solution to that problem is to tease apart the "runner" part of the REPL, which doesn't need a Plugin interface and can live in source/Commands, and the language adaptor part which is properly a plugin. Then the language adaptor could go in ExpressionParser plugin directory.
Not suggesting you do that work, but that seems like the actually correct solution here.
Jim
Yea, i was sort of extrapolating for a general solution to "how can we best isolate implementation specific functionality in plugins from implementation agnostic functionality in . There are a handful of other instances where a generic component includes directly from the tree of a specific plugin, so centralizing to a single plugin library seems like a starting point for solving it generally, while also serving as good documentation for the various types of plugins that exist (ie, just look in the folder at each header file).
Anyway, it’s not related to this immediate problem as you said