gopls: time.Format with the bad format "2006-02-01" causes gopls to hang (new analyzer)

[Phadin]

What version of Go, VS Code & VS Code Go extension are you using?

Version Information

• Run go version to get version of Go from the VS Code integrated terminal.
  • go version go1.19 darwin/amd64
• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders.
  • 1.70.1 (Universal)
• Check your installed extensions to get the version of the VS Code Go extension
  • v0.35.1

• Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) > Go: Locate Configured Go Tools command.

  go: /usr/local/bin/go: go version go1.19 darwin/amd64
  gotests: not installed
  gomodifytags: not installed
  impl: not installed
  goplay: not installed
  dlv: /Users/mbarri202/go/bin/dlv (version: v1.9.0 built with go: go1.19)
  staticcheck: /Users/mbarri202/go/bin/staticcheck (version: v0.3.3 built with go: go1.19)
  gopls: /Users/mbarri202/go/bin/gopls (version: v0.9.3 built with go: go1.19)

Describe the bug

Intellisense/gopls dies when using custom time format with time.Format. Go: Restart Language Server will work to restore functionality only if the offending code is removed or there are code errors preventing it from being run through. When the error occurs, hovering over text is stuck with a 'loading...' box, saving will hang on trying to access go formatting, and autocomplete will not function.

Steps to reproduce the behavior:

Go code that will cause the error:

now := time.Now()
nowFormatted := now.Format("2006-02-01")
fmt.Printf("Time: %v", nowFormatted)

Note that no error occurs with other time.Format functions such as now.Format(time.RFC822). It seemed to only occur with this custom format.

[findleyr]

Hi, thank you for reporting. I was not able to reproduce following your instructions. Can you please attach the panicking stack? (you can find this via output -> gopls (server)).

[findleyr]

Wait, I do believe I can reproduce: I don't get a crash, but rather a hanging process.

I am investigating.

[findleyr]

Well, yes it is reliably reproducible, and only with that format.

Almost certainly this is related to https://go.dev/cl/354010. Note that the format "2006-02-01" is likely wrong, per the discussion in https://go.dev/issue/48801. But of course it should not make gopls hang.

CC @timothy-king (Tim: no action required from you, just keeping you informed that there may be a bug in this analyzer).

Amazing that this was caught so soon. Thank you very much for filing an issue!

[findleyr]

The root cause is a debug print statement left in the analyzer, which breaks gopls' communication over stdin/stdout.

[eqinox76]

Hit the same issue with time.Format("2006-02-01 15:04:05").
Kudos for adding this check even if the print statement is unfortunate.

[gopherbot]

Change https://go.dev/cl/422902 mentions this issue: go/analysis: remove stray print statement in the timeformat analyzer

[findleyr]

Reopening and pinning until this is released.

Since it is Friday, we likely won't cut a new release until Monday.

[gopherbot]

Change https://go.dev/cl/422903 mentions this issue: go/analysis: remove stray print statement in the timeformat analyzer

[findleyr]

The fix for this issue will be released on Monday (we don't do releases late in the day on Friday, I'm afraid).

In the meantime, anyone encountering this bug can take any one of the following mitigating steps:

• Remove the bad format string
• Disable the "timeformat" analyzer (see documentation)
• Downgrade to [email protected] (go install golang.org/x/tools/[email protected]), which doesn't contain this regression.
• Upgrade to the patched version of gopls that will be released on Monday (go install golang.org/x/tools/[email protected]).

[Phadin]

Thank you for the quick verification and work on releasing a fix.

[findleyr]

This fix has been released in [email protected].