Also introduce Expr::tryEvaluateStrLen.
thanks for this! mostly just nits from me
Looks like this is the second "try to evaluate the call to this builtin function" API endpoint we have here (the other being for __builtin_object_size). IMO this isn't an issue, but if we need many more of these, it might be worth considering exposing a more general Expr::tryEvaluateBuiltinFunctionCall(APValue &, ASTContext &, BuiltinID, ArrayRef<Expr>) or similar.
nit: i'd rename this ComputeExplicitObjectSizeArgument
nit: would const Expr * work here? clang prefers to have const where possible
i expected ComputeCheckVariantSize to imply that the argument was to a _chk function, but these cases don't reference _chk functions (nor do we set IsChkVariant = true;). should this be calling ComputeSizeArgument instead?
same "shouldn't this be ComputeSizeArgument?' question
for completeness and consistency, please include a case where this warning doesn't fire.
at the same time, it'd be nice to test for an off-by-one (which i believe is handled correctly by this patch already); maybe shorten src to "abcd" and have a test on char dst2; that doesn't fire?
I just didn't find the extra verbiage helpful. AFAICT this code could be used for purposes other than issuing a diagnostic, and a diagnostic could be issued after following either the fast or slow path, so it didn't make a lot of sense to me. But if you have a different preference for this comment let me know.
Maybe the name ComputeCheckVariantSize was misleading and it'll be more clear now that I'm changing the name, but these functions like strncat, the memcpys below, and snprintf, etc, all take an explicit size argument just like the _chk functions.