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