labath added a comment. Heh, I didn't realize that "debugger-less" events are implemented by iterating over all debugger instances, but since we're doing that for progress events anyway, we might as well copy the pattern.
Any chance of a test case for some of this stuff? Maybe a unittest which creates a Debugger object and uses it to send/receive some events? ================ Comment at: lldb/include/lldb/Core/DebuggerEvents.h:73 + +class WarningEventData : public DiagnosticEventData { +public: ---------------- Do we really need separate types for this? The handling of the two events is completely identical (except for the "error"/"warning" prefix, so it seems that an enum would suffice. The classes won't make it to the SB api (I think), so it's not like we're locking ourselves into a particular design. ================ Comment at: lldb/source/Core/Debugger.cpp:1665-1671 listener_sp->StartListeningForEvents(&m_broadcaster, Debugger::eBroadcastBitProgress); + listener_sp->StartListeningForEvents(&m_broadcaster, + Debugger::eBroadcastBitWarning); + listener_sp->StartListeningForEvents(&m_broadcaster, + Debugger::eBroadcastBitError); ---------------- StartListeningForEvents(eBroadcastBitProgress | eBroadcastBitWarning | eBroadcastBitError) ? ================ Comment at: lldb/source/Core/Debugger.cpp:1866 + + Stream &stream = *GetAsyncErrorStream(); + stream << "warning: " << data->GetMessage() << '\n'; ---------------- GetAsyncErrorStream returns a (shared -- it should probably be a unique_ptr instead) pointer to a new object. You can't just throw it away here. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D121511/new/ https://reviews.llvm.org/D121511 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits