[PATCH] D119004: [NFC][analyzer] Allow CallDescriptions to be matched with CallExprs

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

In D119004#3299971 <https://reviews.llvm.org/D119004#3299971>, @NoQ wrote:

> The original `lookup()` isn't exactly precise either, it's just slightly more precise as it has better access to path-sensitive information such as current values of function pointers, but this doesn't necessarily help given that these pointers can still be unknown. And when the information is not available the lookup silently fails in both cases.
>
> But I can certainly get behind demotivating callers from calling the new function unless they know what they're doing. Maybe `lookupAsWritten()` to indicate that the function intentionally ignores the runtime state of the program and looks at the syntax only?

I still don't see the benefit of introducing another API.
This is actually a difference between the `CallEvent` and a `CallExpr`, thus it has not much to do with the `CallDescription`. For choosing the right `matches()` overload inherently depends on knowing about the parameter, on which we overload on.
We should have this as a comment for the type `CallEvent`, and I'm okay with reminding users even at the `matches(CallExpr)` overload.
I'm still heavily against introducing a new API instead of an overload.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119004