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
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to