[PATCH] D53354: [WIP][NOT FOR COMMIT][PROTOTYPE] clang-scan-deps: dependency scanning tool rough prototype

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added inline comments.


================
Comment at: lib/Lex/FilterToIncludes.cpp:628
+  First = Id.Last;
+  auto Kind = llvm::StringSwitch<TokenKind>(Id.Name)
+                  .Case("include", pp_include)
----------------
arphaman wrote:
> arphaman wrote:
> > ddunbar wrote:
> > > What is our feeling w.r.t. _Pragma, which can in theory influence the preprocessor. I'm not sure this model can sanely support it?
> > We need to look into that. In the worst case we can always avoid minimizing the file if it has a _Pragma anywhere in it.
> We also have to handle cases like this one:
> 
> foo.h:
> ```
> #define PP _Pragma
> ```
> 
> bar.h:
> ```
> PP ("foo")
> ```
> 
> Unfortunately this can't be handled by just disabling minimization for `foo.h` as PP will be stripped out from `bar.h`. Furthermore, this pattern is quite reasonable, so we should expect it in the code we receive. Right now I can't think of a reasonable solution for this problem.
> 
> There's also a more "evil" case:
> 
> ```
> #define P(A, B) A##B
> 
> P(_Pra,gma)("foo")
> ```
> 
> It would be reasonable to introduce a warning for the use of `_Pragma` token that was created using PP token concatenation and just hope that our users won't use this pattern.
One possible solution to the first issue is to simply fallback to the regular -Eonly invocation if we detect an include of a file that has a macro with a `_Pragma` in it. Then we could emit a remark to the user saying that their build could be faster if they rewrite their code so that this pattern no longer occurs.


Repository:
  rC Clang

https://reviews.llvm.org/D53354