Run rustc/cargo in the background to avoid blocking UI

[jamii]

Otherwise the whole editor locks up for 10+ seconds when using cargo.

Sharing the settings between threads is not safe but I got bored halfway through pulling out all that shared state :) It would be difficult to actually break it anyway - the settings would have to change in the middle of really_run.

[oschwald]

This seems like a good idea, but I wonder if the correct fix is to take advantage of the threaded queue already in SublimeLinter.

[jamii]

I had no idea there was one :)

[Byron]

+1
I would totally love to see this feature implemented as well, ideally with the means already provided by the SublimeLinter framework.

@oschwald Do you think doing this _the right way_™ would be complicated ? If not I could possibly give it a try, even though I have absolutely no experience with SublimeText- or Linter-Plugins.

[oschwald]

I'd also like to see this implemented. I think the threaded queue should be used automatically for the continuous linting, but the plugin currently doesn't work with continuous linting. If I recall correctly, the reason for this has to do with the fact that, with Cargo, it needs the full build directory rather than being able to copy the file to a temp directory. I suspect getting the other modes working with the queue wouldn't be that hard, but it would likely involve using some less documented parts of SublimeLinter.

[Byron]

I see - from what you say ThreadQueues in SublimeLinter are tried to continuous linting, which doesn't work for cargo unless the active buffer is flushed to disk all the time. This seems like an architectural oversight in SublimeLinter, if the orthogonal concepts of continuous linting and background-operation through ThreadQueues have truly been tied to each other.

In an ideal world, one would just start a new background invocation of cargo + linting each time a file managed by cargo (or more generally, any *.rs file in the project) is saved.

Maybe it's possible to piggy-back the continuous linting + threadqueues features just to get a callback, and check against the last time the buffer was saved. That way, the cargo invocation could happen as part of the continous linting framework, even though it will only be executed every once in a while, and operates on files already saved to disk.

[oschwald]

That might be possible. It would probably involve using undocumented calls to SublimeLinter, but this plugin already does that anyway. It might be worth engaging with the SublimeLinter maintainers on how to best do this.

[arthurprs]

Sorry to intrude, but are there any updates on this?

[oschwald]

It'd be great to see this implemented using the API available in SublimeLinter itself. I am bit concerned that this particular PR will introduce problems for some users, but if a number of people have been using it without issue, I'd consider merging it as is.

[Byron]

This PR would also benefit from the upcoming wait-mode to prevent multiple cargo processes to interfere with each other.

[kbknapp]

Would it be of any benefit to use cargo rustc -Zno-trans instead of cargo build in this plugin?

[Byron]

Sounds like a great idea - I believe it's the same that the cargo check (cargo) plugin does under the hood.

[kbknapp]

Yep, that's actually what made me look into this. I think cargo-check is still only a third party plugin, so not all installations of cargo have it. But I believe cargo-rustc is built in, to everyone has it.

Without actually spending more than a minute reading this repo, I think all it would take is to edit this line.

[oschwald]

Although it is a bit off-topic to this PR, I did switch to using -Zno-trans with cargo. It previously was only used for rustc directly. Please let me know (in a new issue) if this causes any problems.