This is an archive of the discontinued LLVM Phabricator instance.

[include-cleaner] Add the missing parts of Symbol and Header clases.
ClosedPublic

Authored by sammccall on Oct 25 2022, 12:23 PM.

Diff Detail

Event Timeline

sammccall created this revision.Oct 25 2022, 12:23 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 25 2022, 12:23 PM
sammccall requested review of this revision.Oct 25 2022, 12:23 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 25 2022, 12:23 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
sammccall updated this revision to Diff 471143.Oct 27 2022, 5:54 AM

Add comment on variant/enum order match.

kadircet accepted this revision.Oct 27 2022, 6:17 AM
kadircet added inline comments.
clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
49

nit: how about implementing this with std::visit? it's definitely more code, but at least makes sure:

  • we won't depend on the order in Kind matching the Storage, and
  • we'd get a hard compiler error when a new variant is introduced without proper handling here

it would look like:

Kind kind() const {
  struct KindTranslator {
      Kind operator()(Decl *) { return Declaration; }
      ...
  };
  return std::visit(KindTranslator{}, Storage);
}

but not feeling so strongly about it, so feel free to keep as is if needed (I don't think we'll add tons of more kinds later on, so the chances of introducing bugs is small. but using new language/library constructs sounds fun).
(same for Header)

55

nit: I think it would be better to spell out the types here (and above), rather than rely on what Kind would translate into

61

nit: any particular reason for dropping const here?

This revision is now accepted and ready to land.Oct 27 2022, 6:17 AM
sammccall marked an inline comment as done.Oct 27 2022, 6:43 AM
sammccall added inline comments.
clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
49

This is a bunch more code to read, is no longer a trivial accessor when compiled. It does look canonical, but I think this speaks more to std::variant being not great (we don't have a lot of experience with it yet).

It's not *that* much more safe, the error enum {A, C, B} can still be expressed as

Kind operator()(A*)  { return A; }
Kind operator()(B*)  { return A; /*oops*/ }

It's silghtly more locally obvious, but it's buried in a bunch of boilerplate.

(It also leans into addressing variants with types, as I mentioned below)

55

This seems backwards to me: the compiler will check that the type is correct, but can't check that the alternative we're fetching matches the accessor we're defining.
This version places declaration() and Declaration next to each other so such a mistake is obvious.

(As a design question, I think we should to name variants rather than access them with types when this is ergonomic, e.g. it's perfectly reasonable to model header=physical/verbatim/stdlib as variant<FileEntry*, StringRef, StringRef>. Languages that take variants seriously tend to prefer this)

61

Oh, the constructor was nonconst so I assumed const was an oversight. Changed to const everywhere.

thanks, i agree with your comments around std::variant, let's see what kind of patterns will emerge in the future.

so, still LG, but please address the triple slash issue and const-ness before landing

clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
40

triple slashes (here and elsewhere)

61

i guess you forgot to upload the diff? (the constructor was definitely an oversight, thanks for noticing that)

This revision was automatically updated to reflect the committed changes.
sammccall marked 2 inline comments as done.