[cfe-dev] Adding indexing support to Clangd

[Alex L via cfe-dev]

Apologies, U does stand for Unified :). But I believe that my points still
stand.

On 15 August 2017 at 08:33, Alex L <arphaman at gmail.com> wrote:

>
>
> On 15 August 2017 at 07:57, Vladimir Voskresensky via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>>
>>
>> On 14.08.2017 11:06, Ilya Biryukov wrote:
>>
>> Could you provide more info, please.
>>> Are USRs different for same named file-local entries (i.e. static
>>> functions)?
>>>
>>
>> Looking at USRGenerator::VisitVarDecl, it seems they will be the same
>> across different translation units.
>> For local entities, "location" is part of the USR.  ("Location" is a
>> filename + an offset from the start of that file).
>>
>> That was my point, U in USRs are not so Unified, so can not be used as
>> universal keys for queries in DB.
>> Adding location to USR makes them less usable in index if fast
>> incremental re-index is going to be implemented vs. full reparse on each
>> change.
>>
>> Vladimir.
>>
>
> U is meant to be unique. USRs file-local declarations like static
> functions will include the filename only. USRs for function-local
> declarations will also include the offset in the file, but they're not
> actually indexed. There are a couple of global declarations that include
> file + offset in the USR as well - ObjC class extensions, some embedded tag
> decls (not that common), template parameter names (not actually indexed) &
> macros (not indexed).
>
> What exactly prevents unique strings from being used as keys for queries?
>
> Are filenames are a problem for the incremental re-indexing? If they
> aren't, then there are probably way to work around the file offsets in USRs
> for the incremental re-indexing, especially given how uncommon they
> actually are.
>
> Alex
>
>>
>> --
>> Regards,
>> Ilya Biryukov
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170815/90dc90f2/attachment.html>