haoNoQ wrote:
> Overall, this looks good to me. In general, we sometimes report errors in
> system headers because a warning in a system header (e.g., a null
> dereference) might be the result of the user code doing something bad. But in
> this particular case, I believe it is very unlikely that the user code is to
> blame.
>
> But wait for at least one more perspective on this before merging.
Yes I think it's actually surprisingly unlikely with this checker specifically.
One way this could happen is if the system header provides a template algorithm
to do something with your class, which involves calling a method on your class,
and in the case of your specific class this method happens to be virtual.
Eg. something like
```c++
struct AbstractSortedContainer {
virtual Iterator begin() = 0;
virtual Iterator end() = 0;
AbstractSortedContainer(...) {
llvm::sort(*this);
}
};
```
where `llvm::sort()` comes from system headers. (It won't work with `std::sort`
because `std::sort` requires you to pass `this->begin(), this->end()` from the
outside.)
But either way I haven't seen such code ever in my life. I think it's probably
ok if we miss it.
https://github.com/llvm/llvm-project/pull/184183
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
