labath added a comment.
It seems to me that it would be better to decentralize the warning tracking.
Also due to a central list of all possible warnings not being modular, but
mainly because I can imagine that some warnings may want to be reported with
different "scopes" -- once per target, thread, module (this is the case of the
"dwp missing" warning) or whatever. That won't work if the list is managed
centrally in the debugger object. We could define some token `warn_once` type
(maybe just a typedef to once_flag or atomic_flag) that would have to be passed
to the warning emitting function. The function would handle the actual "once"
logic, and the scope of the token variable would determine the frequency of the
warning.
My second remark is that this does not help with the warnings that are not tied
to a specific debugger instance -- such as those coming from the module parsing
code. I don't know if you have a need to display those (I know I don't), but it
may be nice to set things up so that we're able to transmit those as well -- I
believe we are able to do that for progress events.
================
Comment at: lldb/include/lldb/Core/DebuggerEvents.h:91
+ : DiagnosticEventData(DiagnosticEventData::Type::Warning, diagnostic,
+ std::move(message), once){};
+
----------------
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D121511/new/
https://reviews.llvm.org/D121511
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits