ArcsinX wrote:
> I intentionally did not change the hashing when
> `--background-index-path-mapping` is disabled, because that would invalidate
> _all_ existing caches when someone switched to a version with this change.
> But that hash is based on the raw file path in the generating client (and
> thus it cannot be reused).
It seems we're coming to the conclusion that the current implementation isn't
exactly path mapping, but rather a functionality for creating and using a
specially prepared index. There are a number of restrictions on how the index
should be created and used. A solution with a separate conversion tool seems
more appropriate, as any conversion errors will be immediately visible. While
these won't be the standard tools, your current solution also uses custom index
preparation scripts. Speaking about performance, index conversion (changing the
path inside the idx file + renaming taking into account the new hash for the
path) doesn't seem to take very long (compared to indexing time).
> Just to make sure we are on the same page, the user would have to specify
> something like
> `--background-index-path-mappings=/my/path=/TOKEN_ONE,/other/path=/TOKEN_TWO`,
> correct? If the _same_ token is specified it makes sense on store, but not
> necessarily on load.
Yes, I'm talking about this case. It can be like
`${workspaceFolder}=/TOKEN1,/usr/include/c++/9=/TOKEN2,...` and in this case
seems user needs manually specify non-workspace paths taking into account his
system/compiler/SDK paths
https://github.com/llvm/llvm-project/pull/180285
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
