This will allow the IncludeCleaner to suppress warnings on the lines with "IWYU
pragma: keep".
Clang APIs are not very convinient, so the code has to navigate around it.
Differential D114072
[clangd] Record IWYU pragma keep in the IncludeStructure kbobyrev on Nov 17 2021, 2:06 AM. Authored by
Details This will allow the IncludeCleaner to suppress warnings on the lines with "IWYU Clang APIs are not very convinient, so the code has to navigate around it.
Diff Detail
Event TimelineComment Actions It's annoying that we see comments and inclusion directives out-of-order, we can try fixing it on the parser side (I think it is incidental that these are issued in that order currently, they are eagerly trying to generate a fix/diagnostic for tokens after a pp-directive. hence we can first issue the PP callback, and then diagnose for rest of the line instead). So I'd suggest just building a side table information about these interesting comments/pragmas we see as we go, and then merge them with rest of the information we've built inside RecordHeaders::EndOfMainFile. WDYT? Comment Actions Sorry for forgetting about this one. Hopefully I can still help now by disagreeing with Kadir and creating an awkward stalemate instead. I agree that the ownership situation is ugly, but I think a single object here is still simpler. Partly because the ordering isn't some weird coincidence (see below)
Comment Actions Didn't really address this part
That's a more general approach for sure. But it does seem there's some complexity: what is the data structure and how do we merge it back into the graph. (e.g. are we going to record line numbers of each #include in the graph for this merging?) So let's think about the concrete cases:
The TL;DR is that each of these either stand alone, or we see the directive before the inclusion it describes in a way that's easy to keep track of incrementally. So I'm not really seeing much implementation difficulty to justify trying to move the directives and inclusion processing apart. Export seems basically similar. We're going to see the pragma immediately before the directive. Begin/end is a bit different. The stateful solution looks like: keep a Set<FileID> where exports are turned on, mutate it when you see a directive, and check it when you seen an inclusion. Private I think we have to treat as a standalone directive that mutates the current file, and the reference to another file is treated as a string. It's not a file the PP has necessarily seen. So the result is a map<file, string> and it seems adequate for this to be written straight into IncludeStructure.
Comment Actions
Haha, always welcome!
Right, I suppose it makes sense when you look at the "construct being finalized" perspective.
Definitely, but we are not going to get rid of that extra complexity no matter which solution we go with. We still need to store some extra state about these comments, the only difference is when we process them & whether we store just the latest or the whole set.
Yeah these are the cases I had in mind, but didn't really think about them thoroughly.
Yup, I guess this one looks pretty much the same for both approaches. Comment Actions Fix failures, address review comments.
Comment Actions thanks, LGTM! sorry for taking so long.
|
I suppose the comment needs updating too. (it no longer returns nor requires extra comment handler insertion).
Inserts a PPCallback and CommentHandler that'll populate this structure. ?