This is an archive of the discontinued LLVM Phabricator instance.

[include-cleaner] Better support ambiguous std symbols
ClosedPublic

Authored by hokein on Feb 13 2023, 5:49 AM.

Details

Summary

By special-casing them at the moment. The tooling stdlib lib doesn't
support these symbols (most important one is std::move).

Diff Detail

Event Timeline

hokein created this revision.Feb 13 2023, 5:49 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 13 2023, 5:49 AM
hokein requested review of this revision.Feb 13 2023, 5:49 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 13 2023, 5:49 AM
kadircet added inline comments.Feb 13 2023, 6:47 AM
clang-tools-extra/include-cleaner/lib/FindHeaders.cpp
104

nit: else if

110

we also need to account for exporters, similar to findHeaders. might be worth lifting that branch to a free-function.

182

rather than doing this here and bailing out early, i think we should just augment the Headers below, after locateSymbol and findHeaders is run.

that way we'll make sure rest of the logic applies in the future without special casing (e.g. we've some fixmes for treating implementation locations for stdlib symbols as providers, in such a scenario this early exits would create non-uniformity).
it also implies we'll need to think about hints to attach here, which seems consistent with rest of the logic again (as we still assign hints to headers derived from stdlib recognizer).

so what about an alternative with a signature like: llvm::SmallVector<Hinted<Header>> headersForSpecialSymbols(S, SM, PI); then we can just initialize Headers with a call to it?

hokein updated this revision to Diff 497110.Feb 13 2023, 2:15 PM
hokein marked 3 inline comments as done.

address comments

hokein added inline comments.Feb 13 2023, 2:16 PM
clang-tools-extra/include-cleaner/lib/FindHeaders.cpp
182

i think we should just augment the Headers below, after locateSymbol and findHeaders is run.

I'm not sure about it. Looks like this is subtle, it creates discrepancies for standard symbols, these special std symbols will have the underlying header as alternative while other normal std-recognizer symbols not. I think it would be better to be consistent for all std symbols.

kadircet accepted this revision.Feb 14 2023, 12:39 AM

thanks!

clang-tools-extra/include-cleaner/lib/FindHeaders.cpp
85

we actually need to nullcheck for PI here, defaulting to PublicHeader when it isn't present.

86

nit: maybe unwrap this? e.g:

if (PI->isPrivate(..) ... ) return Hints::None;
return Hints::PublicHeader;
95

we need to nullcheck for PI here

134

can you also wrap this in applyHints(..., Hints::CompleteSymbol), similar to what locateSymbol does for rest of the stdlib symbols

This revision is now accepted and ready to land.Feb 14 2023, 12:39 AM
hokein updated this revision to Diff 497233.Feb 14 2023, 12:58 AM
hokein marked 2 inline comments as done.

handle the case where PI is null.

hokein marked an inline comment as done.Feb 14 2023, 12:59 AM

Thanks for the review!

clang-tools-extra/include-cleaner/lib/FindHeaders.cpp
85

ah, I think we can make it a reference, all callsites can guarantee the PI is nonnull.

This revision was landed with ongoing or failed builds.Feb 14 2023, 1:18 AM
This revision was automatically updated to reflect the committed changes.