NoQ marked an inline comment as done.
NoQ added inline comments.

================
Comment at: 
clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h:186
+  /// ranges.
+  void addRange(SourceRange R) {
+    assert((R.isValid() || Ranges.empty()) && "Invalid range can only be used "
----------------
gribozavr wrote:
> NoQ wrote:
> > gribozavr wrote:
> > > Ranges should be associated with a message.
> > Mmm, what do you mean?
> > 
> > Currently these ranges are attached to the warning message, path note 
> > messages can't have ranges, and extra path-insensitive notes can have a 
> > separate set of ranges attached to them by passing them through `addNote()`.
> I see. What looks weird to me is that methods related to the warning itself 
> are on `BugReport`, but notes and fixits are their own data structures. It 
> creates an inconsistent API, and makes notes and fixits feel bolted on.
> 
> Do you think it would make sense to change the API to be more uniform?
Hmm, i guess this is an artifact of how path-sensitive checkers usually emits 
warnings and their respective notes in completely different parts of their code 
(warnings come from the checker itself, path notes are generated by so-called 
"bug visitors" which aren't necessarily even a part of the checker).

Generally we need our notes to be attached to their respective warnings; say, 
in HTML report they need to be displayed on the same HTML page. But yeah, we 
should make our APIs more uniform because there's an obvious duplication of 
effort.

I also suspect that we'll need a new API in general, because in the current 
shape the `BugReporter` will look fairly alien and overly-complicated to 
clang-tidy developers that are used to the conciseness of `diag() << ...`. I'm 
not sure if it'll boil down to providing convenient wrappers or i'll prefer to 
rewrite our checkers as well. I think we should talk about this separately on 
the mailing list.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66572/new/

https://reviews.llvm.org/D66572



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to