Skip to content
This repository has been archived by the owner on Dec 29, 2022. It is now read-only.

Easy to use indexing of std libs #88

Closed
5 tasks done
nrc opened this issue Nov 6, 2016 · 11 comments
Closed
5 tasks done

Easy to use indexing of std libs #88

nrc opened this issue Nov 6, 2016 · 11 comments
Assignees

Comments

@nrc
Copy link
Member

nrc commented Nov 6, 2016

This means building and distributing save-analysis info for std libs and making RLS find and use that info. The tricky part if that it must exactly match the installed libraries. I expect this will need Rustup or Cargo integration.

  • produce save-analysis info for nightly builds (Add --emit metadata rust#37411)
  • make that data available on r-l.o
  • download the data corresponding to current libs using rustup (or distribute with libs by default)
  • RLS to control the whole process without user interaction (or just an OK for the downloads or something)
  • heuristic for discovering the rustup save-analysis for std lib based on target

I don't think we necessarily need all of this to work for the alpha release, but we it should be easier than it is now (we can't require users to build their own compiler and libs) and we should have a good plan for the long term solution.

@nrc nrc added this to the Alpha release milestone Nov 6, 2016
@matklad
Copy link
Member

matklad commented Nov 8, 2016

we should have a good plan for the long term solution.

Why you can't just use an .rlib file? If it contains enough information for compiling code, it must be also enough for rls. IntelliJ IDEs use the same abstraction (PSI) for working with both .java and compiled .class files. So you can just add a compiled binary library to your project and get completion and other features. You can also attach a source code to the binary library so that "go to definition" works properly.

@nrc
Copy link
Member Author

nrc commented Nov 8, 2016

The metadata in the rlib is technically what we need but it is hard to read (we'd basically need to link the compiler to decode it) and is an implementation detail and thus can change at any moment. The save-analysis metadata is basically the same information but with a layer of abstraction, thus easy to read and fundamentally stable.

@nrc nrc self-assigned this Nov 8, 2016
@matklad
Copy link
Member

matklad commented Nov 8, 2016

we'd basically need to link the compiler to decode it

Hm, you already are using an in-process rustc?

and is an implementation detail and thus can change at any moment.

If it is more or less stable in practice, then perhaps it is possible to write a translator from rlib to save-analysis format. I don't know the amount of work here, but it will be the most convenient form for the users, because they won't need to download/install additional stuff. Custom build stdlibs would also work, which is a nice little benefit, as well as an ability to work with hypothetical closed source binary only crates.

@nrc
Copy link
Member Author

nrc commented Nov 8, 2016

Hm, you already are using an in-process rustc?

Only when we don't have the save-analysis data already

If it is more or less stable in practice

It is not

then perhaps it is possible to write a translator from rlib to save-analysis format. I don't know the amount of work here, but it will be the most convenient form for the users, because they won't need to download/install additional stuff

I don't think there is much more convenience for users - they have to wait for a translation step vs waiting for a download - either is just a wait, everything else should be automatic. Long term, the save-analysis data should be distrbuted with the libs, so there would not even be an extra download.

Custom build stdlibs would also work

If custom building then you can just output save-analysis, no issue there

@nrc
Copy link
Member Author

nrc commented Dec 29, 2016

planning:

  • remaining for alpha: change the search path for std save-analysis data, finish instructions in README.md
  • for alpha2: rustup integration
  • for beta: total automation

@nrc
Copy link
Member Author

nrc commented Dec 30, 2016

Changing milestone since we've now done everything intended for the alpha

@nrc nrc modified the milestones: Alpha #2, Alpha release Dec 30, 2016
@nrc
Copy link
Member Author

nrc commented Jan 25, 2017

Working on rustup distribution of data. Hopefully, we don't actually need to modify rustup at all, just provide the right manifests. Unfortunately, we need to do that for the current (Buildbot) and future (Travis) systems.

rust-lang-deprecated/rust-buildbot#150 should address the current system.

When rust-lang/rust#39284 lands, we'll need to add a line for the analysis data.

@Arzte
Copy link

Arzte commented Feb 16, 2017

@nrc Both of the mentioned pull requests have merged.

@nrc
Copy link
Member Author

nrc commented Feb 22, 2017

Changes for the new system: rust-lang/rust#40026

@nrc
Copy link
Member Author

nrc commented Feb 27, 2017

Rustup now downloads the data and rls-analysis manages it. We are done for alpha 2 (modulo any bugs discovered).

Remaining:

  • make the RLS handle fetching the data, rather than needing the user to interact with rustup.
  • cross-compilation - we currently require the host and target triples to match exactly. To address this we need to pass the target triple from the rls to rls-analysis. I think the best way to get the target triple is by parsing the calls from cargo to rustc. We might need to add API to Cargo or rustc though.

@nrc nrc modified the milestones: Beta, Alpha #2 Feb 27, 2017
@sophiajt
Copy link

Rustup can now fetch and install the rls, rust-analysis, and rust-src. Good enough for beta.

@sophiajt sophiajt removed this from the Beta milestone Apr 18, 2017
@nrc nrc closed this as completed Oct 30, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants