[PATCH] D106394: [clang][pp] adds '#pragma include_instead'

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D106394#2923186 <https://reviews.llvm.org/D106394#2923186>, @dblaikie wrote:

> In D106394#2922972 <https://reviews.llvm.org/D106394#2922972>, @rsmith wrote:
>
>> ... As an alternative, have you considered checking whether any of the headers named in the pragma are in the include stack, and warning if not? That would seem to make this warning applicable to both user headers and system headers in an unsurprising way. We'd presumably need two lists of headers: the external headers that we encourage people to include to get at the implementation detail header, and the internal list of headers that are also allowed to use it but that we shouldn't list in the diagnostic.
>
> Yeah, @cjdb and I discussed this offline last week - a main concern with that direction is the maintenance burden that'd add to libc++ when using one of the internal implementation headers, having to update the "internal list of headers" every time a new include is added.

It seems to me that this is at least only a linear factor more work: when you add a `#include`, you need to update the list of permitted includers in that file. (This is assuming that your permitted includers list contains only (a) the list of headers to tell the user about and (b) the list of *direct* includers in libc++.)

> (we speculated that maybe something akin to a modulemap could be used - found with a similar search path that would be able to describe once a single set of headers (but I guess that only works if all the headers are in a partitioned subdirectory - otherwise who gets to own the top-level file that has these lists of names - I guess maybe each file could say "I'm part of library foo" and then from the file search for foo.headerlist file and use that to describe which are the public and private headers to implement the warning) - but no doubt that's overkill/not likely feasible)

Perhaps a much simplified version of this could work: permit an inclusion only if the file is found by relative path or if it's found in the same include path as an earlier file in the include stack. (So, once you enter `/usr/include/c++/v1` you can include any header within it; it's only edges from outside -> inside that have this enforcement applied to them.)

Alternatively, perhaps we could use the existing module map infrastructure for this? Treating these headers as private textual headers would seem to have the right semantics without requiring any in-source-file annotations. For that, we'd presumably want to change Clang's default (modules disabled) mode from ignoring all module maps to parsing module maps but treating all headers in them as textual, or something along those lines.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106394