This allows efficiently accessing all expansions (without iterating over each
token and searching), and also identifying tokens within a range that are
affected by the preprocessor (which is how clangd will use it).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
auto
clang/lib/Tooling/Syntax/Tokens.cpp | ||
---|---|---|
427 | FileID is a bit awkward: then you have to have some way to specify which expansions you're interested in (or get those for the whole file and filter them yourself). We could add an overload for this, but I think Buf.expansionsAffecting(Buf.spelledTokens(FID)) is pretty acceptable for this case. (MarkedFile can't be used in an API because it's private) |
Thanks. This LGTM, but I think I don't have enough experience to accept revisions and could miss something important. So, may be @kadircet could accept it if its OK for him.
thanks, mostly LG with a comment about some edge case. just wanna know what you think.
clang/include/clang/Tooling/Syntax/Tokens.h | ||
---|---|---|
281 | this sounds more like expansionsAffected rather than affecting ? maybe my mental model requires correction, but it feels like spelled tokens are not affected by expansions, it is the other way around. maybe even expansionsSpawned or triggered? this is definitely non-blocking though, i am just bikesheding, comment is explanatory enough in any case. | |
clang/lib/Tooling/Syntax/Tokens.cpp | ||
251–252 | these two are also asserted in fileForSpelled | |
251–252 | maybe move that into fileForSpelled too ? (to ensure Spelled is contained within the returned file) | |
427 | this might be inconistent with spelledForExpanded from time to time, e.g: #define FOO(X) 123 #define BAR void foo() { FOO(BA^R); } normally BAR has no expansions, but I think it will get merged into outer macro expansion e.g. 123 coming from FOO(BAR). (whereas spelledForExpanded will treat BAR in isolation) not sure an important limitation but something to keep in mind. |
clang/include/clang/Tooling/Syntax/Tokens.h | ||
---|---|---|
281 | Either mental model works I think. Mine is that expansions are rewrite rules - you start with a stream of tokens, and then each expansion mutates it, and you end up with different ones. Renamed to expansionsOverlapping which seems more neutral and consistent with expansionStartingAt | |
clang/lib/Tooling/Syntax/Tokens.cpp | ||
427 | I don't understand the consistency you're looking for - AFAICS these are different functions that do different things - spelledForExpanded is much higher level. Is there something in the name or comment I can add/remove to clarify?
Tokens don't really "have expansions" - they're *part of* expansions. Generally expansionsOverlapping() will return the expansions themselves that are overlapping, while spelledForExpanded will include the expanded tokens if the whole expansion is in-range. The former is a building-block (returning Expansions seems like a clear indicator of that) that will usually require some postfiltering, while the latter is fairly directly usable. |
thanks, LGTM! (and loved the choice of overlapping)
clang/lib/Tooling/Syntax/Tokens.cpp | ||
---|---|---|
427 |
yeah expansionsOverlapping() will return the expansions themselves that are overlapping bit made my reasoning a little more solid, i am still thinking with the spelled tokens might expand mindset but I suppose spelled tokens might be part of expansions is a better reasoning. I don't think any extra comments are necessary, at least in this layer. |
this sounds more like expansionsAffected rather than affecting ? maybe my mental model requires correction, but it feels like spelled tokens are not affected by expansions, it is the other way around.
maybe even expansionsSpawned or triggered?
this is definitely non-blocking though, i am just bikesheding, comment is explanatory enough in any case.