labath added a comment.
The part that bothers me here is that this assumes that the entirety of a
module (or an least the portion of it written in the same language) uses the
same version of the language. Is that true for swift? Because it definitely
isn't true for c++, as you can easily mix compile units built with different
`-std` flags (and most of the time it will work). So it's not clear to me how
this would work for c/c++, or any other language that offers some kind of a
version-independent ABI, thus, enabling one to combine different versions in a
single module. Nevertheless, since this is how swift works, it seems
reasonable to have some way to access this information. However, it's not clear
to me if this is the best way to do that...
Another thing on my mind is the name (type system). AFAICT, this is the first
mention of these words in all of `lldb/API` headers, so one would get the
impression that type systems are an internal implementation detail of lldb.
That's why this methods sort of jumps out in your face. Are we planning to make
more type system-y stuff visible at the SB level? If not, could we make this
name more generic? Maybe, IsDebugInfoCompatible (with the meaning that lldb is
able to understand all of debug info (of a given language) in this module)?
================
Comment at: lldb/source/API/SBModule.cpp:700-704
+ if (!type_system_or_err) {
+ sb_error.SetErrorStringWithFormat(
+ "no type system for language %s",
+ Language::GetNameForLanguageType(language));
+ llvm::consumeError(type_system_or_err.takeError());
----------------
Do you want to store the actual error message in `type_system_or_err` into
sb_error?
Repository:
rLLDB LLDB
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D69704/new/
https://reviews.llvm.org/D69704
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
