[clangd-dev] Automatically adding includes always inserts the full path on windows

Kadir Çetinkaya via clangd-dev clangd-dev at lists.llvm.org
Tue Jun 4 00:46:13 PDT 2019


Yeah naming is a bit unfortunate, but this is also used in the logic for
generating include header strings in clangd, see
https://github.com/llvm-mirror/clang-tools-extra/blob/master/clangd/Headers.cpp#L196
.

On Tue, Jun 4, 2019 at 9:29 AM Ilya Biryukov <ibiryukov at google.com> wrote:

> Hi Stefan,
>
> Thanks for reporting this. I don't think any of the active clangd
> developers run on Windows, so bugs like this can easily go unnoticed.
> To add to what Kadir was requesting, could you point to a particular point
> in code that does the string comparison? If some of the strings come from
> user input (e.g. flags to the compiler), we should definitely normalize
> them before comparisons.
>
> @Kadir Çetinkaya <kadircet at google.com>, does your change also cover
> non-diagnostic use-cases? The function name looks very diagnostic-specific
>
> On Mon, Jun 3, 2019 at 8:20 PM Stefan Lietzau via clangd-dev <
> clangd-dev at lists.llvm.org> wrote:
>
>> Hi there,
>>
>>
>>
>> I’m using clangd with vscode on windows with the option to add includes
>> when autocompleting symbols. However the inserted include is always
>> absolute, even if the file is present in the include path
>> (compile-commands.json generated by CMake). I tracked the problem down to a
>> path comparison where one path coming from the compilation database
>> contains forward slashes and the other path (header where the symbol
>> definition was found) contains backslashes. Since this is a simple string
>> comparison it fails and determines the header is not part of the include
>> directories.
>>
>>
>>
>> I don’t think the best fix would be to convert the paths before
>> comparison or use a better comparison. Instead I think this is something
>> that needs to be fixed deep inside clang tooling. That means I think the
>> paths returned by the compilation database should be in a predictable
>> format.
>>
>>
>>
>> What do you guys think?
>>
>>
>>
>> Kind regards
>>
>>
>>
>> *Stefan*
>>
>>
>> _______________________________________________
>> clangd-dev mailing list
>> clangd-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev
>>
>
>
> --
> Regards,
> Ilya Biryukov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20190604/6a652027/attachment.html>


More information about the clangd-dev mailing list