This is an archive of the discontinued LLVM Phabricator instance.

[LibTooling] Add NodeId, a strong type for AST-matcher node identifiers.
AbandonedPublic

Authored by ymandel on Mar 13 2019, 1:55 PM.

Details

Reviewers
ilya-biryukov
Summary

The standard matcher API uses StringRefs to identify bound nodes. This patch
introduces a strong type thats allows distinguishing ids from arbitrary text in
APIs. It additionally adds a templated version which can indicate the AST type
to which the id is bound.

This patch is the second in a series intended to improve the abstractions
available to users for writing source-to-source transformations. A full
discussion of the end goal can be found on the cfe-dev list with subject "[RFC]
Easier source-to-source transformations with clang tooling".

Event Timeline

ymandel created this revision.Mar 13 2019, 1:55 PM
ymandel updated this revision to Diff 190675.Mar 14 2019, 11:03 AM
This comment was removed by ymandel.
ymandel updated this revision to Diff 190679.Mar 14 2019, 11:09 AM

"Revert" to original diff. This undoes the previous diff, which associated with the wrong revision.

gentle ping...

ilya-biryukov added inline comments.
clang/include/clang/Tooling/Refactoring/NodeId.h
30

What are the use-cases for passing a custom id to this class?
If the purpose is to hide the IDs from the user, exposing this constructor seems to be against this goal.

clang/lib/Tooling/Refactoring/NodeId.cpp
13

NIT: change to using namespace for consistency

25

Suggestion from @klimek :

could we get the unique string by printing a pointer of this instead?
(And disallow copies and moves of this class for this to be correct)

Could you provide the rationale for having NodeID vs just using strings for the binds?
Is this just a more type-safe way to do the same thing or is that actually required to solve a particular problem?

ymandel abandoned this revision.May 21 2019, 6:20 AM
ymandel marked an inline comment as done.
ymandel added inline comments.
clang/include/clang/Tooling/Refactoring/NodeId.h
30

If there are errors relating to the id (say, referencing it in a stencil when it wasn't bound in the match), the errors are hard to understand when the id is auto-generated. In general, I'd say that best practice is to explicitly specify the id so that dynamic failures print a meaningful id. The default constructor is a compromise and perhaps shouldn't be exported.

that said, if we could find another way to give good error messages (for example, if we could somehow grab the line number of the declaration), then the default construction would be the preferred approach.