live-update diagnostics

[dakom]

Is it possible to get diagnostics when text is edited, like with a debounce/delay so its not overwhelming?

Right now I have to save in order to see them - which is more of a problem than it may seem since old errors lurk around and pollute the screen

[bjorn3]

These diagnostics come from running cargo check. This needs the current code to be saved. Rls solves this problem by hooking into nightly only compiler api's to present a virtual fs containing the current unsaved code.

[dakom]

thanks for the insight! is this something rust-analyzer could do too?

[bjorn3]

Currently rust-analyzer is using stable. These api's however require nightly, so using them is not possible. Using for example LD_PRELOAD it would be possible to change the open syscall, but this is a hack and I don't know if windows has something equivalent.

[Immugio]

@bjorn3 Is there any plan to make the analysis work while typing?

[resolritter]

These diagnostics come from running cargo check. This needs the current code to be saved. Rls solves this problem by hooking into nightly only compiler api's to present a virtual fs containing the current unsaved code.

Related to this, on RLS

https://github.com/rust-lang/rls/blob/67bce0bdcf2db1d3c05bb1a3d87df9e66eaec7db/src/build/rustc.rs#L132

Notice how it using this run_compiler API from rustc_driver.

https://github.com/rust-lang/rustc-dev-guide/blob/master/src/rustc-driver.md
https://github.com/rust-lang/rustc-dev-guide/blob/master/src/rustc-driver-getting-diagnostics.md

Due to my unfamiliarity with Rust, I couldn't find out whether run_compiler is still nightly-only (it seems to be). I also could not figure out when it'd be stabilized from the issue tracker. @bjorn3 since you have more context, if you happen to have a rustc issue in mind which is blocking this, it'd be good to link it here for the subscribed people.

[bjorn3]

run_compiler is a permanently unstable function. We want to be able to change it in the future. In fact I changed it a few days ago to add another parameter.

[resolritter]

run_compiler is a permanently unstable function. We want to be able to change it in the future. In fact I changed it a few days ago to add another parameter.

@bjorn3 Thanks for the clarification. My attempt was for understanding what is blocking progress on this issue on the rustc side; knowing that makes contributing easier and is also useful for this issue's subscribers. For instance, quoting #3107 (comment)

These api's however require nightly

Is there some roadmap and/or tracking issue for having them on stable? (Or maybe they already are?)

[bjorn3]

No, there is no roadmap, nor a tracking issue. These are implementation details of the rust compiler. It is highly likely that the api's necessary for this will look fundamentally different in a few years. Either as a result of the ongoing libraryfication of rustc (to make it easier to share code with other tools like rust-analyzer) or as a result of the wish to push back incremental compilation more towards the macro expansion/parsing part of the compilation.

[Kimundi]

@bjorn3 Instead of stabilizing the internal FileLoader API, how feasible would it be to eventually stabilize a high-level interface for providing the compiler with a path remapping for the filesystem directly?

If we define this such that we can substitute any data read from the filesystem, then we don't have to build-in any assumptions about how the internal API of the compiler works.

For example:

> rustc main.rs --override_paths=overrides.json

Source directory:

main.rs
submodule.rs

overrides.json

{
    "version": 0,
    "overrides": [
        { "path": "submodule.rs", "override": "/some/tmp/ra/dir/submodule.rs", "mtime": "..." }
    ]
}

[MikailBag]

I think such a remapping can be already achieved using e.g. bind mounts or symbolic links (at least on Linux).

[lukechu10]

Is there any reason preventing rust-analyzer from using nightly compiler APIs?
I think there are two ways forward from here:

• Using the nightly only run_compiler from rustc_driver.
• Exposing a higher-level API from rustc that is stable.

[flodiebold]

Is there any reason preventing rust-analyzer from using nightly compiler APIs?

There are reasons, yes -- we prefer rust-analyzer to build on stable with normal cargo build to make contribution as easy as possible. Also, as long as our release cycle isn't aligned with rustc's, we can't really be bound to a specific rustc version.

These problems might be avoidable by implementing a separate custom driver for rustc, but the other reason why no-one is spending effort on this is that it's not the final architecture we intend. The whole reason for rust-analyzer's existence is that the RLS approach of just running the compiler on every change is a dead-end. The current 'cargo watch' / flycheck integration is a stopgap to provide diagnostics that rust-analyzer can't provide natively, but our focus is on librarification of rustc and providing more and more diagnostics natively, ideally by sharing library code with rustc. We're not far off from showing type errors natively (without saving), for example.

(Just to be clear, that's not saying that any particular pull requests would be rejected out of hand.)

[emi2k01]

Naive question. If rust analyzer knows the types of local variables and the signature of functions, could we have type checking for assigning a value with the wrong type to a variable and passing a value with the wrong type to a function? I've found those two are my most common errors. Willing to contribute

[flodiebold]

This already exists as an experimental diagnostic; you can enable it by setting rust-analyzer.diagnostics.experimental.enable to true. You might get some false positive errors though, which is why it's not enabled by default yet. (Also, the error messages aren't as good as rustc's.)

[emi2k01]

@flodiebold, awesome! thanks :)