tasks.json Support

[jcdickinson]

Move the task provider anonymous class into a real class, as this seems to be how Microsoft do this in their documentation.

resolveTask is now implemented, which is used by VSCode to determine how to execute tasks that the user has defined in tasks.json.

Resolves #3983

[jcdickinson]

Turns out I didn't need much time to fix this :).

[matklad]

bors r+

Thanks!

[bors]

Build succeeded:

• Rust (macos-latest)
• Rust (ubuntu-latest)
• Rust (windows-latest)
• TypeScript

[Keavon]

@jcdickinson Is this a bad place to ask a question related to tasks.json? I am trying to make CtrlShiftB (the default build task) execute cargo run but I only see default options for cargo build and cargo check. I tried setting this to my tasks.json:

{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "cargo",
            "command": "run",
            "problemMatcher": [
                "$rustc"
            ],
            "group": { "kind": "build", "isDefault": true },
            "label": "rust: cargo run"
        }
    ]
}

But it's ignoring the default task, and just popping up the "Select the build task to run" palette menu and showing "There are task errors. See the output for details." where the Output console says:

Error: The cargo task detection didn't contribute a task for the following configuration:
{
    "type": "cargo",
    "command": "run",
    "problemMatcher": [
        "$rustc"
    ],
    "group": {
        "kind": "build",
        "isDefault": true
    },
    "label": "rust: cargo run"
}
The task will be ignored.

Can there be a default for cargo run or can this be fixed or explained to me how to fix it? I am running the latest non-nightly release (I just installed Rust Analyzer and didn't opt in to nightlies.)

(And again, sorry if this isn't the best spot for the question, I can also move it to an issue if it belongs there.)

[jcdickinson]

@Keavon you will have to build the extension from source, or wait for an update on the VSCode extension store. The nightly setting wouldn't even help here, as that doesn't govern the version of the extension (it only covers the language server version).

[Keavon]

@jcdickinson I see, so it's a matter of the extension updating now the language server. And to clarify, the issue I was having is fixed now, just not yet deployed to the VS Code extension store? I don't quite understand what this merge request is about, but does it fix the problem I described? Once the web store updates, what behavior will I see? Thanks!

[jcdickinson]

@Keavon you can download the VSIX from the updates page and manually install it to try out the changes.