This is an archive of the discontinued LLVM Phabricator instance.

Prepare ground for re-lexing modular headers.
AbandonedPublic

Authored by alexfh on Feb 15 2019, 4:03 AM.

Details

Summary

When a clang tool runs on a translation unit that uses modular headers, no
PPCallbacks will be invoked for the code in the modular headers (since they are
not parsed, but loaded as AST). Since some tools depend on PPCallbacks for all
transitively included headers, a solution is to re-lex the modular headers
from the sources stored along with AST inside module files. This patch makes it
possible to re-attach PPCallbacks from the compiler's Preprocessor to a custom
one that will be used to re-lex all transitively included headers. It also
updates clang-tidy checks to be compatible with this mode of operation.

Event Timeline

alexfh created this revision.Feb 15 2019, 4:03 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 15 2019, 4:03 AM
alexfh edited reviewers, added: sammccall; removed: klimek.Feb 18 2019, 8:08 AM

Friendly ping.

sammccall added inline comments.Feb 22 2019, 12:28 AM
clang/include/clang/Lex/PPCallbacks.h
346

This seems pretty tangly from a layering point of view, giving each object a reference to the other. I always find it hard to reason about ownership in such cases.

What about lifecycle methods beginPreprocessing(Preprocessor*) and endPreprocessing(Preprocessor*)? It will look similar in practice: subclasses that need it can still track the PP instance, but the circular references will only be there when needed, and will be explicit.

alexfh marked an inline comment as done.Feb 22 2019, 1:54 AM
alexfh added inline comments.
clang/include/clang/Lex/PPCallbacks.h
346

We can do that as well. However, adding another couple of overrides to each PPCallbacks implementation will result in quite some boilerplate. How would you look at creating an intermediate class in the PPCallbacks -> <users' PPCallbacks handlers> hierarchy that will handle beginPreprocessing/endPreprocessing and expose the preprocessor pointer via a protected getPreprocessor() method?

sammccall added inline comments.Feb 22 2019, 2:03 AM
clang/include/clang/Lex/PPCallbacks.h
346

I think that would probably obscure the intent, I really think this is subtle enough to be explicit, and would be only about as boilerplatey as today (the PP pointer is set by a method rather than in the constructor).

But I'm more concerned about the interfaces in Lex/ than the specific callsites in clang-tidy, so if such a helper class were private to clang-tidy, that seems ok.

alexfh abandoned this revision.Mar 21 2019, 4:01 AM

I've found an alternative way to deal with PPCallbacks when analyzing code in modular mode. See https://reviews.llvm.org/D59528. Abandoning this revision.