Syntax highlighting stops working in workspace

[Wyverex42]

Sublime Text 3 (Build 3125)
Ubuntu 16.10
Rust Enhanced 1.2.1

I have a workspace directory containing a number of crates and a Cargo.toml, just containing a [workspace] section with a "members" entry. Each crate still has its own Cargo.toml. My sublime project contains just the folder of one of those sub-crates.

As long as this workspace Cargo.toml exists, syntax highlighting stops working. If I rename it, syntax highlighting works again.

The error message is
Rust Enhanced: Failed to find target for '<path to the rs>'

[jasonwilliams]

ok thanks for raising this, most likely to do with the latest release which had significant changes in it.
@ehuss any ideas?

@Wyverex42 do you have a link to the project so we can test ourselves? or is it private?

[ehuss]

Sorry about that. It was a known issue, and I honestly just forgot about it. Uploaded PR #152 to fix. If maybe @Wyverex42 can test that to see if it works? I'm not certain if there are any gotchas with how cargo handles workspace paths.

[Wyverex42]

Hi, thanks for the update. The project is private, so I cannot share this here.
I tried to use the fix but I'm probably doing something wrong when trying to use the plugin with the repository code directly. I tried that already yesterday with one of the older releases.

Here's what I'm doing:

• remove the plugin via package control
• Add a "Rust Enhanced" directory in ~/.config/sublime-text-3/Packages
• Unzip the repository into that directory
• Restart sublime

Then, whenever I save a *.rs file, I get those messages:
Running 'cargo metadata --no-deps'
Failed to run: cargo metadata --no-deps
error: could not find Cargo.toml in ~/projects/mio/code or any parent directory

What confuses me about this is that my file is for example ~/projects/mio/code/crates/mio_core/src/components.rs and for some reason either cargo or the plugin tries to look in mio/code for a Cargo.toml. Note that this happens independently of whether I have the Cargo.toml in my mio/code/crates directory (which is my workspace) or not.

So until I find out how to run the plugin from code, I'm afraid I can't verify that fix :-/
Do you have any suggestions?

[ehuss]

I'm not a GitHub expert, but I just wanted to confirm how you downloaded the repository. I'm not sure if there's a convenient way to fetch the tree from a PR, but you can download the attempted fix from my repo here:
https://github.com/ehuss/sublime-rust/tree/042f73c236b6178c396911b6635784bf2c5904c1
Click the "Clone or Download" button to download a Zip with the fix.

If you are in the directory ~/projects/mio/code/crates/mio_core/src/ in a terminal, and you run cargo metadata --no-deps yourself, does it spit something out or do you get the same error?

[Wyverex42]

There is a way to fetch the repo for a PR. Just press the '<>' button on the specific commit and you get the repo view (the one you sent me).

If I run the cargo metadata --no-deps command in the ~/projects/mio/code/crates/mio_core/src directory directly, it works. When I have a workspace Cargo.toml in my ~/projects/mio/code/crates directory, it also writes more data, so it seems to pick up the workspace correctly.

So it seems to me that the plugin somehow messes up the paths. I have no idea why it would try to look in ~/projects/mio/code. (Incidentally that is the root directory for my project's code but there are no cargo files inside).
But this only happens when I download the repository. Via package control, the metadata command works.

[Wyverex42]

Sorry, I must have messed up my previous tests, because now as the change made it into Package Control, I had the same issue with cargo metadata --no-deps.

So I investigated further and found that while running the on_post_save_async handler, the current working directory is changed three times. One instance of those is desired, the other two are not. Please have a look at this PR: #155

This is a hack fix that fixes my problems but probably not what you would want as a general solution.
On the plus side: My workspace works fine now :)

[fxdave]

If I have a non-lib project with a custom lib in the directory. This fails again with Rust Enhanced: Failed to find target for '...'. Syntax highlighting works but cargo check is not.