Re: [PATCH] C/C++: more stdlib header hints (PR c/81404)

[Martin Sebor <msebor at gmail dot com>]

On 10/17/2017 11:33 AM, David Malcolm wrote:
> This patch depends on:
>
> * "[PATCH] c-family: add name_hint/deferred_diagnostic (v2)"
>   * https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01021.html
>   (waiting review)
>
> * [PATCH 3/3] C: hints for missing stdlib includes for macros and types
>   * https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00125.html
>   (approved, pending the prereq above)
>
> It extends the C frontend's "knowledge" of the C stdlib within
> get_c_name_hint to cover some more macros and functions, covering
> a case reported in PR c/81404 ("INT_MAX"), so that rather than printing:
>
>   t.c:5:12: error: 'INT_MAX' undeclared here (not in a function); did you mean '__INT_MAX__'?
>    int test = INT_MAX;
>               ^~~~~~~
>               __INT_MAX__
>
> we instead print:
>
>   t.c:5:12: error: 'INT_MAX' undeclared here (not in a function)
>    int test = INT_MAX;
>               ^~~~~~~
>   t.c:5:12: note: 'INT_MAX' is defined in header '<limits.h>'; did you forget to '#include <limits.h>'?
>   t.c:1:1:
>   +#include <limits.h>
>
>   t.c:5:12:
>    int test = INT_MAX;
>               ^~~~~~~
>
> It also adds generalizes some of the code for this (and for the "std::"
> namespace hints in the C++ frontend), moving it to a new
> c-family/known-headers.cc and .h, and introducing a class known_headers.
> This currently just works by scanning a hardcoded array of known
> name/header associations, but perhaps in the future could be turned
> into some kind of symbol database so that the compiler could record API
> uses and use that to offer suggestions e.g.

I think this feature will be especially helpful for the not
so common symbols or those that are often expected to be
declared in the wrong header.  As you say, the data structure
can be improved/enhanced and made more general.  Until that
happens, it would be great to complete the set of the standard
symbols.  Since the full list is going to be quite long, it
might be worthwhile to sort it so it can be searched using
a binary search.

Btw., while on the subject of enhancements, I think it would
also be helpful to make the preprocessor aware of the set of
predefined macros and have it issue warnings in cases where
they are either used in nonsensical or error-prone ways.  One
example that I've had trouble with is making mistakes testing
the C++ __cplusplus macro for equality that can never be true,
as in the contrived:

  #if __cplusplus == 2014
  // C++ 14 code
  #else
  // other code
  #endif

(The real problems usually involve several non-trivial tests
not all of which get tested.)

Martin