[PATCH] D88833: [clang-tidy] Do not warn on pointer decays in system macros

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D88833#2319118 <https://reviews.llvm.org/D88833#2319118>, @fiesh wrote:

> @aaron.ballman valid point.  It would seem natural to diagnose both since the user is voluntarily causing the decay?

I'm on the fence. If the argument to the function is one that's defined by a system header, you could argue that the user isn't voluntarily causing the decay -- they're using the API they were given by the system. If you're calling a user-defined function with that argument, then you could say that the user could change their function signature to remove the decay. If you're calling a system-defined function with that argument, then there's really nothing the user can do except add a cast that they'll likely view as useless. So at the very least, I think if the function declaration and the argument to the function are in a system header, then we shouldn't warn.

I think for a user-declared function, my intuition is that using an argument from a system header which causes decay is pretty uncommon but that we should follow the same behavior for the argument as we do for predefined expressions like `__PRETTY_FUNCTION__`. Because the argument is outside of the user's control, asking them to jump through hoops with their function declaration seems like it wouldn't likely add a lot of value. However, I'm not firmly tied to that. For user-declared functions, I just want to make sure we treat `__PRETTY_FUNCTION__` and `SYS_STRING` consistently.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88833