Details
Diff Detail
- Repository
- rCTE Clang Tools Extra
- Build Status
Buildable 14659 Build 14659: arc lint + arc unit
Event Timeline
This looks OK so far, where is it going? It doesn't make sense to put URIs in if we only ever use file:.
I guess others will be produced by some kind of extension point on SymbolCollector. That will specify URI schemes we should try, allow you to replace the whole toFileURI, or something else?
Unfortunately there's a bunch of Uris here, where the existing code uses URI...
clangd/index/Index.h | ||
---|---|---|
27 | nit: FileURI? | |
clangd/index/SymbolCollector.cpp | ||
29 | this combines or better, "resolves relative paths against \p FallbackDir" | |
36–37 | also URI here, and below | |
219 | while here, would you mind changing GetSymbolLocation -> getSymbolLocation? | |
clangd/index/SymbolYAML.cpp | ||
51 | more URI |
clangd/index/Index.h | ||
---|---|---|
27 | I tend to use Uri for URI strings and URI/U for URI objects. But I'd be okay with either, if you prefer URI. |
I was thinking about leaving URI scheme customization to the postprocessing phase, but you are right, it would be better to make the URI scheme extendable in SymbolCollector.
Great, this all makes sense. I think we can/should make the scheme selection a bit more robust (we shouldn't crash if we get unexpected filenames).
And... Uri or URI (I really think this is a usability issue - i had a scarring experience with a codebase that couldn't decide how to spell abbreviations...)
clangd/index/Index.h | ||
---|---|---|
27 | I'm fine with either spelling, but not really with mixing the two. Is there some precedent for using different capitalization depending on the variable type? That seems... non obvious to me. | |
clangd/index/SymbolCollector.cpp | ||
70 | this doesn't seem unreachable? | |
clangd/index/SymbolCollector.h | ||
38 | We should document the semantics/exceptions in case of failure. One scheme that would be flexible and I think pretty simple:
For our monorepo we can set this to {"google", "file"} or just {"google"} if we never want to leak local paths. It seems pretty plausible that other orgs whose builds aren't totally hermetic would want several schemes here. | |
unittests/clangd/SymbolCollectorTests.cpp | ||
49 | while renaming this, maybe Decl is better? we'll have Def soon! | |
199 | Can you add a test for the case when the path fails to convert to the URI scheme? |
clangd/index/Index.h | ||
---|---|---|
27 | I'm +1 on URI, using all capital letters for initialisms can make the name a bit easier to read. Let's be consistent using URI? |
clangd/index/Index.h | ||
---|---|---|
27 | I'll change to URI. Another reason why I avoided using URI as variable names was the name conflicts with the actual URI class... I always need to come up with a prefix... |
- s/Uri/URI/
- Address review comments. Support multiple schemes.
- Merged with origin/master
- Merge branch 'master' of http://llvm.org/git/clang-tools-extra into uri
unittests/clangd/SymbolCollectorTests.cpp | ||
---|---|---|
280 | leftover logs |
- removed leftover logs.
- Merge branch 'master' of http://llvm.org/git/clang-tools-extra into uri
nit: FileURI?
(The other style is OK too, though I personally find it harder to read. But the class is URI and we should be consistent)