Proposed solution after the discussion in microsoft/vscode-go#2696:

Show a warning before even starting delve in such cases. We can have this warning include 2 buttons: Ignore GOOS and GOARCH from settings and Continue.

This can be done in the goDebugConfiguration.ts file as suggested in the Code Pointers in microsoft/vscode-go#2696 (comment)

The most recent message looks like so (still not immediately obvious what the issue is):

@aarzilli
In which cases are cross-platform GOOS/GOARCH useful? I think core mode is one. Instead of implementing a user prompt, perhaps it would be cleaner to ignore these for certain modes?

I think ignoring them would lead users into thinking they are accomplishing something by setting GOOS/GOARCH. I think we should do what the user asks and fail, so that the user can better form a model of what delve does.

In which cases are cross-platform GOOS/GOARCH useful? I think core mode is one

In any case where we don't call the compiler GOOS/GOARCH aren't used and therefore do not interfere, including core mode. I wouldn't call that "useful"

I think ignoring them would lead users into thinking they are accomplishing something by setting GOOS/GOARCH. I think we should do what the user asks and fail, so that the user can better form a model of what delve does.

This issue was filed because a user did cross-platform development and accidentally left the settings intended for gopls in the global configuration and forgot about them. Then later when they tried to launch-debug, the settings were applied and they got an error, but the message said nothing about the os/arch mismatch, so they were not sure what was going on and asked that we improve the error message.

The conclusion a while back was that vscode-go extension could compare GOOS/GOARCH to that of the machine and if they did not match, offer warning and a prompt to ignore them or continue. But if these settings are never useful in any or all cases, then why do the check and offer a choice at all? That's what I am trying to determine: when are they useful? We don't have to silently ignore them when they are not. We can always print a warning and update documentation.

In any case where we don't call the compiler GOOS/GOARCH aren't used and therefore do not interfere, including core mode. I wouldn't call that "useful"

Ah, I see. I just assumed they are used somehow because I remember reading that you can debug core file from one platform while running dlv on another.

All of this is also true for go run:

$ GOARCH=arm64 go run hello.go
fork/exec /dev/shm/go-build2434359517/b001/exe/test: exec format error

But if these settings are never useful in any or all cases, then why do the check and offer a choice at all? That's what I am trying to determine: when are they useful? We don't have to silently ignore them when they are not. We can always print a warning and update documentation.

In my opinion showing an error is a better user experience than silently ignoring the setting. If the user sees a prompt, "Hey you tried to debug using an incompatible GOOS/GOARCH," it's pretty obvious what happened.

I can easily imagine a scenario where I'm running on Linux, working on stuff_windows.go, I set GOOS to make sure the Windows-specific code compiles, then decide I need to test it and try to debug. Obviously that wouldn't work, but sometimes I forget pesky details like "you can't run Windows code on Linux" when I'm in the zone. And I can easily imagine myself spending an extremely frustrating 10 minutes trying to figure out why the code I'm working on isn't being debugged before I remember "DOH! 🤦 I can't debug Windows code on Linux!"

There's a great book on human-interface usability called Don't Make Me Think. When designing UX, the less the user has to think the better their experience will be. If an error message pops up telling me "Hey you can't do that" I don't have to think. That's a much better UX than spending time trying to figure out why code isn't running.

All of this is also true for go run:

$ GOARCH=arm64 go run hello.go
fork/exec /dev/shm/go-build2434359517/b001/exe/test: exec format error

It would be nice if go run had a better error message, but at least when I see "exec format error" I know exactly what's wrong.

All of this is also true for go run:

$ GOARCH=arm64 go run hello.go
fork/exec /dev/shm/go-build2434359517/b001/exe/test: exec format error

I think a big difference between this instance of go run or even

$ GOOS=windows dlv debug  _fixtures/increment.go 
could not launch process: not an executable file

is that when you see a failure, you know exactly what to inspect for issues - your command-line. When it happens in vscode, the problem is buried deep in settings. You get a standard message to check launch.json, but settings.json. And even then, which of the many fields there is the likely offender? It's not clear. I think it would be nice to improve the error message.

I was assuming it was coming from some underlying dependencies, but I see now that it is defined in delve itself, so this seems like an easy fix.

is that when you see a failure, you know exactly what to inspect for issues - your command-line. When it happens in vscode, the problem is buried deep in settings

Not really, you could have the environment variable set somewhere else.