This is an archive of the discontinued LLVM Phabricator instance.

[Syntax] Build nodes for simple cases of top level declarations
ClosedPublic

Authored by ilya-biryukov on Nov 29 2019, 6:55 AM.

Details

Summary

More complicated nodes (e.g. template declarations) will be implemented
in the follow-up patches.

Diff Detail

Event Timeline

ilya-biryukov created this revision.Nov 29 2019, 6:55 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 29 2019, 6:55 AM
gribozavr2 accepted this revision.Dec 2 2019, 1:59 AM
gribozavr2 added inline comments.
clang/include/clang/Tooling/Syntax/Nodes.h
347

Why no semicolon, here and in other newly-added comments below? Seems like these syntax nodes cover the semicolon as implemented.

380

Isn't it a "nested name specifier" since C++17?

clang/lib/Tooling/Syntax/BuildTree.cpp
528

Why not also mark the message?

clang/unittests/Tooling/Syntax/TreeTest.cpp
517

Also add namespace a::b {} ?

692

Duplicate test? (There's one above that's exactly like this.)

This revision is now accepted and ready to land.Dec 2 2019, 1:59 AM
ilya-biryukov marked 5 inline comments as done.
  • Remove the duplicate test
  • Add 'message' to the node for static_assert
  • Handle nested namespace definitions, add them to the tests
clang/include/clang/Tooling/Syntax/Nodes.h
347

I was torn on this...
In the statement position, this semicolon is not consumed by declarations (instead, it's consumed by DeclarationStatement). However, it is consumed at the namespace and TU level.

I've decided to punt on this until we add accessors for the semicolon and add a comment to the corresponding accessors, explaining the percularities of its placement.

Decided to keep it out from the comment, since it's not present sometimes.

Don't have a strong opinion here, can add it back

380

nested-name-specifier is a qualifier
it's actually something like <nested-name-qualifier>? <identifier>. Which is quite verbose, so decided decided to go with <name> to keep it small for now.

May have to change to something more suitable when we actually start building syntax trees for names.

Does keeping <name> make sense for now? Do you think we should be more precise from the start?

Happy to go in either direction, actually.

clang/lib/Tooling/Syntax/BuildTree.cpp
528

Good point. Done.

We don't have a node for StringLiteral, but we're returning it as <expression> for now.

clang/unittests/Tooling/Syntax/TreeTest.cpp
517

Done. This was also broken, now fixed. Thanks for bringing this up.

692

Thanks! Totally accidental, did not notice this.

Build result: pass - 60626 tests passed, 0 failed and 726 were skipped.

Log files: console-log.txt, CMakeCache.txt

  • Do not call Builder.getRange() twice for namespaces

Build result: pass - 60626 tests passed, 0 failed and 726 were skipped.

Log files: console-log.txt, CMakeCache.txt

Landing as is, but happy to address any comments in the follow-up patches.
@gribozavr2, please feel free to leave any suggestions in the review comments, despite it being closed.

This revision was automatically updated to reflect the committed changes.

Updated version LGTM, thanks!

clang/include/clang/Tooling/Syntax/Nodes.h
347

It is fine to punt until later.

380

"name" != "identifier" so it is technically correct. Once we have accessors, they should have comments about what the actual options for the name are, and with that, I don't mind having just "name" here.