[analyzer] Copy-constructor should trigger a load for check::Location

[steakhal]

Recently I was investigating a new diagnostic caused by #72107 ([analyzer] Switch to PostStmt callbacks in ArrayBoundV2).

Eventually drilled down to this:

class Obj {};
void top() {
  Obj buf[10];
  Obj copy(buf[404]); // No issue with ArrayBound, but ArrayBoundV2 reports this
  (void)copy;
}

I was wondering if there is something wrong with check::Location given that we now report this with the PostStmt<ArraySubscriptExpr> callback.
It turns out that the copy-constructor takes the parameter by reference - no surprise. Consequently, there is no lvalue to rvalue conversion (aka. we don't have a read operation). However, one could argue that a copy-constructor should really do a load of the argument passed, thus begs the question:
Shouldn't we force model a "load" for copy-constructor, move-constructor, copy-assignment, move-assignment?

Any opinions?

[llvmbot]

@llvm/issue-subscribers-clang-static-analyzer

Author: Balazs Benics (steakhal)

Recently I was investigating a new diagnostic caused by #72107 ([analyzer] Switch to PostStmt callbacks in ArrayBoundV2).

Eventually drilled down to this:

class Obj {};
void top() {
  Obj buf[10];
  Obj copy(buf[404]); // No issue with ArrayBound, but ArrayBoundV2 reports this
  (void)copy;
}

I was wondering if there is something wrong with check::Location given that we now report this with the PostStmt<ArraySubscriptExpr> callback.
It turns out that the copy-constructor takes the parameter by reference - no surprise. Consequently, there is no lvalue to rvalue conversion (aka. we don't have a read operation). However, one could argue that a copy-constructor should really do a load of the argument passed, thus begs the question:
Shouldn't we force model a "load" for copy-constructor, move-constructor, copy-assignment, move-assignment?

Any opinions?