labath added a comment.
I agree with your reasoning about language runtime dependencies, and I think
this is the right way to accomplish this.
However, I just want to add that from an lldb-server POV, even the fact that we
pull in the `Process` class into it's dependency graph is a bug. So, what I'd
do (and what I have been doing so far, but mainly as a passtime effort) was to
cut the dependencies way lower that this. Ideally, I wouldn't want to include
anything from the `Target` library in lldb-server, possibly by moving some
stuff that lldb-server does need to use (MemoryRegionInfo) out of it.
But, you know, there are multiple angles from which you can attack this
problem, and if this results in dependency cleanups in the rest of lldb, then I
don't see a reason to not proceed here.
================
Comment at: include/lldb/Target/CPPLanguageRuntime.h:47
+ static CPPLanguageRuntime *GetCPPLanguageRuntime(Process &process) {
+ return static_cast<CPPLanguageRuntime *>(
+ process.GetLanguageRuntime(lldb::eLanguageTypeC_plus_plus));
----------------
It might be nice to add some glue so we could write
`llvm::cast_or_null<CPPLanguageRuntime>(...)` here. The main advantage of that
being that we'd automatically get an assert firing if `GetLanguageRuntime` ever
returns something which is *not* a CPPLanguageRuntime.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D62755/new/
https://reviews.llvm.org/D62755
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
