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

Wed Jul 21 09:15:54 PDT 2021

cjdb added a comment.

In D106394#2892832 <https://reviews.llvm.org/D106394#2892832>, @sammccall wrote:

> This is pretty interesting from a tooling perspective!
>
> Some prior art here are the include-what-you-use "pragmas" <https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUPragmas.md> (magic comments). Clangd supports `// IWYU pragma: "private", include "public.h"` which has similar semantics to that proposed here.
>
> Having multiple alternatives makes this less useful to tools as it's ambiguous what the correct action/fix is. It's necessary for the standard library and the syntax doesn't really encourage it, so that seems OK. Worst case, tools can ignore the pragmas when several are present.

Hmm... I like prior art. That clangd supports it suggests that there's a section of code I can look at for inspiration if we were to replace this pragma with the IWYU comment-pragma (I wonder why they didn't just go with `#pragma IWYU ...`?).

Is it reasonable for a compiler to interpret comments and issue/adjust diagnostics based on those comments? I thought that was the purpose of a pp-pragma.

> Eventually this seems like a reasonable thing to want for user code. What are your motivations for restricting it to system headers? (And do you think people in future will be tempted to lift them?)
> FWIW in the short term in clangd it's not that useful for the standard libraries, as we can enumerate all the symbols and that will work with libstdc+, MS stdlib...
>
> For user code it's worth thinking about how the alternatives are specified - in the standard library a literal string `<utility>` is correct, but in user code you may rather want a path to the correct *file* (relative to the current file) which can then be turned into a spelled `#include` according to the including file's header search path.

Louis' answer is wholesale correct, at least for now. If someone wants to extend the design to support "groups", then I'll happily consider the design; that's not something I've been able to provide a trivial solution to (it usually just comes back to redesigning `-fmodules`).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106394