#113 raises a good point about consitency so I've made some changes but would like some feed back. (don't merge this without discussion please)

if @boscop or @petrochenkov would like to give comment that would be appreciated

currently function calls aren't highlighted, i got stuck trying to make generic function calls match the non generic ones so gave up and went with white for all functions calls for consitency

Whenever an error is caused by a derive macro, sublime opens a non-existent file with the name of the macro when pressing F4 to jump to the error: E.g.

error[E0412]: type name `Foo` is undefined or not in scope
 --> <proc-macro source code>:1:4261

When I press F4 it opens a new empty file named . This is undesirable. Btw, in this case the error was caused by using #[derive(Serialize)] on an enum with a member that uses an undefined type:

#[derive(Serialize, Deserialize)]
pub enum Bar {
	Bla(Foo),
}

This PR adds

cargo test output highlighting:

• note:
• test result:
• a passed test
• a failed test
• failed test source line (this is clickable, jumps to source)
• summary line, total number of passed tests
• summary line, total number of failed tests if > 0
• summary line, total number of ignored tests if > 0
• summary line, total number of measured tests if > 0

New build commands:

• cargo build --release
• cargo clippy

Bug fixes:

• Don't treat <std macros> as a file name.

My choice of entity to trigger various highlights is probably questionable, but they're a complete 🚮🔥 anyway. @dten what do you think?

Rust 1.24 introduces some breaking changes, in particular:

• All paths are now relative to the workspace root instead of the package root.
• Columns reported in macros are now 1-based (affects test output).

Fixes #234.

This is mostly a result of me playing around with the new json formatted error messages but I decided to PR it to see what was thought of it.

It requires the latest dev build of Sublime Text 3 so I don't really expect this to be pulled as it stands.

This uses the phantom system to display error messages and hints inline with the code, i'm not sure how much I like this system but it seemed to be the nicest way I could think of displaying them.

I don't really do python so i'm sorry about the code

I wanted to share a WIP of a new, enhanced build system for Cargo. I was wondering:

1. Would you would be willing to merge something like this?
2. Test it out and let me know what you think (any issues, ideas for improvements, etc.)

The main improvements are:

• Shows inline phantoms for errors/warnings when building.
• Properly handles cancelling/stopping a build.
• Pulls in the user's shell environment to make it less likely to have problems.
• Supports custom environment variables.
• Interacts more nicely with the on-save syntax checking.
• Allows you to configure settings for builds (see docs/build.md).
• Command to assist configuring custom build variants.
• On-save syntax checking supports different methods (rustc no-trans, cargo check, clippy)

This also closes a few issues: #182, #170, #162, #154, #146, #109

It should be fully functional in its current state, but I still have a long todo/improvement list. Here's a copy in case you are curious:

• [x] Support custom build variants (passing in any and all settings).
  • [x] Also include interactive command to configure a new variant.
  • [x] Include "environment", and "path"
  • [x] Any custom arguments.
  • [x] working_dir
• [x] Set "default" project path/package.
• [x] Cargo "Automatic"
• [x] Add "--features" support.
• [x] cargo check
• [x] test: Message-order: Next/Prev testing Test with a variety of message types (to ensure is_main is good) Test with already open files and files that need to be opened.
• [x] Test without cargo manifest
• [x] Test without sublime project
• ~~[ ] Run with multiple executables displays this error: error: cargo run requires that a project only have one executable; use the --bin option to specify which one to run Should we detect this, and bring a popup to select a target?~~ Deferred
• [ ] Clippy: Should it automatically use nightly toolchain?
  • [ ] Same with Bench?
• [x] Make links in clippy output clickable.
• [x] Deal with duplicate messages generated by clippy (filter duplicate messages in general)
• [x] Make clippy an option for on-save checking.
• [x] Should the cargo settings be used for SyntaxCheck somehow?
• ~~[ ] I think the build-language could be improved (coloring file filenames, numbers, etc.)~~ Deferred
• ~~[ ] Something similar to Anaconda Show Errors (popup with list of errors)~~ Deferred
• ~~[ ] Other cargo test options?: --doc --no-run --no-fail-fast~~ Deferred
• [x] Is term "Target" too confusing? Filter or Kind? Internally Cargo uses various terms (CompilerFilter, Kind, Target)
• [x] Update README
• [x] Fix called with multiple buffers (views) into same file. (Terminates, but otherwise runs correctly. This is something that really needs to be fixed in Sublime.)
• [x] Check setting "show_errors_inline"? In case someone doesn't like the phantom style.
• [x] Possibly consolidate the configuration commands into a single command?
• [x] Add command to configure environment variables (in particular, make it easy to add RUST_BACKTRACE=1).

One last thing, this replaces the "rustc" build variants. I'm not sure what the use case is for those, and whether or not "cargo script" is a sufficient replacement.

SyntaxCheckPlugin was not able to find cargo, but doesn't report not being able to find it, because the actual error message is /bin/sh: cargo: command not found, whereas the error checker looks for "error".

I installed Rust through rustup, so cargo is in $HOME/.cargo/bin. But the path of SyntaxCheckPlugin is the default: /usr/bin:/bin:/usr/sbin:/sbin. #92 did not address this plugin.

HI guys I really liked the syntax checking on save within GoSublime. So i had a go at trying it for Rust.

Under the hood all this plugin does is call "cargo run" in the same directory the file is in, if there's any errors it will try and parse out the first line number, then return that back to sublime.

It would be nice if some sublime users could take a look at my PR and tell me what they think needs adding or their thoughts.

here is a demo Thanks Jason

macro_rules failed in a lot of cases, this reworks it to fully support:

• Complete matcher syntax.
• Better bracket balancing support.
• Add lifetime designator (1.28).
• More resilient to odd syntax within the transcriber. The content doesn't have to be Rust syntax, so it can sometimes get confused. Add a few escapes so it at least doesn't barf.
• At-most-once kleene operator (2018).

Closes #311

This matches things like this now:

struct Thing(u8, u8);

fn name(Thing(a, b): Thing) {
    do_something_with(a, b);
}

I don't know if this is the right way to solve it. Some more tests might also be in order

Sublime Text Version

Sublime Text 3 (Build 3126)

Rust Enhanced Version

1.1.1

Operating system

OS Name macOS Version 10.12.3

Description

Pressing Cmd+Shift+P and selecting "Build With: RustEnhanced" calls rustc, rather than cargo.

I'm getting the following output in the bottom pane:

error[E0463]: can't find crate for `rustc_serialize`
 --> /net/sujin/home/ubuntu/src/rust-playground/src/ohai.rs:1:1
  |
1 | extern crate rustc_serialize;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to previous error

[Finished in 0.4s with exit code 101]
[shell_cmd: rustc /net/sujin/home/ubuntu/src/rust-playground/src/ohai.rs]
[dir: /net/sujin/home/ubuntu/src/rust-playground/src]
[path: /Users/primary/.cargo/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/primary/bin]

Note that the shell_cmd says rustc. As a result of using rustc, it fails to find the external crates we are using.

I believe it should call cargo instead. The cargo binary is in the search path at /Users/primary/.cargo/bin/cargo, so I'm not sure why it's not working.

If I select Tools -> Build System -> RustEnhanced, and then Tools -> Build, the same thing happens.

If I select Tools -> Build System -> Rust, and then Tools -> Build, the same thing happens.

If I select Tools -> Build System -> Automatic, and then Tools -> Build, it does call cargo, but it doesn't show build errors in the source code, so I'm having to hunt for line numbers. (I'm not sure if that's calling the built-in Rust or the RustEnhanced plugin.)

Sublime Text Version### Sublime Text Version

Sublime Text 4 (Build 4142)

Rust Enhanced Version

v2.25.0

Operating system

Ubuntu 22.10, Gnome 43.0

Expected behavior

Macros should have a macro scope applied even if they're fully qualified.

Actual behavior

fn main() {
    std::todo!();
}

Scopes:

source.rust
meta.function.rust
meta.block.rust

Compare to the bare macro:

fn main() {
    todo!();
}

source.rust
meta.function.rust
meta.block.rust
support.macro.rust

Steps to reproduce

See code above.

Sublime Text Version

Sublime Text 4 (Build 4142)

Rust Enhanced Version

v2.25.0

Operating system

Ubuntu 22.10, Gnome 43.0

Expected behavior

Attributes on fields within a struct should have a scope applied to mark them as such eg.

Actual behavior

struct Magic(#[more] bool, #[more(magic)] usize);

Neither attribute has any scope applied to indicate that it's an attribute. For example, the first attribute has scopes

source.rust
meta.struct.rust
meta.struct.rust
meta.group.rust

Steps to reproduce

See code above.

Sublime Text Version

Sublime Text 4 (Build 4142)

Rust Enhanced Version

v2.25.0

Operating system

Ubuntu 22.10, Gnome 43.0

Expected behavior

enum HayesCommand {
    /// Commands per the V.250 aka V.25TER AT standard, plus the ETSI TS 127 007
    /// standard.
    V250(v250::Command),
    /// Extensions to the above that we support.
    Extension(extension::Command),
}

Both V250 and Extension should have the same scopes applied, since there is no syntactical difference between them ie. they are both variants of an enum. Neither trigger a compiler or clippy warning.

(I'm not particularly tied to V250 as a name, nor do I mind the inconsistent highlighting for this single example. I just noticed it because V250 is the first abbreviation of "V.250" I thought of that was syntactically allowed, and here we are.)

Actual behavior

The text V250 has the following scopes:

source.rust
meta.block.rust
meta.enum.rust
constant.other.rust 👈 

Extension has the following scopes:

source.rust
meta.block.rust
meta.enum.rust
storage.type.source.rust 👈

Many syntax highlighting schemes, including the default Monokai, highlight these differently:

Steps to reproduce

Code above.

To fix it, I did:

{
	"rust_syntax_checking": false
}

Sublime Text Version

Sublime Text 4 (Build 4126)

Rust Enhanced Version

v2.25.0

Operating system

Linux x64_64 Kernel 5.19.17_1

Expected behavior

File saves, continue editing

Actual behavior

Computer is unresponsive.

Steps to reproduce

1. Write rust code.with question mark operator.
2. Delete or un-delete question mark operator

upd: ok, so this updated syntax works, but for the user to be able to update your default one (instead of copy&pasting everything and losing the ability to track your changes) you'd need to update it:

• add a tag/branch bumping the min version of ST to 4075 (and update the package manifest to allow installing the later package on the later ST)
• explicitly opt into version: 2 src

extends 4075 A string of a base syntax this syntax should inherit from. The base syntax must be specified using its package path, e.g. Packages/JavaScript/JavaScript.sublime-syntax. See Inheritance for an overview of syntax inheritance.

• split the huge statements into subgroups and then the user would be able to just copy&paste your list of sub-statements (without the code that defines them, just the names), insert his override one line above yours, and then add the two new block-lua, block-lua-body block definitions in his syntax file.

Also, if you know how to remove the need for introducing a custom syntax signifying that the } ends the lua block and not any } block inside lua (in the file above the syntax is escape: '(\})(/\*\s*lua\s*\*/)'), please share this bright idea!

Sublime Text Version

Sublime Text 4 (Build 4138)

Rust Enhanced Version

2.25.0

Operating system

OS Name macOS Catalina Version 10.15.7

Expected behavior

Some proc macros should have all text inside them marked by a different (non-Rust) syntax similar to how nested syntaxes work, for example, in Markdown code blocks

Given that the macro names are arbitrary, but the .sublime-syntax are nested, the could the solution be a working example of a user RustEnhanced.sublime-syntax file with just a single example macro name that would have the Rust syntax completely popped/replaced by some other syntax. Then the user would just need to change the macro name and the replacing syntax

Actual behavior

Two issues (see the code snippet below)

• do is highlighted in red as a reserved word even though it's inside a macro, so it's not Rust
• the syntax applied is still that of Rust source.rust meta.function.rust meta.block.rust meta.group.rust meta.block.rust instead of source.lua

Steps to reproduce

1. Add this snippet to a Rust file

fn lua_plugin_within_rust(lua:&Lua,_:()) -> LuaResult<()> {
  lua.load(chunk! { // ←↓ can this code be recognized as a nested Lua syntax?
    while (1 < 2) do // ← "do" this is highlighted in red as a reserved word
    end
  }
  Ok(())
}

References

https://github.com/rust-lang/rust-enhanced/issues/284 mentioned the macro call fix, which gave me the idea for this issue

8. Macro calls should not break highlighting on unusual tokens

Sublime Text Version

Sublime Text 4 (Build 4126)

Rust Enhanced Version

2.25.0

Operating system

OS Name macOS Monterey Version 12.5

Expected behavior

Automatic build output should be equivalent to the output when running manually in a terminal:

$ cargo run --example mesh2d                                                                                                                                                                                                                                                                        
    Finished dev [unoptimized + debuginfo] target(s) in 0.12s
     Running `target/debug/examples/mesh2d`
2022-08-06T08:31:27.264081Z  INFO bevy_render::renderer: AdapterInfo { name: "Apple M1", vendor: 0, device: 0, device_type: DiscreteGpu, backend: Metal }

Actual behavior

Codes for control symbols are visible:

[Running: cargo run --example mesh2d --message-format=json]
   Compiling bevy v0.7.0 (/Users/bardt/Projects/rust/bevy)
    Finished dev [unoptimized + debuginfo] target(s) in 2.98s
     Running `target/debug/examples/mesh2d`
2022-08-06T08:26:34.586134Z  INFO bevy_render::renderer: AdapterInfo { name: "Apple M1", vendor: 0, device: 0, device_type: DiscreteGpu, backend: Metal }

(In the output, I see <0x1b> instead of )

I suppose the difference is in the --message-format=json flag

Steps to reproduce

1. Clone Bevy repo https://github.com/bevyengine/bevy.git, check out v0.7.0 tag
2. Open bevy/examples/2d/mesh2d.rs file
3. Run Build With: RustEnhanced - Automatic command, watch the output
4. Run cargo run --example mesh2d in a terminal, compare the outcome