It's common for CLIs on macOS to read configuration files from more
unix-standard directories with either dotfiles directly in ~ or files in
~/.config. Previously macOS clangd configuration only read from
~/Library/Preferences on macOS, now it respects the other Unix
directories with XDG_CONFIG_HOME or just ~/.config as a fallback. This
is implemented by changing user_config_directory to
user_config_directories which sets a vector of paths to search,
maintaining the previous order of operations.
Details
- Reviewers
- None
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I got a couple of concerns about the general ideas in the change. Even though the convenience of using ~/.config/clangd/config.yaml seems nice, I think it'll just end up creating confusion in the long run.
According to various macOS developer documentation & QAs, canonical user config directory for applications are ~/Library/Preferences (see https://developer.apple.com/library/archive/qa/qa1170/_index.html#//apple_ref/doc/uid/DTS10001702-CH1-SECTION3 and various others).
Regarding XDG_CONFIG_HOME, AFAICT macOS doesn't really implement XDG Base Directory Specification, so querying its existence in that platform seems controversial.
Another concern is around multiple user config files. Clangd's config mechanism actually implements overriding of previous config options, and user config file is the most authoritative one and in the case of multiple such config files it's unclear which one should have precedence. So i don't think we should ever use "multiple" user config files.
cc @sammccall as he was the one that introduced this.
While this makes sense, I think the practical realities today are that ~/.config is always preferred by unix style tools, even when on macOS.
Regarding XDG_CONFIG_HOME, AFAICT macOS doesn't really implement XDG Base Directory Specification, so querying its existence in that platform seems controversial.
Yea I considered still omitting that one, but figured it was fair to simplify the compiler conditionals and assume that if someone had that variable set on macOS it was intentional. But I think it would be fine to exclude.
Another concern is around multiple user config files. Clangd's config mechanism actually implements overriding of previous config options, and user config file is the most authoritative one and in the case of multiple such config files it's unclear which one should have precedence. So i don't think we should ever use "multiple" user config files.
Yea this makes sense. Theoretically we could check these "search paths" to determine if the configs actually existed to make that more clear, but with --log=verbose the order of operations is clear where clangd is searching for these so I think that shouldn't be a common issue.