On Tue, 17 Oct 2017, David Malcolm wrote: > 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. > > foo.cc: error: 'myapi::foo' was not declared in this scope > foo.cc: note: 'myapi::foo" was declared in header 'myapi/private.h' > (included via 'myapi/public.h') when compiling 'bar.cc'; did you forget to > '#include "myapi/public.h"'? > > or somesuch. > > In any case, moving this to a class gives an easier way to locate the > hardcoded knowledge about the stdlib. > > The patch also adds similar code to the C++ frontend covering > unqualified names in the standard library, so that rather than just
I'd tend to expect hardcoded standard library knowledge, where it relates to symbols present for both C and C++, to be in a common c-family file (e.g. listing both C and C++ headers for each symbol, with the possibility of some symbols only having a header listed for one C and C++; most C symbols would have <foo.h> and <cfoo> listed, but some might be different, e.g. wchar_t being a keyword in C++ or clog being completely different in the two libraries). That reduces the chance of a symbol being gratuitously listed for one language only when such hints make sense for it in both languages. -- Joseph S. Myers jos...@codesourcery.com
