Metals 1.3.0 under Windows cannot run scala-cli project main through cmd.exe

[soronpo]

Describe the bug

Running any basic @main def hello = println("hello") in a scala-cli project by clicking run yields the following error:
The terminal process failed to launch: Path to shell executable "cmd.exe" does not exist.
My SBT-based project seems fine.
It caused me to chase down the wrong rabbit hole of VS code cmd.exe issues.
I downgraded to v1.2.2, and it works as expected, then reupgraded to v1.3.0 and it's broken. Definitely a metals issue.

Expected behavior

Run as expected

Operating system

Windows

Editor/Extension

VS Code

Version of Metals

v1.3.0

Extra context or search terms

No response

[tgodzik]

Thanks for reporting. Do you have a full path being invoked? We didn't really change anything related to invoking main, and cmd.exe seems like something that should be always available.

[soronpo]

Do you have a full path being invoked?

It just invokes cmd.exe like always.
Do you have Windows to see if this is just my computer that is somehow sensitive to v1.3.0 perhaps?

[tgodzik]

Looks to be working for me correctly on Windows.

This is how we define the task:

function platformSpecificOptions(): vscode.ShellExecutionOptions {
  if (platform() == "win32") {
    return { executable: "cmd.exe", shellArgs: ["/c"] };
  } else {
    return {};
  }
}

I wasn't able to make it work any other wat on Windows.

I wonder why Path to shell executable "cmd.exe" does not exist. happens, cmd should always be avaiable. Unless you have a different default shell and that is influencing the outcome?

[soronpo]

I don't know what to tell you. I tried it again. Downgrading works. Upgrading fails.
Single-file project.

//> using scala "3.4.0"

@main def main = println("hello")

v1.2.2

v1.3.0

[soronpo]

I'm on Windows 10 Pro, if it makes any difference.

[tgodzik]

This is quite surprising, nothing really changed aside from scalameta/metals-vscode#1479 but I can't figure out how would that influence you. Maybe it's just this specific name combination?

The other big thing that changes is java detection, but that seems exactly the same, so it can't be it.

[soronpo]

Here is a thought (sorry, could be a dumb idea, because I don't know how Metals is working with VSCode):
When you build the plugin, are you using some VSCode dependencies? Maybe one of the dependencies changed in a way to cause this.

[tgodzik]

Here is a thought (sorry, could be a dumb idea, because I don't know how Metals is working with VSCode): When you build the plugin, are you using some VSCode dependencies? Maybe one of the dependencies changed in a way to cause this.

That is possible, but then why would it break on your windows and not on mine. I just can see the exact difference that can explain it. I have a lead to take a look at later, but I wasn't on my windows machine yesterday.

[soronpo]

I just tried 1.3.1 and everything is OK, so maybe it was a one-time glitch or something that was actually fixed. I think we can close it for now.

[tgodzik]

Let's reopen if this happen again.