Support deterministic relative include path in .clangd file

[cloudhan]

It seems there is no mechanism to support relative path expansion. For example

CompileFlags:
  Add:
  - -Iinclude/path/relative/to/.clangd

.clangd file can generally check into the repo, then the repo path will not be deterministic, adding a mechanism to dynamically determine the path will be greatly helpful.

For (a poor) example

Var:
  dot_clangd_path: dirname(__FILE__) 
CompileFlags:
  Add:
  - -I${dot_clangd_path}/include/path/relative/to/.clangd

So when you open some subdirectory, those portion of config will still work correctly.

Note that I never have it work correctly with relative include path. So I do not have idea whether will it work and how it works.

[HighCommander4]

Doesn't the compiler perform relative path expansion at the time it processes the -I argument?

[cloudhan]

Then relative to what? When you open a subdirectory of a project that might have some .clangd files nested deep, and red squiggle occurs, I bless you have time to figure it out.

So when a relative path occurs in the configuration, where does it relative to should be made clear in the document. If it is relative to the current working directory where the clangd server starts up, then there should be a way to specifiy where you exactly want it to relative to, regardless of the execution environment of the clangd server instance.

[HighCommander4]

I expect it would be interpreted relative to the directory in which the compile command is invoked, i.e. the "directory" field of the entries in compile_commands.json.

[sam-mccall]

The compile command is basically a pair {working directory, argv}. When argv are parsed by the driver, relative paths are resolved against the working directory.

First: what are you really trying to do?
If you have no compilation database, you should use compile_flags.txt instead of .clangd, this will set the working directory (as it sets rather than modifies the flags).
Are you trying to patch the compile commands from an existing CDB, to add extra includes?

The CompileCommands section in .clangd file modifies the argv textually, we can't reasonably say "relative paths are resolved against .clangd where they're specified, as the config parser doesn't even know which args specify paths (they're just strings).

Things we could possibly do:

• provide a semantic config option like AddIncludeDirectory: foo that would be equivalent to CompileFlags: Add: -I/absolute/path/foo.
• provide a config option to override the working directory for the compile command (though this would mess up relative paths specified in other places)
• support some textual expansion like in your example

[cloudhan]

Sometimes I don't have CBD, because it requires extra work or the build system does not support generating it. I do it for patching a subdirectory (for example, opencl code). I find a .clangd file can be the last resort and can be very useful in this case. But not that useful if I cannot check it into the VCS. So to checkin, the relative path should be properly handled first.

So I think textual expansion just fit in this case. And it can be simplified as

CompileFlags:
  Add:
  - -I${__FILE__}/../include/path/relative/to/.clangd

I think this change will be minimal. After loading, expand every string value and then form a static config.

[cloudhan]

compile_flags.txt doesn't fit the case because I use If block to pattern match files.

Anyway, If someone can finialize a design, I can implement it myself and contribute a PR :)

[dabeibao]

Really need this if compilation database is not available.
Otherwise looks like need to adjust .clang file every time I move code to another location.

[fneddy]

+1

[koval64]

+1

[adenisonafifi]

Would appreciate this functionality. For now I have added a bash script to generate the .clangd file for each user so the include paths are correct for their repository checkout path. Would be great to be able to commit the .clangd file to the repo and avoid requiring a setup script.

[freqmod]

I made a review for a solution to this https://reviews.llvm.org/D142981

[miguno]

+1 to what @adenisonafifi said in the comment at #1038 (comment)