This is an archive of the discontinued LLVM Phabricator instance.

[Tooling/Syntax] Helpers to find spelled tokens touching a location.
ClosedPublic

Authored by sammccall on Dec 11 2019, 6:40 AM.

Diff Detail

Event Timeline

sammccall created this revision.Dec 11 2019, 6:40 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 11 2019, 6:40 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
kbobyrev added inline comments.Dec 11 2019, 7:02 AM
clang/include/clang/Tooling/Syntax/Tokens.h
320

Maybe llvm::Optional<> here?

clang/lib/Tooling/Syntax/Tokens.cpp
254

Nit: maybe mention this requirement in the header comment?

257

Nit: "Comparing SourceLocations within one file using operator less/< is a valid operation"? Can't come up with something better, but this is slightly hard to understand.

262

Nit: static casts here or in variable declarations?

267

The formatting looks weird here, does it come from Clang-Format?

Unit tests: pass. 60699 tests passed, 0 failed and 726 were skipped.

clang-format: fail. Please format your changes with clang-format by running git-clang-format HEAD^ or apply this patch.

Build artifacts: console-log.txt, CMakeCache.txt, clang-format.patch, test-results.xml, diff.json

sammccall marked 6 inline comments as done.

comments

clang/include/clang/Tooling/Syntax/Tokens.h
320

Pointers are the idiomatic way to express "optional, by-reference" in LLVM.

By contrast, optional<Token&> is illegal, and optional<token*> is unidiomatic

clang/lib/Tooling/Syntax/Tokens.cpp
254

It is mentioned - Loc must be a spelling location.

257

done (I think). FileID rather than file here, because it's not true (or at least not clear) about files.

262

Replaced with an explicit ternary instead, which is (maybe) clearer?

Unit tests: pass. 60699 tests passed, 0 failed and 726 were skipped.

clang-format: pass.

Build artifacts: console-log.txt, CMakeCache.txt, test-results.xml, diff.json

kbobyrev marked an inline comment as done.Dec 12 2019, 1:29 AM
kbobyrev added inline comments.
clang/include/clang/Tooling/Syntax/Tokens.h
320

Ah, I see, I thought a copy is quite cheap in this case. Makes sense then.

clang/lib/Tooling/Syntax/Tokens.cpp
254

Ah, okay, I didn't know that spelling location implies exactly this property, my bad.

kbobyrev accepted this revision.Dec 12 2019, 1:29 AM
This revision is now accepted and ready to land.Dec 12 2019, 1:29 AM
ilya-biryukov added inline comments.Dec 12 2019, 1:39 AM
clang/lib/Tooling/Syntax/Tokens.cpp
270

NIT: add braces around if statement

ilya-biryukov added inline comments.Dec 12 2019, 1:43 AM
clang/lib/Tooling/Syntax/Tokens.cpp
260

NIT: why not Right->location() <= Loc instead of !(Loc < Right->location)?
Do we only overload operator < for SourceLocations?

261

Maybe compare offsets instead of locations?
It might be more code, but it would read much cleaner.

It always feels weird to compare source locations for anything other than storing them in std::map

kbobyrev added inline comments.Dec 12 2019, 2:18 AM
clang/lib/Tooling/Syntax/Tokens.cpp
260

Yes, we only have operator< :(

sammccall updated this revision to Diff 233550.Dec 12 2019, 2:45 AM

Add overloads for SourceLocation comparison, and document when they're meaningful.

sammccall updated this revision to Diff 233557.Dec 12 2019, 2:56 AM
sammccall marked 10 inline comments as done.

braces

clang/include/clang/Tooling/Syntax/Tokens.h
320

Ah, it is, so Optional<Token> would be an option. But the address is meaningful - spelled tokens have contiguous storage that indicates their sequence. So returning a pointer is actually more useful.

clang/lib/Tooling/Syntax/Tokens.cpp
261

I find the SM.getFileOffset(...) everywhere pretty hard to read and obscures the actual locations.
But agree about the operators, I've added the rest. Having operator< is pretty evil, but I don't think the others are particularly incrementally evil.

270

Is there some reference for preferred LLVM style for this, or personal preference? (Real question, as this comes up a bunch)

I ask because that's my *least*-preferred option - no braces > braces on for > braces on both > braces on (only) if.

Added braces to the for (maybe that's what you meant?)

Unit tests: pass. 60699 tests passed, 0 failed and 726 were skipped.

clang-format: pass.

Build artifacts: console-log.txt, CMakeCache.txt, test-results.xml, diff.json

kbobyrev added inline comments.Dec 12 2019, 3:18 AM
clang/lib/Tooling/Syntax/Tokens.cpp
270

I guess it's a personal preference (also for me), but I don't think there is a strict guideline on that. Interestingly enough, I think there is a piece of code in the styleguide that looks exactly like the code you had: https://llvm.org/docs/CodingStandards.html#turn-predicate-loops-into-predicate-functions

Some Clang subprojects tend to put braces everywhere though.

That being said, I guess no braces at all would be the best option here.

ilya-biryukov marked an inline comment as done.Dec 12 2019, 3:20 AM
ilya-biryukov added inline comments.
clang/lib/Tooling/Syntax/Tokens.cpp
261

I find it to be the only way to write code, which unambiguously says what it wants to do with source locations.

Not saying it's pretty, but I the source location API was designed to be used this way. Arguably, using something else in special corner cases does more harm than good (hard-to-read, non-conventional code).

But up to you.

270

Not sure if it's in LLVM style guide, but files inside Syntax folder definitely use this style: put braces everywhere until you reach the last level of nesting for non-leaf statements (i.e. having other statements as children, e.g. loops,. if statements, etc)

It's my personal preference, happy to discuss whether having this makes sense.

ilya-biryukov added inline comments.Dec 12 2019, 3:22 AM
clang/lib/Tooling/Syntax/Tokens.cpp
270

Yeah, so LLVM style is unclear, but has examples with no braces.
Could be the argument to get rid of those.

I'd still stick to my personal preferences where I can, but if everyone thinks no braces is better, happy to go with this option.

Unit tests: pass. 60699 tests passed, 0 failed and 726 were skipped.

clang-format: pass.

Build artifacts: console-log.txt, CMakeCache.txt, test-results.xml, diff.json

sammccall marked 6 inline comments as done.Dec 12 2019, 3:37 AM
sammccall added inline comments.
clang/lib/Tooling/Syntax/Tokens.cpp
261

But up to you.

I would rather use the operators, with the comment for the unusual usage, if that's OK.

(I agree it doesn't generalize and about the intent of the APIs, but think the APIs hurt readability to the extent that there's less value in consistency than in clear intent at individual callsites).

270

I think we're good here - I'm fine with the braces on for, and it sounds like that's what you wanted.
(I guess I misread "braces around if statement" as "braces around if body")

This revision was automatically updated to reflect the committed changes.
sammccall marked 2 inline comments as done.
ilya-biryukov marked an inline comment as done.Dec 12 2019, 4:51 AM
ilya-biryukov added inline comments.
clang/lib/Tooling/Syntax/Tokens.cpp
270

Ah, great, we're on the same page then!