Flowistry like feature

[HKalbasi]

Flowistry is a very cool and useful tool that gray out codes that are not related to the code under cursor. Now that we have a functioning MIR, we can implement a similar feature in rust-analyzer. The flowistry paper explains how it works, and it's internal analysis is published as a crate but I don't think we can reuse that much since it is heavily dependent on the rustc internals. A challenge in reimplementing that in r-a is that we ignore lifetime annotations currently in type lowering, but I think it wouldn't create problems for start, we can assume all lifetimes are static at cost of some false positive gray areas. Another challenge is constructing a ast to mir map, for finding the mir node under cursor.

But why we should implement it in rust-analyzer when flowistry already exists? Implementing it in rust-analyzer has some benefits:

• Flowistry focus mode will be disabled if you change the code, limiting its usability.
• It's start time is a bit slow.
• It needs nightly, which doubles the target folder size, and has other nightly problems.
• It only supports vscode, but r-a is cross editor.
• It's discoverability is a little lower than r-a.

cc @willcrichton

[Veykril]

fwiw, they did ask about mir in r-a half a year ago here https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/How.20far.20is.20RA.20from.20MIR.3F so the interest is probably there

I am unsure whether we would want this to live in r-a proper though or be a third-party extension that r-a provides the required bits for.

[HKalbasi]

I am unsure whether we would want this to live in r-a proper though or be a third-party extension that r-a provides the required bits for.

I think the analysis should live in a crate outside of r-a repo, but the ide part should be here, for better discoverability, ease of use, and efficency (so that there wouldn't be two r-a consumig 2 gb ram each). What is the downside of including it in r-a?

[Veykril]

so that there wouldn't be two r-a consumig 2 gb ram each

Ah I assumed the majority of flowistry's logic was in the typescript extension part, so my thought was to have the rust-analyzer extension expose necessary API endpoints for it to consume. If that's not the case then having it be a third party thing seems unnecessary given the resource usage indeed.

What is the downside of including it in r-a?

More things to maintain ourselves. r-a still has a ton of architecture changes that it will need, so more things that depend on these bits that we maintain makes these changes more difficult for us. Obviously this is not a hard deny for here, it is just something to be aware of.

[HKalbasi]

Ah I assumed the majority of flowistry's logic was in the typescript extension part

The typescript / lsp extension part is very minimal I think, it's a command to toggle it between enable and disable, and some things like that. It then uses semantic highlighting for graying things out.

More things to maintain ourselves. r-a still has a ton of architecture changes that it will need, so more things that depend on these bits that we maintain makes these changes more difficult for us.

I see. I think we can manage that cost by moving the analysis logic into the external crate.

[willcrichton]

Overall, I would be super excited to see Flowistry built on Rust Analyzer rather than Rustc for all the reasons @HKalbasi enumerated. I don't have the cycles to build that integration right now, but I would be more than happy to support someone who does.

Adding my thoughts to the existing threads:

• Rust code vs. TS code: Flowistry is predominantly Rust code using the Rustc API. The core aspects of the analysis are all in the infoflow folder. The TS code just handles user interactions and highlighting.
• Reimplementing the analysis in R-A: as @HKalbasi stated, Flowistry uses the base lifetime facts emitted by the compiler in combination with Polonius to do alias analysis. You could use a less precise alias analysis that assumes everything has an &'static lifetime, but my experiments suggest that would cause a serious drop in overall precision. I would consider how to incorporate lifetime analysis into the R-A MIR. And yes, source-mapping would be a relevant issue as well.
• Living in-tree vs. externally: I don't have a strong opinion about this, since it's up to the R-A maintainers to decide their maintenance burden. One thing I don't know is how R-A manages extensions. Is there an extension framework? Is it easy for users to discover, install, and update extensions?