[PATCH] D90270: [clangd] Handle absolute/relative path specifications in Config

Sam McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Oct 28 07:39:10 PDT 2020


sammccall accepted this revision.
sammccall added inline comments.
This revision is now accepted and ready to land.


================
Comment at: clang-tools-extra/clangd/ConfigCompile.cpp:75
   llvm::SourceMgr *SourceMgr;
+  // Directory containing the fragment. Absolute path with forward slashes, with
+  // a trailing slash or empty for user-config fragments.
----------------
nit: associated with again (or just "normalized Fragment::SourceInfo::Directory")


================
Comment at: clang-tools-extra/clangd/ConfigCompile.cpp:162
               return false;
+            llvm::StringRef Path = P.Path;
+            // Ignore the file if it is not nested under Fragment and strip the
----------------
maybe pull out a method `Optional<StringRef> configRelative(StringRef)`?
This would avoid the duplication


================
Comment at: clang-tools-extra/clangd/ConfigCompile.cpp:168
+            if (!FragmentDir.empty())
+              Path.consume_front("/");
             return llvm::any_of(*PathMatch, [&](const llvm::Regex &RE) {
----------------
not needed as you've ensured FragmentDir ends with a slash


================
Comment at: clang-tools-extra/clangd/ConfigProvider.cpp:67
+  // Directory associated with this fragment.
+  std::string Dir;
 
----------------
nit: Directory matching Fragment.Source.Directory?
(the abbreviation isn't terrible but consistency is nice)


================
Comment at: clang-tools-extra/clangd/ConfigProvider.cpp:124
       std::vector<CompiledFragment> Result;
-      Cache.read(FS, DC, P.FreshTime, Result);
+      Cache.read(FS, DC, P.FreshTime, Fragment::SourceInfo::Absolute, Result);
       return Result;
----------------
kadircet wrote:
> sammccall wrote:
> > this seems like a surprising place to encode this choice (why is fromYAMLFile coupled to the idea that it's a global config file not associated with any dir?)
> It was mostly because the only user of `fromYAMLFile` was user-config provider. Would you rather have this as an additional parameter instead?
> 
> I can't see any other way of updating that information directly from the user, apart from changing the interface of `Provider` to have some sort of `setPathSpec` method.
Yes, I'd prefer this to be a parameter (I suppose the dir seems slightly cleaner than a boolean).
The fact that user-config is the only user seems like a coincidence, I'd rather express the decision at that level.

(On the other hand, the fact that RelFileProvider *does* set Dir isn't a coincidence, it seems OK to hardcode that)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90270/new/

https://reviews.llvm.org/D90270



More information about the cfe-commits mailing list