Browse Source
In preparation for compiling with -Wunused-parameter, we'd like to be able to annotate some function parameters as false positives (e.g., parameters which must exist to conform to a callback interface). Ideally our annotation will: - be portable, turning into nothing on platforms which don't support it - be easy to read, without looking too syntactically odd or taking attention away from the rest of the parameters - help us notice when a parameter marked as unused is actually used, which keeps our annotations accurate. In theory a compiler could tell us this easily, but gcc has no such warning. Clang has -Wused-but-marked-unused, but it triggers false positives with our MAYBE_UNUSED annotation (e.g., for commit-slab functions) This patch introduces an UNUSED() macro which takes the parameter name as an argument. That lets us tweak the name in such a way that we'll notice if somebody tries to use it. It looks like this in use: int some_ref_cb(const char *refname, const struct object_id *UNUSED(oid), int UNUSED(flags), void *UNUSED(data)) { printf("got refname %s", refname); return 0; } Because the unused parameter names are rewritten behind the scenes to UNUSED_oid, etc, adding code like: printf("oid is %s", oid_to_hex(oid)); will fail compilation with "oid undeclared". Sadly, the "did you mean" feature of modern compilers is not generally smart enough to suggest the "unused" name. If we used a very short prefix like U_oid, that does convince gcc to say "did you mean", but since the "U_" in the suggestion isn't much of a hint, it doesn't really help. In practice, a look at the function definition usually makes the problem pretty obvious. Note that we have to put the definition of UNUSED early in git-compat-util.h, because it will eventually be used for some compat functions themselves (both directly here and in mingw.h). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>maint
Jeff King
2 years ago
committed by
Junio C Hamano
1 changed files with 6 additions and 0 deletions
Loading…
Reference in new issue