Wsrtjtyk

Question

What would be the right file_regex to capture Cargo / Rustc's error messages in a Sublime Text 3 build system? I'm asking specifically about relatively recent cargo/rustc versions (it seems that the older versions used a somewhat more easily parsable single-line error output format).

Example

Example output of cargo build on a broken hello-world project (default code autogenerated by cargo new --bin broken, with one double quote removed to create an error message):

error: unterminated double quote string

 --> src/main.rs:2:14

  |

2 |       println!("Hello, world!);

  |  ______________^

3 | | }

  | |__^



error: aborting due to previous error



error: Could not compile `broken`.

The relative file path is src/main.rs, line-column is 2:14, the error message that I personally would prefer to see directly between the lines is

unterminated double quote string

1st Solution Attempt

This kind-of works, but it doesn't capture the error messages properly, because they are on a separate line that preceeds the line with the file path and line numbers:

    {

        "name": "cargo build",

        "shell_cmd": "cargo build",

        "working_dir": 

          "/home/you/path/to/cargo/project/with/the/toml",

        "file_regex": 

          "^ *--> *([a-zA-Z0-9_/.]+):([0-9]+):([0-9]+)()$"

    },

2nd Solution Attempt

This funny regex here that uses this awesome lookahead-with-matching-groups-trick:

error(?:[Ed+])?: (?=.+n +--> +([a-zA-Z0-9_/.-]+):([d]+):([d]+))(.+)

would have solved the problem, but Sublime doesn't seem to work with multiline regexes.

The TL;DR version of the answer is that unfortunately I think the only way to get Sublime to recognize the error output in your question is to either make the tool generate output in a different format (either directly or by way of some filter app that sits in the middle) or by creating your own custom build target for your build that can recognize this error output (but it would only work for inline errors, see below).

Background

Build systems in Sublime Text have two regular expressions that can be applied to try and match error output/build results, file_regex and line_regex. Both are applied to the results of the build in the output panel in order to obtain the list of build results.

file_regex is the "general purpose" regex for matching build results, and should contain anywhere from 2 to 4 capture groups that capture the appropriate data. The capture groups (used in order) are filename, line, column, message.

line_regex is used in cases where the information about location of the error is on a different line than the error message/location. Here the captures are in the order line, column, message and you can use anywhere from 1 to 3 of them.

In both cases the captures are used in the order given above, which can necessitate having empty capture groups to make sure things line up as expected.

In normal use you just use file_regex and nothing else, and that captures the results for you. If you also use line_regex, then internally Sublime matches on line_regex instead, and then if it finds a match, it looks backwards through the result output for the first line that matches file_regex, and combines the results from the captures together.

Inherently this means that there are some restrictions placed on the sort of results that Sublime can capture; the file name has to appear prior to the other information about the error in order for it to be captured.

Massaging the output

In your example above, the error is displayed first and the location for the error is displayed second, so inherently there's no way to correctly associate the two regular expression matches together.

The most common way around this is to modify the output of the tool in order to rework it into a format that Sublime can detect with the above regular expressions.

For example you might change your build so that it executes your command and pipes the result to another shell script or program that can alter the information on the fly as it goes through. Another example would be to alter your build so that it invokes a script/batch file that executes the tool and does the output alteration internally, so that the final output matches what Sublime expects.

Custom build targets

Although there's no way to use the regex system to match your build output fully, if you're primarily interested in inline build errors being displayed, there is some recourse if you want to get your hands dirty with a little Sublime plugin development. In this case you need to know a bit of Python. There is documentation on custom build targets as well as the Sublime API available.

Internally, when you run a build, Sublime gathers the information from the sublime-build file, expands any variables in it, and then invokes the exec internal command to actually perform the build providing the keys in the sublime-build as arguments (some, such as selector, are not provided because Sublime handles that for you), and it's the exec command that sets the file_regex and line_regex settings into the output buffer.

From here, the applied settings are used by the Sublime core directly to perform navigation on build results, such as by clicking on the results to open the file, or using the navigation commands to go to the next and previous errors.

However, it's the exec command that is responsible for using those same results to show you the inline build errors, so it's possible to still get inline error messages working, although result navigation can only take you to the location in the file.

One of the keys that you can provide in a sublime-build file is target, which specifies the command that should execute the build; this defaults to exec if not given.

By creating your own custom command that mimics what exec does and using it in the target directive of your sublime-build, you can hook into the build process to capture the appropriate data.

The exec command is stored in Default/exec.py, which you can view by using the View Package File command from the command palette.

As a minimal example, the following plugin defines a new command named cargo_exec which exactly mimics what the exec command does. The call to self.output_view.find_all_results_with_text() is the API call that makes the Sublime core return all of the error information from the build output view, which is used to set up the phantoms used for inline build errors.

By modifying that code to examine the contents of the buffer and use your custom knowledge of what errors look like, the remainder of the code in the core exec command will display the inline errors for you.

import sublime

import sublime_plugin



from Default.exec import ExecCommand



# Subclass the exec command to hook into the output processing.

class CargoExecCommand(ExecCommand):

    def run(self, **kwargs):

        # If we are being told to kill a running build, kill it right away

        # and leave.

        if kwargs.get("kill", False):

            return super().run(kill=True)



        # Use our super class to execute the build from this point.

        super().run(**kwargs)



    # override the super class method so we can handle output as it

    # arrives in the output panel.

    def service_text_queue(self):

        is_empty = False

        with self.text_queue_lock:

            if len(self.text_queue) == 0:

                # this can happen if a new build was started, which will clear

                # the text_queue

                return



            characters = self.text_queue.popleft()

            is_empty = (len(self.text_queue) == 0)



        self.output_view.run_command(

            'append',

            {'characters': characters, 'force': True, 'scroll_to_end': True})



        if self.show_errors_inline and characters.find('n') >= 0:

            errs = self.output_view.find_all_results_with_text()

            errs_by_file = {}

            for file, line, column, text in errs:

                if file not in errs_by_file:

                    errs_by_file[file] = 

                errs_by_file[file].append((line, column, text))

            self.errs_by_file = errs_by_file



            self.update_phantoms()



        if not is_empty:

            sublime.set_timeout(self.service_text_queue, 1)





# Use the latest build results to add inline errors to newly opened files.

class CargoExecEventListener(sublime_plugin.EventListener):

    def on_load(self, view):

        w = view.window()

        if w is not None:

            w.run_command('cargo_exec', {'update_phantoms_only': True})

To use this as a custom build target, you need to add a couple of extra keys to your sublime-build file:

// Specify a custom build target to execute this build, and specify what

// argument to the command will cause it to cancel a build that is currently

// running.

"target": "cargo_exec",

"cancel": {"kill": true},

This AWK script combines the error message with the line numbers, and brings it into the order that Sublime wants:

awk 'BEGIN { errmsg="" } /error([E[0-9]+])?:.*/ {errmsg=$0; next} / *--> *.*/ { printf "%s::::%sn", $0, errmsg; next} {print $0}'

The output is trivially matched by the following regex:

error(?:[Ed+])?: (?=.+n +--> +([a-zA-Z0-9_/.-]+):([d]+):([d]+))(.+)

You can use | and AWK scripts inside the shell_cmd, so this build config captures all the error messages and displays them at the correct line numbers:

{

    "name": "cargo build",

    "working_dir": "/wherever/your/project",

    "shell_cmd": "cargo build 2>&1 | awk 'BEGIN { errmsg="" } /error(\[E[0-9]+\])?:.*/ {errmsg=\$0; next} /\ *-->\ *.*/ { printf "%s::::%s\n", \$0, errmsg; next} {print \$0}'",

    "file_regex": " +--> +([a-zA-Z_\/.-]+):(\d+):(\d+)::::(.*)"

}

This also treats warnings in the same way:

"shell_cmd": "cargo build 2>&1 | awk 'BEGIN { errmsg="" } /(error|warning)(\[E[0-9]+\])?:.*/ {errmsg=\$0; next} /\ *-->\ *.*/ { printf "%s::::%s\n", \$0, errmsg; next} {print \$0}'",