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

Is this a TODO comment?

1095–1098
1099–1100
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

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

1080–1082
clang/lib/ASTMatchers/Dynamic/Parser.cpp
372 ↗(On Diff #319431)
373 ↗(On Diff #319431)
435 ↗(On Diff #319431)
449 ↗(On Diff #319431)

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?

491 ↗(On Diff #319431)
510 ↗(On Diff #319431)
521 ↗(On Diff #319431)
553 ↗(On Diff #319431)

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

563 ↗(On Diff #319431)
638–641 ↗(On Diff #319431)
691 ↗(On Diff #319431)
clang/lib/ASTMatchers/Dynamic/Registry.cpp
580

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.

654

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
654

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
397–406

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?

1093
clang/lib/ASTMatchers/Dynamic/Parser.cpp
373 ↗(On Diff #320593)
449 ↗(On Diff #320593)
606 ↗(On Diff #320593)

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.