Useful when positions are used to target nodes, with before/after ambiguity.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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
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
clang/lib/Tooling/Syntax/Tokens.cpp | ||
---|---|---|
270 | NIT: add braces around if statement |
clang/lib/Tooling/Syntax/Tokens.cpp | ||
---|---|---|
260 | NIT: why not Right->location() <= Loc instead of !(Loc < Right->location)? | |
261 | Maybe compare offsets instead of locations? It always feels weird to compare source locations for anything other than storing them in std::map |
clang/lib/Tooling/Syntax/Tokens.cpp | ||
---|---|---|
260 | Yes, we only have operator< :( |
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. | |
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
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. |
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. |
clang/lib/Tooling/Syntax/Tokens.cpp | ||
---|---|---|
270 | Yeah, so LLVM style is unclear, but has examples with no braces. 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
clang/lib/Tooling/Syntax/Tokens.cpp | ||
---|---|---|
261 |
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. |
clang/lib/Tooling/Syntax/Tokens.cpp | ||
---|---|---|
270 | Ah, great, we're on the same page then! |
Maybe llvm::Optional<> here?