This is an archive of the discontinued LLVM Phabricator instance.

Add clang-query support for mapAnyOf
ClosedPublic

Authored by steveire on Jan 17 2021, 10:10 AM.

Diff Detail

Event Timeline

steveire requested review of this revision.Jan 17 2021, 10:10 AM
steveire created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJan 17 2021, 10:10 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
aaron.ballman accepted this revision.Jan 19 2021, 7:16 AM

LGTM aside from some minor nits.

clang/lib/ASTMatchers/Dynamic/Marshallers.h
1081 ↗(On Diff #317229)

Is this a TODO comment?

1095–1098 ↗(On Diff #317229)
1099–1100 ↗(On Diff #317229)
This revision is now accepted and ready to land.Jan 19 2021, 7:16 AM

@aaron.ballman Please review this again as I've merged some more needed changes into it.

aaron.ballman added inline comments.Feb 1 2021, 6:40 AM
clang/include/clang/ASTMatchers/Dynamic/Registry.h
36–37 ↗(On Diff #319431)
40 ↗(On Diff #319431)

I think it'd be cleaner to make callers be explicit about forming the smart pointer.

clang/lib/ASTMatchers/Dynamic/Marshallers.h
586–587 ↗(On Diff #319431)

Might as well make it obvious the function doesn't care about its arguments (same elsewhere in the patch).

1081–1083 ↗(On Diff #319431)
clang/lib/ASTMatchers/Dynamic/Parser.cpp
394
395
434
447–448

The comment is a bit misleading in that this doesn't parse the .bind part, only the ("foo") bits.

Also, why does the function now accept BindToken but not use it?

490
509
520
552

unique_ptr? or is this our custom smart pointer? Either way, please spell the type out.

562
639–642
717
clang/lib/ASTMatchers/Dynamic/Registry.cpp
580 ↗(On Diff #319431)

I think that having the explicit ctor call here would make it more obvious that the .release() is being picked up by another smart pointer type.

697 ↗(On Diff #319431)

Any reason this declaration needed to move?

steveire updated this revision to Diff 320593.Feb 1 2021, 2:00 PM

Update

clang/lib/ASTMatchers/Dynamic/Registry.cpp
697 ↗(On Diff #319431)

It's used after the if-else.

I think there should be some documentation change for the new with functionality.

clang/lib/ASTMatchers/Dynamic/Marshallers.h
398–407 ↗(On Diff #320593)

Rather than repeat these degenerate definitions six times, should this just be the default implementation within MatcherDescriptor (so derived classes are not required to override them)? Alternatively, should we make a NonBuilderMatcherDescriptor class that holds the degenerate definition, and these derived classes can inherit from NonBuilderMatcherDescriptor instead?

1094 ↗(On Diff #320593)
clang/lib/ASTMatchers/Dynamic/Parser.cpp
372
448
605

I think there should be some documentation change for the new with functionality.

It's already documented in https://clang.llvm.org/docs/LibASTMatchersReference.html , just like all the other functionality.

@aaron.ballman Any further comments?

@aaron.ballman Any further comments?

Thank you for pinging, this fell off my queue! The only further comments I have about about my confusion with with.

I think there should be some documentation change for the new with functionality.

It's already documented in https://clang.llvm.org/docs/LibASTMatchersReference.html , just like all the other functionality.

Perhaps I'm blind, but when I search for "with" on that page, I get 21 hits and none of them are about the with() function. I am not finding evidence of with being supported on ToT, can you point me to the existing implementation? (If the functionality isn't being introduced in this patch, you don't need to document as part of this work. However, I was under the impression you were adding this functionality, so I'd like to understand this situation better before approving.)

That page collapses the documentation for each matcher, as you know.

You need to expand the docs for mapAnyOf, as you know.

You seem to know all this. What's the remaining issue?

aaron.ballman accepted this revision.Feb 5 2021, 6:07 AM

That page collapses the documentation for each matcher, as you know.

You need to expand the docs for mapAnyOf, as you know.

You seem to know all this. What's the remaining issue?

The issue was that this was not at all obvious to me as a code reviewer, so I was asking you for help. Your response comes across as patronizing, but thank you for giving me the information I was looking for. FWIW, I did not know this was under the mapAnyOf matcher and I was assuming this was going to be documented at the top level, just like bind().

LG.

That page collapses the documentation for each matcher, as you know.

You need to expand the docs for mapAnyOf, as you know.

You seem to know all this. What's the remaining issue?

The issue was that this was not at all obvious to me as a code reviewer, so I was asking you for help. Your response comes across as patronizing, but thank you for giving me the information I was looking for. FWIW, I did not know this was under the mapAnyOf matcher and I was assuming this was going to be documented at the top level, just like bind().

LG.

You reviewed the patches for mapAnyOf up to now and you reviewed this change which has unit tests using with. I didn't know what was unclear to you. Sorry for being terse.

Thanks for the review.

This revision was landed with ongoing or failed builds.Feb 7 2021, 7:46 AM
This revision was automatically updated to reflect the committed changes.