This is an archive of the discontinued LLVM Phabricator instance.

Comment Sema: Eliminate or factor out DeclInfo inspection (NFC)
Needs ReviewPublic

Authored by aaronpuchert on Nov 12 2021, 12:24 PM.

Details

Reviewers
gribozavr2
Summary

We make all predicates expect an already inspected DeclInfo, and
introduce a function to run such a predicate after inspecting it.
Checks that were only used once have been inlined.

Before every call to inspectThisDecl the caller was checking IsFilled,
so we move that into the function itself.

Diff Detail

Event Timeline

aaronpuchert requested review of this revision.Nov 12 2021, 12:24 PM
aaronpuchert created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptNov 12 2021, 12:24 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
aaronpuchert added inline comments.Nov 13 2021, 4:25 AM
clang/include/clang/AST/CommentSema.h
207

Another idea for naming: hasDeclThat, then calls read like hasDeclThat(isOfSomeKind).

Sorry, here I also find the old code to be more readable.

  • I don't see a problem with checks that are only used once. They are encapsulated in functions with meaningful names, making the code more readable. Compare Sema::checkFunctionDeclVerbatimLine before and after, for example.
  • checkDecl looks like a too complex abstraction for the task at hand: it accepts a function pointer (and it is incorrect for the user to call those other functions directly), it hardcodes the result value of false when the decl is not available etc.

Sorry, here I also find the old code to be more readable.

Admittedly this isn't mainly about readability but about reducing boilerplate. A large number of functions start like this:

if (!ThisDeclInfo)
  return false;
if (!ThisDeclInfo->IsFilled)
  inspectThisDecl();

The diffstat is 95 insertions, 208 deletions.

  • I don't see a problem with checks that are only used once. They are encapsulated in functions with meaningful names, making the code more readable. Compare Sema::checkFunctionDeclVerbatimLine before and after, for example.

Agreed, though you'll find I've basically only inlined one- or maybe two-liners. Having them in-place reduces the number of visual jumps in the code flow. Maybe isFunctionPointerVarDecl is worth preserving though.

  • checkDecl looks like a too complex abstraction for the task at hand: it accepts a function pointer

Perhaps that's an issue with the name? I suggested hasDeclThat, then it's clear that this takes a predicate. Also reads almost like a proper sentence: hasDeclThat(isXXX).

(and it is incorrect for the user to call those other functions directly),

Not quite true, as you can see I'm calling many of these functions directly. We go through checkDecl only if we don't know if ThisDeclInfo is available.

it hardcodes the result value of false when the decl is not available etc.

Would hasDeclThat address that concern?

aaronpuchert added inline comments.Nov 26 2021, 1:39 PM
clang/lib/AST/CommentSema.cpp
135–137

Something might be wrong here anyway: the documentation says that @callback

Specifies the name and description of a callback field in a structure.

But we're looking for a VarDecl instead of a FieldDecl. Is somebody still around who knows HeaderDoc? Seems like Apple doesn't care any longer.

Rename checkDecl to hasDeclThat, which should hopefully address most issues.

We leave isFunctionPointerVarDecl inlined for now, since it's probably wrong anyway. (I think we should look for fields.)