add editor run actions for Swift executables

[matthewbastien]

This PR adds two new actions in the editor for running and debugging the active Swift file. These actions use existing commands and are only shown when the active Swift file belongs to an executable target.

[MahdiBM]

I can see the wording being confusing. It won't actually run that specific single file, will it?

Maybe "Run recent Swift executable"? So also if you switch to another file for a sec it won't just go away since it says "recent"?

I could also get behind just having it for the "current Swift executable" since I'd guess it will have a more predictable algorithms and users won't need to remember what executable they were working on last.
But I'd still slightly prefer "recent" since I feel like that's what will be more useful to me based on what I remember from working on stuff.

Also would be nice to have build actions for current active target as well, perhaps in another PR. Related to #1320

[matthewbastien]

Yeah, that's a good point. The command looks at the most recently opened Swift file and runs the executable target that builds it (if any). Though wording it as Run recent Swift executable would look weird in the editor action, imo.

I think what I'd rather do is rename the two commands Run Swift executable/Debug Swift executable and hide them from the command palette. As far as I'm aware these commands are only used by SourceKit-LSP to launch targets via CodeLens. In this case (and the case of clicking the run button in the editor actions) then there is definitely an active file that can be run/debug in a Swift executable. I wouldn't expect a user to run this command themselves from the command palette.

[matthewbastien]

Actually, taking a closer look at this we already limit the run and debug commands to show up in the command palette only when a Swift file built by an executable target is active. I've just renamed the commands because of this. Let me know what you think.

[MahdiBM]

hmm I never noticed these commands but I can see them now. This is actually pretty cool, I would've used these commands if I knew they existed. I probably wished for something like this a few times. Though most of the times I probably want just a "Build" not a "Run".

vapor/penny-bot has IIIRC 8 executables, so it would be nice to have these commands so I don't even need to pay attention to "what lambda executable am I in?" then do CMD+B CMD+SHIFT+B and choose that specific executable to build. Swift's build times are relatively slow so I usually would like to only build what I'm actually focusing on.

So can we have these same commands but only for building the active target? Should I create a new issue?

Also for visibility, should we not conditionally hide these commands and maybe just error out with "current file is not executable" or just run the most recent executable? Not 100% sure about this recommendation but sounds like an improvement to me right now. WDYT?

[matthewbastien]

vapor/penny-bot has IIIRC 8 executables, so it would be nice to have these commands so I don't even need to pay attention to "what lambda executable am I in?" then do CMD+B and choose that specific executable to build. Swift's build times are relatively slow so I usually would like to only build what I'm actually focusing on.

You should be able to build a specific target by running the appropriate build task. If you use the VS Code shortcut CMD + Shift + B it'll pop up build tasks for all of your targets. Is that what you're looking for?

Also for visibility, should we not conditionally hide these commands and maybe just error out with "current file is not executable" or just run the most recent executable? Not 100% sure about this recommendation but sounds like an improvement to me right now. WDYT?

I'll have to think about that one more. Perhaps it makes more sense to add a new command that gives you a dropdown of all available targets that can be debugged? Could be another entry point into debugging.

[award999]

Maybe a palette command for letting the user select a target, but I wouldn't think we'd add it as an editor action which are intended to be provided for the context of the current editor

[MahdiBM]

@matthewbastien

If you use the VS Code shortcut CMD + Shift + B

That's actually what I meant by "CMD+B" in my comment. That's fine and it's doing what it's supposed to, but no that's not what I want considering that's what I already have/use.

I prefer an easier way to trigger the right build. I guess It's more complicated than what I thought considering users might want to have custom build settings and a simple command pallete command is probably not the best place for that 🤔.

In the ideal world the extension would just know what build task I want to run (first build task that is related to the current most recent file perhaps?) and I can just use that. But maybe I'm getting a bit impractical. Maybe "Xcode schemes" is the best thing we could have without getting too messy, considering other stuff like the "background compilation" feature can also use that to not build the whole app when a specific "scheme" is selected, like mentioned in #1320 🤔

[matthewbastien]

Ah, I think I see what you mean now. Yeah that's something that needs some design work for sure to make it practical. Thanks for raising that issue!

[plemarquand]

Verified in cef4e6c