Tracking issue for -Zsave-analysis

[nrc]

-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 whatever
• Keep the -Z flag and give tools a loophole to use it on stable

I 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.

[nrc]

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).

[steveklabnik]

What does "custom compiler driver" mean exactly?

[oli-obk]

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 rustc_driver that rustc itself uses). You basically end up implementing a small trait, forwarding all methods to rustc's default implementation, and injecting your own code at the appropriate locations.

[nrc]

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.

[staktrace]

@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)

[nrc]

You should just be able to make an executable which looks like:

extern crate rls_rustc;

fn main() {
    rls_rustc::run();
}

And then run that executable as a drop-in replacement for rustc.

[nrc]

@staktrace ^

[staktrace]

@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.

[ishitatsuyuki]

I think we should not make any guarantee of the analysis format, however it worths to expose a lib like rls-analysis bundled with the compiler distribution. It would start with a small subset of types, expanding as we decide, similar to what proc-macro has been.

Stabilising this allows us to have documentation generators other than rustdoc, for example.

[jyn514]

AFAIK rustdoc doesn't and never has used -Z save-analysis, so I'm going to remove the rustdoc label.

[steveklabnik]

There was serious effort to make it understand it at one point, but that idea was abandoned long ago, so 👍

[wesleywiser]

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 -Zsave-analysis, it's not clear that we should still be working to stabilize this feature.

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 S-tracking-design-concerns until we decide to either move forward with stabilization or commit to removing the feature.

[eddyb]

The future of save-analysis was discussed in #100863 (comment) (i.e. on the PR to sunset RLS).

I had some suggestions but @bjorn3 pointed out (in #100863 (comment)) that:

Rust-analyzer has support for emitting LSIF formatted analysis results as well as Sourcegraph's SCIP. This might be a viable alternative for the save-analysis results for most users.

Based on that, I was able to find existing mentions of LSIF regarding searchfox's indexer (the only project I've heard of that still relies on save-analysis, and is used at scale, at the very least inside Mozilla):

• rust-analyze: only stick with the deps/save-analysis file, instead of all of them. mozsearch/mozsearch#81 (comment)
• Bug 1633260 - Add Java AST parser using JavaParser mozsearch/mozsearch#314 (comment)
  • (not even about Rust, but interesting to read about nonetheless)

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 save-analysis in favor of RA+LSIF.

(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))

[asutherland]

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:

1. Pass on any planned timelines for save-analysis removal from this issue at the meeting.
2. Provide more clarity over searchfox's plans after the meeting occurs (which obviously could be delayed), recognizing that while it's great if we can time things so there's no gap in searchfox's rust indexing support, searchfox's (lack of) resourcing should not impede rust's removal of an unstable feature that has a clear migration path.

[est31]

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)

[bjorn3]

You can use the LSIF or SCIP output formats of rust-analyzer for that I think.

[Veykril]

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.

[eddyb]

@est31 @Veykril I believe @bjorn3 is talking about rust-analyzer lsif path/to/crate/dir which looks to be working for me? Or am I missing some nuance here?

I assume worst case you can use the LSIF as a rough skeleton and then query more specific things based on it, but I'm not exactly sure.

[asutherland]

As a follow-up for searchfox (https://github.com/mozsearch/mozsearch) plans:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1761287 continues to be the bug we will track any work on the transition to RS+SCIP or RA+LSIF
• Currently the expectation is that @emilio will end up fixing this reactively when save-analysis is removed. (Although it's possible we could end up with some clangd synergies in which case we can try and address this earlier. Emilio may also be able to find some time earlier as well.) As such, I wouldn't block removal on searchfox.

[nnethercote]

I have created #101841 which removes save analysis, just to see how hard it was: not particularly hard.