-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking issue for -Zsave-analysis
#43606
Comments
Another alternative is that the RLS and Rustdoc could use a custom compiler driver. This would mean we would not need a stable CL flag. This seems fine for the RLS (it would mean a marginally more complex build, but nothing too serious) but would mean some extra work for Rustdoc and mean it would only work if distributed with Rustdoc. (Motivation for avoiding a stable flag is to prevent other users using the save-analysis data and it becoming de facto stable). |
What does "custom compiler driver" mean exactly? |
It means that you are using rustc as a library. So instead of extending rustc via plugins, you are writing your own rustc binary (but you are reusing all of the boilerplate offered by the |
I've implemented a shim at https://github.com/nrc/rls-rustc I have a couple more features to add, but this should be a drop-in replacement for rustc for the RLS and rustdoc. I'll leave this issue open until we confirm this approach works, but I think we don't need to stabilise -Zsave-analysis any more. |
@nrc: can you explain how to go about using this wrapper? In particular I'm looking to do a mozilla-central build on taskcluster with save-analysis turned on. Right now I can do this easily by using a rust nightly toolchain and export RUSTFLAGS="-Zsave-analysis". It's not clear to me how I would plug in this wrapper though. (FWIW I would still prefer stabilizing the save-analysis option into rust stable) |
You should just be able to make an executable which looks like:
And then run that executable as a drop-in replacement for rustc. |
@nrc Thanks. I think hooking that into taskcluster is probably nontrivial (at least for me) as I would have to create a custom toolchain and override the compiler being used. I think for now I'll continue using the nightly rustc since that's easier and I have it working, but I would still really like having the -Zsave-analysis option in rust stable. |
I think we should not make any guarantee of the analysis format, however it worths to expose a lib like Stabilising this allows us to have documentation generators other than rustdoc, for example. |
AFAIK rustdoc doesn't and never has used |
There was serious effort to make it understand it at one point, but that idea was abandoned long ago, so 👍 |
Reviewed as part of the compiler team's "backlog bonanza" in the weekly compiler team triage meeting. Given the in-motion plans for Rust Analyzer to officially replace RLS as our IDE experience which does not use In general, meeting attendees thought we should deprecate and remove this unstable feature instead once RLS is no longer in use. Therefore, I'm marking this |
-Zsave-analysis
-Zsave-analysis
The future of I had some suggestions but @bjorn3 pointed out (in #100863 (comment)) that:
Based on that, I was able to find existing mentions of LSIF regarding
Based on https://bugzilla.mozilla.org/show_bug.cgi?id=1761287 I'm guessing the thing to do would be to coordinate with @asutherland and @emilio, and eventually remove (I'm not expecting to be involved, but I wanted to point this out because it's a simpler solution that supersedes the one I described in #100863 (comment)) |
Thanks for reaching out! I noticed the rls removal earlier today and was wondering about the implications on save-analysis! Yes, searchfox (https://github.com/mozsearch/mozsearch) will ideally move to RA+SCIP or RA+LSIF in the near-to-medium term. We have a meeting tentatively planned for this Friday (2022-09-02) to discuss various searchfox meta issues like this, so I can:
|
Does rust-analyzer support a bulk mode yet? Or is it still request based? I need the usage graph for all items in a given crate, so that I can determine which items are unused. (edit: this is for warnalyzer) |
You can use the LSIF or SCIP output formats of rust-analyzer for that I think. |
r-a doesn't have a simple way to just fetch all item declarations of a crate, but you can query declarations of a module, so you should be able to collect all item declarations of a crate by traversing the module hierarchy (this does leave out local items though I believe, not sure if those are easily accessible without resolving from the file source directly). If with request based you mean language server protocol requests, then no, r-a can be used as a library without going through the request protocol. |
As a follow-up for searchfox (https://github.com/mozsearch/mozsearch) plans:
|
I have created #101841 which removes save analysis, just to see how hard it was: not particularly hard. |
…-Simulacrum Remove save-analysis. Most tests involving save-analysis were removed, but I kept a few where the `-Zsave-analysis` was an add-on to the main thing being tested, rather than the main thing being tested. Closes rust-lang#43606
Summary: The flag itself no longer exists in rustc and this indexer never quite worked for our use cases. We will use rust-analyzer instead, which has SCIP and LSIF support already. - D45292993 removed the build flavor we relied on - see rust-lang/rust#43606 for removal Reviewed By: simonmar Differential Revision: D45516746 fbshipit-source-id: 684117415c5daebca7656c330592f1362781ab1c
-Z flags are now unstable. However, we plan to use save-analysis info for the RLS and Rustdoc and we want these to work on stable compilers. Therefore, we need a stable flag. Options:
--save-analysis
--emit analysis
or analysis-info or analysis-data or whateverI propose that the existence of the flag is stable, but that we make no guarantees about the output when using the flag. We might consider guaranteeing that the output is valid JSON (but that includes
{}
). We could promise that the shape of the ouput won't change, but I'd rather not.The text was updated successfully, but these errors were encountered: