cross compilation with custom Settings from ycm_extra_conf.py messes up target with clangd_completer.py

[PlasmaHH]

Hi,

I am not sure if I understand all the interactions correctly, but here is what I think is happening:

I have some non-standard needs to modify the cmd line of the arm-none-eabi-g++ call (e.g. add some -D or so) that is not present in the compile_commands.json. Thus I have a ycm_extra_conf.py which is loaded fine and returns the flags entry in the dict. An entry could look like this:

{ "flags" : [ "/home/plasmahh/opt/arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi/bin//arm-none-eabi-g++", 
"--driver-mode=g++", "-Wall", "-Wextra", "-std=gnu++2c" <and some more> ] }

Now this gets properly forwarded to ycmd/completers/cpp/clangd_completer.py through _SendFlagsFromExtraConf where it calls BuildCompilationCommand( settings['flags'] ).

Inside that function there is PrependCompilerToFlags() called which will remove the first entry and replace it by clang-tool so that in the end clangd sees something like:

{ "flags" : [ "clang-tool",  "--driver-mode=g++", "-Wall", "-Wextra", "-std=gnu++2c" <and some more> ] }

Now clangd (together with a proper --query-driver option) normally internally sets the target as well as the include paths according to the called compiler, the "driver". In this case it does not know anything about that we call the arm crosscompiler, thus things fail in at least the following ways:

• Wrong headers are being used (those from the system instead of the crosscompiler)
• Some defines set by the compiler for the target are wrong
• Options to the compiler like -mtune=cortex-m7 lead to some weird errors like "Request failed: -32001: invalid AST" (possibly because clangd calling the driver failed and thus it returns an empty result??)

Looking around the code I could not see a reason why the compiler call is replaced by the nonexsitant clang-tool.

Note: when you try things for yourself keep in mind to often delete the clangd .cache as somethings things seem to work or not work but its really because something was cached

When I let the BuildCompilationCommand just return the flags parameter things work for me.

As such if it was up to me I would completely get rid of the BuildCompilationCommand function and pass the setttings['flags'] that is the result of the ycm_extra_conf.py Setting() call as-is to clangd. Possibly the majority of users won't ever use that functionality and just pass on the compile_commands.json right away to clangd anyways, and for those that want total control, this gives them full control but also full reponsibility to get it right (well, not too hard as just copying verbatim the entries from compile_commands.json will work already).