[clangd-dev] Clangd on windows+vscode
Michael Steinberg via clangd-dev
clangd-dev at lists.llvm.org
Sat Jan 18 06:26:46 PST 2020
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
> <mailto: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 <mailto: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 <mailto: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
>> <mailto: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
>>> <mailto: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
>>> <mailto: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 <mailto: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/20200118/8536d8f0/attachment.html>
More information about the clangd-dev
mailing list