Not handling this was a side-effect of being overly cautious when trying
to avoid reading files for which clangd doesn't have the source mapped.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp | ||
---|---|---|
353 | why are we breaking the loop if we hit another file ID, rather than just not checking it? | |
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h | ||
219–221 | I do wonder a how hard it would be to approach this more directly: (conditionally )use some API for pulling code out of the SourceManager that *won't* silently do IO. Up to you whether to look at this at all of course, this approach is better than what we have now. | |
clang-tools-extra/clangd/ParsedAST.cpp | ||
312–313 | this part of the comment seems stale | |
clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp | ||
276 | you may want a case with two levels of expansion |
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h | ||
---|---|---|
219–221 | I gave this a try in the updated patch. |
Sorry for taking a while to come back to this again. A bit chaotic right now :-)
Looks good, some further simplification possible.
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp | ||
---|---|---|
299 | This seems more complicated than necessary - e.g. it replicates the "invalid" handling from SourceManager::getCharacterData, when we just bail out in this case. And keeping the raw char* interfaces seems unfortunate if we're going to the trouble of reimplementing most of this anyway. What about implementing llvm::Optional<StringRef> getBuffer(FileID File, bool AllowIO)? This is simpler than the current function, and the caller can be a bit more expressive/simpler like: unsigned Offset = SM.getFileOffset(Loc); StringRef RestOfLine = Data.substr(Offset).split('\n').first; StringRef PrevLine = Data.substr(0, Offset).rsplit('\n').first.rsplit('\n').second; | |
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h | ||
224 | nit: I'd use AllowIO=true to avoid the negative sense, up to you. |
Thanks for the suggested simplification. As the change is not completely trivial, could you have one more look before landing?
Thanks a lot!
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp | ||
---|---|---|
301 | nit: the peer function to reference is SourceManager::getBufferData |
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp | ||
---|---|---|
708–711 | If you insist, I can move them to a separate patch. I don't want to leave it unmodified because the change will come back every time someone touches the file. |
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp | ||
---|---|---|
708–711 | I don't personally care about this too much, but the changes are somewhat distracting in review, blame etc. The policy we've mostly followed is to format changed lines only (git clang-format, turn format-on-save off) and leave misformatted code alone until it's next touched. (Not sure if LLVM offers any guidance either way, but that's what Google does internally and IME it's been great) |
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp | ||
---|---|---|
708–711 | The issue I have with that is that turning format-on-save off means you inevitably end up doing a lot of manual formatting as you write the code. With format-on-save, you can just write the tokens for a statement not caring about the formatting, do a save, and have the statement be formatted before you start writing the next one. |
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp | ||
---|---|---|
708–711 | I guess what we really want is "format on save for modified lines only". I found a VSCode extension which does that, I'll give that a try. |
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp | ||
---|---|---|
708–711 | What I do (apart from when i forget) is run git clang-format before creating the patch, Then just don't worry about formatting while I'm writing the code. |
I do wonder a how hard it would be to approach this more directly: (conditionally )use some API for pulling code out of the SourceManager that *won't* silently do IO.
ContentCache::getRawBuffer() or something?
Up to you whether to look at this at all of course, this approach is better than what we have now.