- Removed assumption that begin and end need to be in same file id.
- Fixes the crash at https://github.com/clangd/clangd/issues/113
Details
- Reviewers
sammccall kadircet - Commits
- rG280dccc54dc4: Merging r368058: --------------------------------------------------------------…
rL368407: Merging r368058:
rG8fbb6ce84782: Fixed toHalfOpenFileRange assertion fail
rL368058: Fixed toHalfOpenFileRange assertion fail
rCTE368058: Fixed toHalfOpenFileRange assertion fail
Diff Detail
- Repository
- rL LLVM
Event Timeline
Implemented function to get expansion range such that ends are both in the same file id.
clang-tools-extra/clangd/SourceCode.cpp | ||
---|---|---|
307 ↗ | (On Diff #213583) | nit: getExpansionTokenRangeInSameFile? |
315 ↗ | (On Diff #213583) | Having a little trouble parsing this comment... "Record the stack of expansion locations for the beginning, keyed by FileID"? |
316 ↗ | (On Diff #213583) | DenseMap<FileID, SourceRange> Why are the values SourceRange here and not just SourceLocation? |
318 ↗ | (On Diff #213583) | Is there a way to write this loop that better captures the intent? while(1) with a break in the middle is hard for readers to understand at a glance. I think it's just for (SourceLocation Begin = ExpansionRange.getBegin(); Begin.isValid(); Begin = Begin.isFileId() ? SourceLocation() : SM.getImmediateExpansionRange(Begin).getBegin()) BeginExpansions[SM.getFileID(Begin)] = Begin; |
323 ↗ | (On Diff #213583) | this call to toTokenRange seems unneccesary, that just adjusts End, but we only care about Start |
328 ↗ | (On Diff #213583) | again, I think by treating these as ranges rather than points you're making it harder than it needs to be. Traversing up the expansion tree isn't going to invert the order (though spelling might) |
333 ↗ | (On Diff #213583) | isn't this always SourceRange(It->second.getBegin(), EndExpansion.getEnd())? |
362 ↗ | (On Diff #213583) | nit: as with comments, avoid adding messages to the assertion unless it adds something to the code |
clang-tools-extra/clangd/SourceCode.cpp | ||
---|---|---|
316 ↗ | (On Diff #213583) | meant to say here: I think FileID is a legitimate key in a DenseMap, no need for unsigned (the DenseMapInfo<clang::FileID> specialization exists, which should make it work) |