Why does user config have the highest precedence instead of the lowest?

[khuldraeseth]

From the docs, I see that the order of precedence is user config > inner project > outer project. The order fragments are applied in practice matches, with user config coming last. I would expect inner > outer > user instead, to allow each project to provide its own .clangd that can override whatever opinionated configuration I have in my user config.

A concrete example is this very project. I have the clang-tidy check modernize-use-trailing-return-type enabled in my user config, but the clangd source doesn't use trailing return types. A project configuration Diagnostics.ClangTidy.Remove: modernize-use-trailing-return-type does not remove the check because it's applied before the check is added.

[HighCommander4]

I suspect the thinking is that project configuration is likely to be checked into the project's repository and thus shared by all developers, and individual developers may want to be able to override aspects of the shared configuration.

You can add things to user config that only apply to one project, as follows:

// previous fragments of config file

---

If:
  PathMatch: /path/to/project

Key: Value

[khuldraeseth]

It still feels backwards to me. The project configuration would be checked in because it's the proper configuration to use for the project, and individual developers overriding anything would only cause headache. Why have a user config at all, if it'll have to be edited anyway for each project?

[Katzeee]

I'm confused too. That means my global remove clang-tidy flags may remove the flags set for the project.

[emilyyyylime]

+1. This is totally backwards. I want to have access to C++20 so I have -std=c++20 in my user flags but now I want to work on a C project and just. Can't? Because there is no way for me to remove the flags in the project config