labath accepted this revision. labath added a comment. This revision is now accepted and ready to land.
I think this is fine. In D69704#1741588 <https://reviews.llvm.org/D69704#1741588>, @jingham wrote: > If, for instance, we decided to use .pcm files as a serialization form for > type info you would need the same sort of check for modules backed by these > pcm's - since the clang in lldb and the clang building the pcm would have to > match. BTW I am NOT suggesting that would be a good idea, and this will > probably always be a no-op for anything but Swift. Hm... If I understand modules correctly (and I admit I know very little about them), I think this actually illustrates the my reservations about this. Assuming we were fetching type info from a pcm file etc., there is no relationship between a module (shared library) and a pcm file... I would imagine a module can reference multiple pcm files, and each one could be theoretically built with a different compiler. That then brings up a question of what does it mean for lldb to be "compatible" with the module as a whole... ================ 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()); ---------------- labath wrote: > Do you want to store the actual error message in `type_system_or_err` into > sb_error? Actually, you can do that by just saying `sb_error.ref() = type_system_or_err.takeError()` or something along those lines. :) CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69704/new/ https://reviews.llvm.org/D69704 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
