-
Notifications
You must be signed in to change notification settings - Fork 26
Cleanup spans with references to non-existing files #49
Description
The issue comes up due to the newly implemented find implementations feature.
Also see this pull request for background information: rust-lang/rls#181
The problem is that finding all implementations for traits of the standard library (like PartialEq
) return spans with references to files located under the path /checkout/src/libstd
or /checkout/src/libcore/
(under linux, may be different for windows and osx). These are non-existent and thus lead to poor user experience.
This is copied from the pull request:
I assume this is an artifact how the save-analysis data is generated. I assume this is the path used in the buildbots.
In general this can only become a problem for the values ref_spans
and impls
in PerCreateAnalysis
, because here we map to a span. ref_spans
is only filled by the "refs":
array in the serialized json. globs
and def_id_for_span
map a span to something else. If they contain such a broken span this only leads to a failed lookup but not to wrong filenames being presented to the user.
In the local (target/rls
) analysis data I can only find references to the path /checkout/src/libcore/macros.rs
. They appear here only in the macro_ref
section, which is currently unused by rls-analysis, thus they could not have been a problem. No span in "refs"
contains such a path.
In the global ('rustlib/.../analysis') analysis data I see references to a lot of different files of the libraries. But none of those json files have any values in "refs"
, which is the only existing possibly problematic case.
This mean, neither the local nor global data could have contributed until this change with broken spans.
There is nothing which makes a path starting with /checkout/src/
invalid. A user could develop all her rust projects under this path. There is also no other indicator in the serialized data that these are invalid paths. This makes it harder to find a good solution for this.
A possible solution might be to rewrite all invalid paths to the rustup download of libstd. This would require to first check all paths if they are present on the file system and would fail if someone would create a file like /checkout/src/libcore/ops.rs
with non-matching source code. Non-matching could either be a file unrelated to libcore (a simple name clash) or libcore in the wrong version, in which case the spans would point to the wrong place.