Skip to content
This repository was archived by the owner on Mar 1, 2019. It is now read-only.

Cleanup spans with references to non-existing files #49

@jonasbb

Description

@jonasbb

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions