[clangd-dev] Clangd on windows+vscode

Sun Jan 19 23:58:21 PST 2020

Hi Michael,

I assume you are making use of the query-driver I suggested in my last
email. Unfortunately, it doesn't extract builtin macros as they are more
hairy compared to headers.

Could you give more details about your problem, which predefined macro is
causing you troubles, what does your fix in clang.cpp involve?
Most of the builtin macros are actually set when initializing the
preprocessor, look for InitializePredefinedMacros
in clang/lib/Frontend/InitPreprocessor.cpp.
Maybe we can come up with a generic fix in there, rather than trying to
parse and redefine those macros in clangd.

On Sat, Jan 18, 2020 at 3:26 PM Michael Steinberg <michsteinb at gmail.com>
wrote:

> Hello,
>
> I'm sorry to reply so late too, only now I have a machine capable enough
> to quickly build clang ;)
> The clangd experience improved much in the meanwhile and I can use it in
> vscode with my embedded project. That being said, clangd seems to have the
> builtin GCC macros hardcoded, instead of detected by the gcc toolchain. It
> reports GCC version 4.2 in my case, although I have a GCC 8.2.1 installed.
> I believe that is because of Clang.cpp:5382. This is unfortunate if you
> need to differ between toolchains. As this controls the default for
> "-fgnuc-version", is there a way to supply that argument to clangd through
> the vscode plugin in addition to the stuff parsed from the
> compile_commands.json file? I tried mentioning it to the clangd-server, but
> that does not work. For now I hardcoded 8.2.1 into the clang sources. Also,
> would it perhaps be possible to detect and supply all the nuiltin macros
> from what the toolchain reports instead?
>
> Thanks and kind regards
> Michael Steinberg
>
>
> Am 05.09.2019 um 11:45 schrieb Kadir Çetinkaya:
>
> Hi Michael, sorry for the late reply this got lost in my inbox.
>
> We actually landed the mentioned support into clangd with
> https://reviews.llvm.org/D62804 you can find docs in
> https://clang.llvm.org/extra/clangd/Configuration.html#query-driver.
> Let me know whether it works for you.
>
> On Wed, Jun 12, 2019 at 3:47 PM Ilya Biryukov <ibiryukov at google.com>
> wrote:
>
>> Thanks for describing the setup. Clang is generally good at mocking GCC
>> rules for searching includes and such, but only for widely used targets
>> (e.g. gcc targeting linux).
>> However, this does not seem to work as nicely for less supported
>> toolchains (like the bare-metal arm toolchain you're using).
>>
>> +Kadir Çetinkaya <kadircet at google.com> is working on adding
>> a cquery-like configuration mechanism to clangd, that should address your
>> use-case. And in general, this seems to be a reasonable
>> fallback mechanism in case we hit a toolchain not well-supported by clang.
>> At the same time, adding better support for bare-metal arm into clang's
>> driver would give other benefits:
>> - other clang-based tools, like clang-tidy, would work without extra
>> configuration;
>> - would allow to more closely mimic various non-include-path flags, which
>> could also affect correctness for some corner cases;
>> - allow easy switching (no extra flags needed, etc) from gcc to clang for
>> the actual builds.
>>
>> But we don't plan to put more effort of the clangd team into the
>> bare-metal toolchain's driver. Hopefully someone else will improve this in
>> the future.
>>
>> On Tue, Jun 11, 2019 at 9:40 PM Michael Steinberg <michsteinb at gmail.com>
>> wrote:
>>
>>> Hi there,
>>>
>>> - I use cmake + ninja, which generates the necessary compile_commands
>>> file.
>>> - I mentioned cquery, which opts to query the compiler found in
>>> compile_commands for its builtins, as you can ask gcc to disclose them
>>> - I would prefer not to be locked into actually using clang to build the
>>> projects, and there are targets which clang does not support
>>> - I could live really well with clangd ignoring inline assembly and
>>> such, for which the syntax and availability of features differs between
>>> clang and gcc
>>>
>>> Kind Regards
>>> Michael
>>>
>>>
>>> Am 11.06.2019 um 16:13 schrieb Ilya Biryukov:
>>>
>>> We don't really have alternatives to compile_commands.json that support
>>> automatic indexing. You could use 'compile_flags.txt', but the
>>> auto-indexing won't know which files it should feed into.
>>>
>>> - What build system do you use and how did you generate the
>>> compile_commands.json file?
>>> - You mentioned ccls could index your project, did it work out of the
>>> box? If it required user configuration, what was it?
>>>
>>> Clangd relies on clang's code to parse command line, which is *mostly* compatible
>>> with GCC, but I'm not sure how it handles custom GCC toolchains (and
>>> whether it handles those at all).
>>> In general, if you manage to set up your build so that it uses clang and
>>> generate compile_commands.json from that configuration - it should work
>>> just fine.
>>>
>>>
>>>
>>> On Sat, Jun 8, 2019 at 8:59 PM Michael Steinberg via clangd-dev <
>>> clangd-dev at lists.llvm.org> wrote:
>>>
>>>> Hello again,
>>>>
>>>> is there maybe a way to add --include directives for the clangd indexer
>>>> only? I couldn't find any command line option for this :( I don't really
>>>> feel like adding around 400 defines through the commandline....
>>>>
>>>> Regards
>>>> Michael
>>>>
>>>>
>>>> Am 03.06.2019 um 11:52 schrieb Kadir Çetinkaya:
>>>>
>>>> Could you try adding "-log=verbose" to clangd args? Which can be done
>>>> by adding
>>>> ```
>>>> "clangd.arguments": [
>>>> "-log=verbose",
>>>> ],
>>>> ```
>>>> to your settings.json. Then you should see the diagnostics for those
>>>> uncompilable errors.
>>>>
>>>> Wild guess; it will most likely be fixed with:
>>>> https://reviews.llvm.org/D62804
>>>>
>>>> On Sun, Jun 2, 2019 at 7:40 PM Michael Steinberg via clangd-dev <
>>>> clangd-dev at lists.llvm.org> wrote:
>>>>
>>>>> Hi there,
>>>>>
>>>>> I'm trying to get clangd running inside vscode on windows. The project
>>>>> is using the gnu-arm-none-eabi toolchain. For almost all compilation
>>>>> units I get the error message "IndexingAction failed: has uncompilable
>>>>> errors". Is there any way to get more infos about the failure cause?
>>>>>
>>>>> Kind regards
>>>>> Michael
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> clangd-dev mailing list
>>>>> clangd-dev at lists.llvm.org
>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev
>>>>>
>>>> _______________________________________________
>>>> clangd-dev mailing list
>>>> clangd-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Ilya Biryukov
>>>
>>>
>>
>> --
>> Regards,
>> Ilya Biryukov
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20200120/42dbbf5f/attachment.html>