VS Code: Add release profile task

[pigrew]

With the provided VS Code build task, I end up with an unoptimized debug build. Could a new task be added for the "release" profile?

(I can't figure out the syntax for specified arguments to a "cargo" task type, but did get it working by changing it to use the "process" type. Perhaps this is a limitation of the RLS plugin?)

The following task works for me (but I don't know if it is the desired solution):

        {
            "label": "build_release",
            "type": "process",
            "command": "cargo",
            "args": ["build", "--release"],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "problemMatcher": [
                "$rustc"
            ]
        }

[thejpster]

@rubberduck203 any thoughts on this one?

[rubberduck203]

I use a shell task to build examples, but I feel like there should be a “native” way to do a release build. Let me look into it.

[pigrew]

Would you like me to create a PR for my above solution? Or create an issue on the RLS VsCode plugin tracker, to ask for help?

[rubberduck203]

This issue is already open for the ability for RLS provided build tasks to perform a build in release mode.

rust-lang/vscode-rust#703

I would go ahead and open a PR.

Quick discussion first though. I’m not sure release should be the default. I think the default should be debug so the debugger works as expected out of the box. Thoughts on that?

[rubberduck203]

@pigrew I built on your solution and opened a PR that adds release, examples, and a clean task.

[rubberduck203]

Moving some of the conversation here from PR #82.

Can we also make a "Release (OpenOCD)" launch? That was the (unstated) intent of issue #80.

#82 (comment)

Well, we can, but debugging in release won’t behave as expected for most people

#82 (comment)

It seems simpler to add the launch, versus another task? To me, using a task has more implementation complexity in order to prevent the user from having an easy way to debug release builds. It also means the user most look one place (launches) to run a debug build, but another to run a release build.

#82 (comment)

You make a good point. I think I’d like someone from the QuickStart team to weigh in.

#82 (comment)

[rubberduck203]

I’ve been thinking about this trying to come up with what the expected behavior of this task would be. Here are my current thoughts.

• Build in release mode (duh)
• load the executable
• Begin executing immediately, do not pause on pre-init or main.

Is that reasonable behavior @pigrew? What is your current workflow like?

[pigrew]

@rubberduck203

That would be fine with me.

I'm used to it pausing at init/main when I load the program (this is what Eclipse-based GUIs do that I've used do by default), however I don't have a strong preference either way on what the default should be.

Pausing may be desired so that the user experience is as similar as possible between debug and release builds. In some cases, I want it to pause at main so that I can trigger an oscilloscope. Pausing also gives me a clear indication that the new binary was loaded.

The advantage of not pausing would be that it's one fewer button for the user to click during each debug cycle.

[rubberduck203]

Ok. Sounds like it should pause then.
I think a launch config should be pretty straight forward now that the release build task has been merged.

[rubberduck203]

rubberduck203 commented on Mar 10, 2020

So, life got crazy right around then and I lost track of this.
My apologies.
I'll see what I can do about this issue.
We already have a task to build in release mode, so it shouldn't be too much work.
I just need to go find my hardware...