2020-03-10 22:49:10 -06:00
|
|
|
// Copyright 2020 The Go Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
2019-09-18 23:21:54 -06:00
|
|
|
package lsp
|
|
|
|
|
|
|
|
import (
|
internal/lsp: improvements for command messages
When falling back to messages for progress reporting, don't try to
implement cancellation via ShowMessageCommand dialogs. They are an
imperfect solution, as the dialog stays open even after the command
completed. Also, among the LSP clients that don't support workDone
reporting, I suspect many also don't support ShowMessageCommand (for
example, govim), so the audience for this feature is probably quite
small.
Just remove it, and instead show a (non-cancellable) message. If clients
want cancellation, workDone progress support is the way to provide it.
Also remove a redundant message on go-generate success, and attach logs
when tests fail. Without logs on failure, I find that the test command
is not very useful. I tested a bit with very verbose test output, and
both VS Code and coc.nvim handled it gracefully.
Finally, fix a bug causing benchmarks not to be run.
Change-Id: I05422bcefc857c25cd99e643e614a0bc33870586
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249702
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-08-21 12:18:37 -06:00
|
|
|
"bytes"
|
2019-09-18 23:21:54 -06:00
|
|
|
"context"
|
2020-08-17 20:50:34 -06:00
|
|
|
"encoding/json"
|
2020-07-10 18:17:16 -06:00
|
|
|
"fmt"
|
2020-05-05 12:43:51 -06:00
|
|
|
"io"
|
2020-08-17 20:50:34 -06:00
|
|
|
"log"
|
2020-07-16 08:45:30 -06:00
|
|
|
"path"
|
2019-09-18 23:21:54 -06:00
|
|
|
|
2020-07-15 21:33:55 -06:00
|
|
|
"golang.org/x/tools/internal/event"
|
2019-09-18 23:21:54 -06:00
|
|
|
"golang.org/x/tools/internal/lsp/protocol"
|
|
|
|
"golang.org/x/tools/internal/lsp/source"
|
2020-06-11 16:25:17 -06:00
|
|
|
"golang.org/x/tools/internal/span"
|
2020-03-10 22:49:10 -06:00
|
|
|
"golang.org/x/tools/internal/xcontext"
|
2019-09-18 23:21:54 -06:00
|
|
|
errors "golang.org/x/xerrors"
|
|
|
|
)
|
|
|
|
|
|
|
|
func (s *Server) executeCommand(ctx context.Context, params *protocol.ExecuteCommandParams) (interface{}, error) {
|
2020-07-23 21:24:36 -06:00
|
|
|
var command *source.Command
|
|
|
|
for _, c := range source.Commands {
|
|
|
|
if c.Name == params.Command {
|
|
|
|
command = c
|
2020-07-10 18:17:16 -06:00
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
2020-07-23 21:24:36 -06:00
|
|
|
if command == nil {
|
|
|
|
return nil, fmt.Errorf("no known command")
|
|
|
|
}
|
|
|
|
var match bool
|
|
|
|
for _, name := range s.session.Options().SupportedCommands {
|
|
|
|
if command.Name == name {
|
|
|
|
match = true
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if !match {
|
|
|
|
return nil, fmt.Errorf("%s is not a supported command", command.Name)
|
2020-07-10 18:17:16 -06:00
|
|
|
}
|
2020-07-14 18:40:38 -06:00
|
|
|
// Some commands require that all files are saved to disk. If we detect
|
|
|
|
// unsaved files, warn the user instead of running the commands.
|
|
|
|
unsaved := false
|
|
|
|
for _, overlay := range s.session.Overlays() {
|
|
|
|
if !overlay.Saved() {
|
|
|
|
unsaved = true
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if unsaved {
|
2020-07-16 08:45:30 -06:00
|
|
|
switch params.Command {
|
|
|
|
case source.CommandTest.Name, source.CommandGenerate.Name, source.CommandToggleDetails.Name:
|
|
|
|
// TODO(PJW): for Toggle, not an error if it is being disabled
|
2020-08-16 12:45:47 -06:00
|
|
|
err := fmt.Errorf("cannot run command %s: unsaved files in the view", params.Command)
|
|
|
|
s.client.ShowMessage(ctx, &protocol.ShowMessageParams{
|
2020-05-05 12:43:51 -06:00
|
|
|
Type: protocol.Error,
|
2020-08-16 12:45:47 -06:00
|
|
|
Message: err.Error(),
|
2020-05-05 12:43:51 -06:00
|
|
|
})
|
2020-08-16 12:45:47 -06:00
|
|
|
return nil, err
|
2020-05-05 12:43:51 -06:00
|
|
|
}
|
2020-07-14 18:40:38 -06:00
|
|
|
}
|
2020-07-23 21:24:36 -06:00
|
|
|
// If the command has a suggested fix function available, use it and apply
|
|
|
|
// the edits to the workspace.
|
|
|
|
if command.IsSuggestedFix() {
|
|
|
|
var uri protocol.DocumentURI
|
|
|
|
var rng protocol.Range
|
|
|
|
if err := source.UnmarshalArgs(params.Arguments, &uri, &rng); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2020-07-02 16:34:10 -06:00
|
|
|
snapshot, fh, ok, release, err := s.beginFileRequest(ctx, uri, source.Go)
|
|
|
|
defer release()
|
2020-07-23 21:24:36 -06:00
|
|
|
if !ok {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
edits, err := command.SuggestedFix(ctx, snapshot, fh, rng)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
r, err := s.client.ApplyEdit(ctx, &protocol.ApplyWorkspaceEditParams{
|
|
|
|
Edit: protocol.WorkspaceEdit{
|
|
|
|
DocumentChanges: edits,
|
|
|
|
},
|
|
|
|
})
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
if !r.Applied {
|
|
|
|
return nil, s.client.ShowMessage(ctx, &protocol.ShowMessageParams{
|
|
|
|
Type: protocol.Error,
|
|
|
|
Message: fmt.Sprintf("%s failed: %v", params.Command, r.FailureReason),
|
|
|
|
})
|
|
|
|
}
|
|
|
|
return nil, nil
|
|
|
|
}
|
2020-08-17 20:50:34 -06:00
|
|
|
title := command.Title
|
|
|
|
if title == "" {
|
|
|
|
title = command.Name
|
|
|
|
}
|
|
|
|
ctx, cancel := context.WithCancel(xcontext.Detach(ctx))
|
|
|
|
// Start progress prior to spinning off a goroutine specifically so that
|
|
|
|
// clients are aware of the work item before the command completes. This
|
|
|
|
// matters for regtests, where having a continuous thread of work is
|
|
|
|
// convenient for assertions.
|
internal/lsp: improvements for command messages
When falling back to messages for progress reporting, don't try to
implement cancellation via ShowMessageCommand dialogs. They are an
imperfect solution, as the dialog stays open even after the command
completed. Also, among the LSP clients that don't support workDone
reporting, I suspect many also don't support ShowMessageCommand (for
example, govim), so the audience for this feature is probably quite
small.
Just remove it, and instead show a (non-cancellable) message. If clients
want cancellation, workDone progress support is the way to provide it.
Also remove a redundant message on go-generate success, and attach logs
when tests fail. Without logs on failure, I find that the test command
is not very useful. I tested a bit with very verbose test output, and
both VS Code and coc.nvim handled it gracefully.
Finally, fix a bug causing benchmarks not to be run.
Change-Id: I05422bcefc857c25cd99e643e614a0bc33870586
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249702
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-08-21 12:18:37 -06:00
|
|
|
work := s.progress.start(ctx, title, title+": running...", params.WorkDoneToken, cancel)
|
2020-08-17 20:50:34 -06:00
|
|
|
go func() {
|
|
|
|
defer cancel()
|
|
|
|
err := s.runCommand(ctx, work, command, params.Arguments)
|
|
|
|
switch {
|
|
|
|
case errors.Is(err, context.Canceled):
|
internal/lsp: improvements for command messages
When falling back to messages for progress reporting, don't try to
implement cancellation via ShowMessageCommand dialogs. They are an
imperfect solution, as the dialog stays open even after the command
completed. Also, among the LSP clients that don't support workDone
reporting, I suspect many also don't support ShowMessageCommand (for
example, govim), so the audience for this feature is probably quite
small.
Just remove it, and instead show a (non-cancellable) message. If clients
want cancellation, workDone progress support is the way to provide it.
Also remove a redundant message on go-generate success, and attach logs
when tests fail. Without logs on failure, I find that the test command
is not very useful. I tested a bit with very verbose test output, and
both VS Code and coc.nvim handled it gracefully.
Finally, fix a bug causing benchmarks not to be run.
Change-Id: I05422bcefc857c25cd99e643e614a0bc33870586
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249702
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-08-21 12:18:37 -06:00
|
|
|
work.end(title + ": canceled")
|
2020-08-17 20:50:34 -06:00
|
|
|
case err != nil:
|
internal/lsp: improvements for command messages
When falling back to messages for progress reporting, don't try to
implement cancellation via ShowMessageCommand dialogs. They are an
imperfect solution, as the dialog stays open even after the command
completed. Also, among the LSP clients that don't support workDone
reporting, I suspect many also don't support ShowMessageCommand (for
example, govim), so the audience for this feature is probably quite
small.
Just remove it, and instead show a (non-cancellable) message. If clients
want cancellation, workDone progress support is the way to provide it.
Also remove a redundant message on go-generate success, and attach logs
when tests fail. Without logs on failure, I find that the test command
is not very useful. I tested a bit with very verbose test output, and
both VS Code and coc.nvim handled it gracefully.
Finally, fix a bug causing benchmarks not to be run.
Change-Id: I05422bcefc857c25cd99e643e614a0bc33870586
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249702
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-08-21 12:18:37 -06:00
|
|
|
event.Error(ctx, fmt.Sprintf("%s: command error", title), err)
|
|
|
|
work.end(title + ": failed")
|
2020-08-17 20:50:34 -06:00
|
|
|
// Show a message when work completes with error, because the progress end
|
|
|
|
// message is typically dismissed immediately by LSP clients.
|
|
|
|
s.client.ShowMessage(ctx, &protocol.ShowMessageParams{
|
|
|
|
Type: protocol.Error,
|
internal/lsp: improvements for command messages
When falling back to messages for progress reporting, don't try to
implement cancellation via ShowMessageCommand dialogs. They are an
imperfect solution, as the dialog stays open even after the command
completed. Also, among the LSP clients that don't support workDone
reporting, I suspect many also don't support ShowMessageCommand (for
example, govim), so the audience for this feature is probably quite
small.
Just remove it, and instead show a (non-cancellable) message. If clients
want cancellation, workDone progress support is the way to provide it.
Also remove a redundant message on go-generate success, and attach logs
when tests fail. Without logs on failure, I find that the test command
is not very useful. I tested a bit with very verbose test output, and
both VS Code and coc.nvim handled it gracefully.
Finally, fix a bug causing benchmarks not to be run.
Change-Id: I05422bcefc857c25cd99e643e614a0bc33870586
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249702
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-08-21 12:18:37 -06:00
|
|
|
Message: fmt.Sprintf("%s: An error occurred: %v", title, err),
|
2020-08-17 20:50:34 -06:00
|
|
|
})
|
|
|
|
default:
|
internal/lsp: improvements for command messages
When falling back to messages for progress reporting, don't try to
implement cancellation via ShowMessageCommand dialogs. They are an
imperfect solution, as the dialog stays open even after the command
completed. Also, among the LSP clients that don't support workDone
reporting, I suspect many also don't support ShowMessageCommand (for
example, govim), so the audience for this feature is probably quite
small.
Just remove it, and instead show a (non-cancellable) message. If clients
want cancellation, workDone progress support is the way to provide it.
Also remove a redundant message on go-generate success, and attach logs
when tests fail. Without logs on failure, I find that the test command
is not very useful. I tested a bit with very verbose test output, and
both VS Code and coc.nvim handled it gracefully.
Finally, fix a bug causing benchmarks not to be run.
Change-Id: I05422bcefc857c25cd99e643e614a0bc33870586
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249702
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-08-21 12:18:37 -06:00
|
|
|
work.end(command.Name + ": completed")
|
2020-08-17 20:50:34 -06:00
|
|
|
}
|
|
|
|
}()
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (s *Server) runCommand(ctx context.Context, work *workDone, command *source.Command, args []json.RawMessage) error {
|
2020-07-23 21:24:36 -06:00
|
|
|
switch command {
|
2020-07-14 18:40:38 -06:00
|
|
|
case source.CommandTest:
|
|
|
|
var uri protocol.DocumentURI
|
2020-07-30 16:48:51 -06:00
|
|
|
var tests, benchmarks []string
|
2020-08-17 20:50:34 -06:00
|
|
|
if err := source.UnmarshalArgs(args, &uri, &tests, &benchmarks); err != nil {
|
|
|
|
return err
|
2020-05-05 12:43:51 -06:00
|
|
|
}
|
2020-07-02 16:34:10 -06:00
|
|
|
snapshot, _, ok, release, err := s.beginFileRequest(ctx, uri, source.UnknownKind)
|
|
|
|
defer release()
|
2020-07-14 18:40:38 -06:00
|
|
|
if !ok {
|
2020-08-17 20:50:34 -06:00
|
|
|
return err
|
2020-05-05 12:43:51 -06:00
|
|
|
}
|
2020-08-17 20:50:34 -06:00
|
|
|
return s.runTests(ctx, snapshot, uri, work, tests, benchmarks)
|
2020-05-06 20:54:50 -06:00
|
|
|
case source.CommandGenerate:
|
2020-07-14 18:40:38 -06:00
|
|
|
var uri protocol.DocumentURI
|
|
|
|
var recursive bool
|
2020-08-17 20:50:34 -06:00
|
|
|
if err := source.UnmarshalArgs(args, &uri, &recursive); err != nil {
|
|
|
|
return err
|
2020-03-10 22:49:10 -06:00
|
|
|
}
|
2020-07-02 16:34:10 -06:00
|
|
|
snapshot, _, ok, release, err := s.beginFileRequest(ctx, uri, source.UnknownKind)
|
|
|
|
defer release()
|
|
|
|
if !ok {
|
2020-08-17 20:50:34 -06:00
|
|
|
return err
|
2020-07-02 16:34:10 -06:00
|
|
|
}
|
2020-08-17 20:50:34 -06:00
|
|
|
return s.runGoGenerate(ctx, snapshot, uri.SpanURI(), recursive, work)
|
2020-05-14 12:02:48 -06:00
|
|
|
case source.CommandRegenerateCgo:
|
2020-07-14 18:40:38 -06:00
|
|
|
var uri protocol.DocumentURI
|
2020-08-17 20:50:34 -06:00
|
|
|
if err := source.UnmarshalArgs(args, &uri); err != nil {
|
|
|
|
return err
|
2020-07-14 18:40:38 -06:00
|
|
|
}
|
2020-05-14 12:02:48 -06:00
|
|
|
mod := source.FileModification{
|
2020-07-14 18:40:38 -06:00
|
|
|
URI: uri.SpanURI(),
|
2020-05-14 12:02:48 -06:00
|
|
|
Action: source.InvalidateMetadata,
|
|
|
|
}
|
2020-08-17 20:50:34 -06:00
|
|
|
return s.didModifyFiles(ctx, []source.FileModification{mod}, FromRegenerateCgo)
|
2020-05-28 19:21:29 -06:00
|
|
|
case source.CommandTidy, source.CommandVendor:
|
2020-07-14 18:40:38 -06:00
|
|
|
var uri protocol.DocumentURI
|
2020-08-17 20:50:34 -06:00
|
|
|
if err := source.UnmarshalArgs(args, &uri); err != nil {
|
|
|
|
return err
|
2019-09-18 23:21:54 -06:00
|
|
|
}
|
2020-05-28 19:21:29 -06:00
|
|
|
// The flow for `go mod tidy` and `go mod vendor` is almost identical,
|
|
|
|
// so we combine them into one case for convenience.
|
2020-07-14 18:40:38 -06:00
|
|
|
a := "tidy"
|
2020-07-23 21:24:36 -06:00
|
|
|
if command == source.CommandVendor {
|
2020-07-14 18:40:38 -06:00
|
|
|
a = "vendor"
|
2019-09-18 23:21:54 -06:00
|
|
|
}
|
2020-08-17 20:50:34 -06:00
|
|
|
return s.directGoModCommand(ctx, uri, "mod", []string{a}...)
|
2020-05-06 20:54:50 -06:00
|
|
|
case source.CommandUpgradeDependency:
|
2020-07-14 18:40:38 -06:00
|
|
|
var uri protocol.DocumentURI
|
2020-07-27 14:47:26 -06:00
|
|
|
var goCmdArgs []string
|
2020-08-17 20:50:34 -06:00
|
|
|
if err := source.UnmarshalArgs(args, &uri, &goCmdArgs); err != nil {
|
|
|
|
return err
|
2020-02-06 12:50:26 -07:00
|
|
|
}
|
2020-08-17 20:50:34 -06:00
|
|
|
return s.directGoModCommand(ctx, uri, "get", goCmdArgs...)
|
2020-07-16 08:45:30 -06:00
|
|
|
case source.CommandToggleDetails:
|
|
|
|
var fileURI span.URI
|
2020-08-17 20:50:34 -06:00
|
|
|
if err := source.UnmarshalArgs(args, &fileURI); err != nil {
|
|
|
|
return err
|
2020-07-16 08:45:30 -06:00
|
|
|
}
|
2020-07-30 13:10:16 -06:00
|
|
|
pkgDir := span.URIFromPath(path.Dir(fileURI.Filename()))
|
2020-07-28 18:05:06 -06:00
|
|
|
s.gcOptimizationDetailsMu.Lock()
|
|
|
|
if _, ok := s.gcOptimizatonDetails[pkgDir]; ok {
|
2020-07-16 08:45:30 -06:00
|
|
|
delete(s.gcOptimizatonDetails, pkgDir)
|
|
|
|
} else {
|
2020-07-28 18:05:06 -06:00
|
|
|
s.gcOptimizatonDetails[pkgDir] = struct{}{}
|
2020-07-16 08:45:30 -06:00
|
|
|
}
|
2020-07-28 18:05:06 -06:00
|
|
|
s.gcOptimizationDetailsMu.Unlock()
|
2020-07-28 17:45:42 -06:00
|
|
|
event.Log(ctx, fmt.Sprintf("gc_details %s now %v %v", pkgDir, s.gcOptimizatonDetails[pkgDir],
|
2020-07-16 08:45:30 -06:00
|
|
|
s.gcOptimizatonDetails))
|
|
|
|
// need to recompute diagnostics.
|
|
|
|
// so find the snapshot
|
|
|
|
sv, err := s.session.ViewOf(fileURI)
|
|
|
|
if err != nil {
|
2020-08-17 20:50:34 -06:00
|
|
|
return err
|
2020-07-16 08:45:30 -06:00
|
|
|
}
|
internal/memoize: switch from GC-driven to explicit deletion
The GC-based cache has given us a number of problems. First, memory
leaks driven by reference cycles: the Go runtime cannot collect cycles
involving finalizers, which prevents us from writing natural code in
Bind callbacks. If we screw it up, we get a mysterious leak that takes a
long time to track down. Second, the behavior is generally mysterious;
it's hard to predict how long a value lasts, and harder to tell if a
value being live is a bug. Third, we think that it may be interacting
poorly with the GC, resulting in unnecessary memory usage.
The structure of the values we put in the cache is not actually that
complicated -- there are only 5 significant types: parse, typecheck,
analyze, parse mod, and analyze mod. Managing them manually should not
be conceptually difficult, and in fact we already do most of the work
in (*snapshot).clone.
In this CL the cache adds the concept of "generations", which function
as reference counts on cache entries. Entries are still global and
shared across generations, but will be explicitly deleted once no
generations refer to them. The idea is that each snapshot is a new
generation, and can inherit entries from the previous snapshot or leave
them behind to be deleted.
One obvious risk of this scheme is that we'll leave dangling references
to values without actually inheriting them across generations. To
prevent that, getting a value requires passing in the generation at
which it's being read, and an error will be returned if that generation
is dead.
Change-Id: I4b30891efd7be4e10f2b84f4c067b0dee43dcf9c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/242838
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
2020-07-24 15:17:13 -06:00
|
|
|
snapshot, release := sv.Snapshot(ctx)
|
2020-07-02 16:34:10 -06:00
|
|
|
defer release()
|
|
|
|
s.diagnoseSnapshot(snapshot)
|
2020-07-28 18:05:06 -06:00
|
|
|
default:
|
2020-08-17 20:50:34 -06:00
|
|
|
return fmt.Errorf("unsupported command: %s", command.Name)
|
2019-09-18 23:21:54 -06:00
|
|
|
}
|
2020-08-17 20:50:34 -06:00
|
|
|
return nil
|
2019-09-18 23:21:54 -06:00
|
|
|
}
|
2020-03-10 22:49:10 -06:00
|
|
|
|
2020-06-21 21:21:15 -06:00
|
|
|
func (s *Server) directGoModCommand(ctx context.Context, uri protocol.DocumentURI, verb string, args ...string) error {
|
2020-05-28 19:21:29 -06:00
|
|
|
view, err := s.session.ViewOf(uri.SpanURI())
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
internal/memoize: switch from GC-driven to explicit deletion
The GC-based cache has given us a number of problems. First, memory
leaks driven by reference cycles: the Go runtime cannot collect cycles
involving finalizers, which prevents us from writing natural code in
Bind callbacks. If we screw it up, we get a mysterious leak that takes a
long time to track down. Second, the behavior is generally mysterious;
it's hard to predict how long a value lasts, and harder to tell if a
value being live is a bug. Third, we think that it may be interacting
poorly with the GC, resulting in unnecessary memory usage.
The structure of the values we put in the cache is not actually that
complicated -- there are only 5 significant types: parse, typecheck,
analyze, parse mod, and analyze mod. Managing them manually should not
be conceptually difficult, and in fact we already do most of the work
in (*snapshot).clone.
In this CL the cache adds the concept of "generations", which function
as reference counts on cache entries. Entries are still global and
shared across generations, but will be explicitly deleted once no
generations refer to them. The idea is that each snapshot is a new
generation, and can inherit entries from the previous snapshot or leave
them behind to be deleted.
One obvious risk of this scheme is that we'll leave dangling references
to values without actually inheriting them across generations. To
prevent that, getting a value requires passing in the generation at
which it's being read, and an error will be returned if that generation
is dead.
Change-Id: I4b30891efd7be4e10f2b84f4c067b0dee43dcf9c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/242838
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
2020-07-24 15:17:13 -06:00
|
|
|
snapshot, release := view.Snapshot(ctx)
|
2020-07-02 16:34:10 -06:00
|
|
|
defer release()
|
|
|
|
return snapshot.RunGoCommandDirect(ctx, verb, args)
|
2020-05-28 19:21:29 -06:00
|
|
|
}
|
|
|
|
|
2020-08-17 20:50:34 -06:00
|
|
|
func (s *Server) runTests(ctx context.Context, snapshot source.Snapshot, uri protocol.DocumentURI, work *workDone, tests, benchmarks []string) error {
|
2020-08-17 12:36:26 -06:00
|
|
|
pkgs, err := snapshot.PackagesForFile(ctx, uri.SpanURI(), source.TypecheckWorkspace)
|
2020-07-30 16:48:51 -06:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if len(pkgs) == 0 {
|
|
|
|
return fmt.Errorf("package could not be found for file: %s", uri.SpanURI().Filename())
|
|
|
|
}
|
|
|
|
pkgPath := pkgs[0].PkgPath()
|
|
|
|
|
|
|
|
// create output
|
internal/lsp: improvements for command messages
When falling back to messages for progress reporting, don't try to
implement cancellation via ShowMessageCommand dialogs. They are an
imperfect solution, as the dialog stays open even after the command
completed. Also, among the LSP clients that don't support workDone
reporting, I suspect many also don't support ShowMessageCommand (for
example, govim), so the audience for this feature is probably quite
small.
Just remove it, and instead show a (non-cancellable) message. If clients
want cancellation, workDone progress support is the way to provide it.
Also remove a redundant message on go-generate success, and attach logs
when tests fail. Without logs on failure, I find that the test command
is not very useful. I tested a bit with very verbose test output, and
both VS Code and coc.nvim handled it gracefully.
Finally, fix a bug causing benchmarks not to be run.
Change-Id: I05422bcefc857c25cd99e643e614a0bc33870586
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249702
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-08-21 12:18:37 -06:00
|
|
|
buf := &bytes.Buffer{}
|
2020-06-11 16:25:17 -06:00
|
|
|
ew := &eventWriter{ctx: ctx, operation: "test"}
|
internal/lsp: improvements for command messages
When falling back to messages for progress reporting, don't try to
implement cancellation via ShowMessageCommand dialogs. They are an
imperfect solution, as the dialog stays open even after the command
completed. Also, among the LSP clients that don't support workDone
reporting, I suspect many also don't support ShowMessageCommand (for
example, govim), so the audience for this feature is probably quite
small.
Just remove it, and instead show a (non-cancellable) message. If clients
want cancellation, workDone progress support is the way to provide it.
Also remove a redundant message on go-generate success, and attach logs
when tests fail. Without logs on failure, I find that the test command
is not very useful. I tested a bit with very verbose test output, and
both VS Code and coc.nvim handled it gracefully.
Finally, fix a bug causing benchmarks not to be run.
Change-Id: I05422bcefc857c25cd99e643e614a0bc33870586
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249702
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-08-21 12:18:37 -06:00
|
|
|
out := io.MultiWriter(ew, workDoneWriter{work}, buf)
|
2020-06-12 12:57:48 -06:00
|
|
|
|
2020-08-17 20:50:34 -06:00
|
|
|
// Run `go test -run Func` on each test.
|
2020-07-30 16:48:51 -06:00
|
|
|
var failedTests int
|
|
|
|
for _, funcName := range tests {
|
2020-08-17 20:50:34 -06:00
|
|
|
args := []string{pkgPath, "-v", "-count=1", "-run", fmt.Sprintf("^%s$", funcName)}
|
|
|
|
log.Printf("running with these args: %v", args)
|
|
|
|
if err := snapshot.RunGoCommandPiped(ctx, "test", args, out, out); err != nil {
|
2020-07-30 16:48:51 -06:00
|
|
|
if errors.Is(err, context.Canceled) {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
failedTests++
|
2020-05-05 12:43:51 -06:00
|
|
|
}
|
2020-07-30 16:48:51 -06:00
|
|
|
}
|
|
|
|
|
2020-08-17 20:50:34 -06:00
|
|
|
// Run `go test -run=^$ -bench Func` on each test.
|
2020-07-30 16:48:51 -06:00
|
|
|
var failedBenchmarks int
|
internal/lsp: improvements for command messages
When falling back to messages for progress reporting, don't try to
implement cancellation via ShowMessageCommand dialogs. They are an
imperfect solution, as the dialog stays open even after the command
completed. Also, among the LSP clients that don't support workDone
reporting, I suspect many also don't support ShowMessageCommand (for
example, govim), so the audience for this feature is probably quite
small.
Just remove it, and instead show a (non-cancellable) message. If clients
want cancellation, workDone progress support is the way to provide it.
Also remove a redundant message on go-generate success, and attach logs
when tests fail. Without logs on failure, I find that the test command
is not very useful. I tested a bit with very verbose test output, and
both VS Code and coc.nvim handled it gracefully.
Finally, fix a bug causing benchmarks not to be run.
Change-Id: I05422bcefc857c25cd99e643e614a0bc33870586
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249702
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-08-21 12:18:37 -06:00
|
|
|
for _, funcName := range benchmarks {
|
2020-08-17 20:50:34 -06:00
|
|
|
args := []string{pkgPath, "-v", "-run=^$", "-bench", fmt.Sprintf("^%s$", funcName)}
|
|
|
|
if err := snapshot.RunGoCommandPiped(ctx, "test", args, out, out); err != nil {
|
2020-07-30 16:48:51 -06:00
|
|
|
if errors.Is(err, context.Canceled) {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
failedBenchmarks++
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
internal/lsp: improvements for command messages
When falling back to messages for progress reporting, don't try to
implement cancellation via ShowMessageCommand dialogs. They are an
imperfect solution, as the dialog stays open even after the command
completed. Also, among the LSP clients that don't support workDone
reporting, I suspect many also don't support ShowMessageCommand (for
example, govim), so the audience for this feature is probably quite
small.
Just remove it, and instead show a (non-cancellable) message. If clients
want cancellation, workDone progress support is the way to provide it.
Also remove a redundant message on go-generate success, and attach logs
when tests fail. Without logs on failure, I find that the test command
is not very useful. I tested a bit with very verbose test output, and
both VS Code and coc.nvim handled it gracefully.
Finally, fix a bug causing benchmarks not to be run.
Change-Id: I05422bcefc857c25cd99e643e614a0bc33870586
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249702
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-08-21 12:18:37 -06:00
|
|
|
var title string
|
|
|
|
if len(tests) > 0 && len(benchmarks) > 0 {
|
|
|
|
title = "tests and benchmarks"
|
|
|
|
} else if len(tests) > 0 {
|
|
|
|
title = "tests"
|
|
|
|
} else if len(benchmarks) > 0 {
|
|
|
|
title = "benchmarks"
|
|
|
|
} else {
|
|
|
|
return errors.New("No functions were provided")
|
2020-05-05 12:43:51 -06:00
|
|
|
}
|
internal/lsp: improvements for command messages
When falling back to messages for progress reporting, don't try to
implement cancellation via ShowMessageCommand dialogs. They are an
imperfect solution, as the dialog stays open even after the command
completed. Also, among the LSP clients that don't support workDone
reporting, I suspect many also don't support ShowMessageCommand (for
example, govim), so the audience for this feature is probably quite
small.
Just remove it, and instead show a (non-cancellable) message. If clients
want cancellation, workDone progress support is the way to provide it.
Also remove a redundant message on go-generate success, and attach logs
when tests fail. Without logs on failure, I find that the test command
is not very useful. I tested a bit with very verbose test output, and
both VS Code and coc.nvim handled it gracefully.
Finally, fix a bug causing benchmarks not to be run.
Change-Id: I05422bcefc857c25cd99e643e614a0bc33870586
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249702
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-08-21 12:18:37 -06:00
|
|
|
message := fmt.Sprintf("all %s passed", title)
|
2020-07-30 16:48:51 -06:00
|
|
|
if failedTests > 0 && failedBenchmarks > 0 {
|
|
|
|
message = fmt.Sprintf("%d / %d tests failed and %d / %d benchmarks failed", failedTests, len(tests), failedBenchmarks, len(benchmarks))
|
|
|
|
} else if failedTests > 0 {
|
|
|
|
message = fmt.Sprintf("%d / %d tests failed", failedTests, len(tests))
|
|
|
|
} else if failedBenchmarks > 0 {
|
|
|
|
message = fmt.Sprintf("%d / %d benchmarks failed", failedBenchmarks, len(benchmarks))
|
|
|
|
}
|
internal/lsp: improvements for command messages
When falling back to messages for progress reporting, don't try to
implement cancellation via ShowMessageCommand dialogs. They are an
imperfect solution, as the dialog stays open even after the command
completed. Also, among the LSP clients that don't support workDone
reporting, I suspect many also don't support ShowMessageCommand (for
example, govim), so the audience for this feature is probably quite
small.
Just remove it, and instead show a (non-cancellable) message. If clients
want cancellation, workDone progress support is the way to provide it.
Also remove a redundant message on go-generate success, and attach logs
when tests fail. Without logs on failure, I find that the test command
is not very useful. I tested a bit with very verbose test output, and
both VS Code and coc.nvim handled it gracefully.
Finally, fix a bug causing benchmarks not to be run.
Change-Id: I05422bcefc857c25cd99e643e614a0bc33870586
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249702
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-08-21 12:18:37 -06:00
|
|
|
messageType := protocol.Info
|
|
|
|
if failedTests > 0 || failedBenchmarks > 0 {
|
|
|
|
messageType = protocol.Error
|
|
|
|
message += "\n" + buf.String()
|
|
|
|
}
|
2020-07-30 16:48:51 -06:00
|
|
|
|
2020-06-12 12:57:48 -06:00
|
|
|
return s.client.ShowMessage(ctx, &protocol.ShowMessageParams{
|
2020-05-05 12:43:51 -06:00
|
|
|
Type: messageType,
|
|
|
|
Message: message,
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2020-08-17 20:50:34 -06:00
|
|
|
func (s *Server) runGoGenerate(ctx context.Context, snapshot source.Snapshot, uri span.URI, recursive bool, work *workDone) error {
|
2020-07-15 21:33:55 -06:00
|
|
|
ctx, cancel := context.WithCancel(ctx)
|
|
|
|
defer cancel()
|
|
|
|
|
|
|
|
er := &eventWriter{ctx: ctx, operation: "generate"}
|
|
|
|
args := []string{"-x"}
|
|
|
|
if recursive {
|
|
|
|
args = append(args, "./...")
|
|
|
|
}
|
|
|
|
|
2020-08-17 20:50:34 -06:00
|
|
|
stderr := io.MultiWriter(er, workDoneWriter{work})
|
2020-07-02 16:34:10 -06:00
|
|
|
|
2020-07-15 21:33:55 -06:00
|
|
|
if err := snapshot.RunGoCommandPiped(ctx, "generate", args, er, stderr); err != nil {
|
2020-08-17 20:50:34 -06:00
|
|
|
return err
|
2020-07-15 21:33:55 -06:00
|
|
|
}
|
internal/lsp: improvements for command messages
When falling back to messages for progress reporting, don't try to
implement cancellation via ShowMessageCommand dialogs. They are an
imperfect solution, as the dialog stays open even after the command
completed. Also, among the LSP clients that don't support workDone
reporting, I suspect many also don't support ShowMessageCommand (for
example, govim), so the audience for this feature is probably quite
small.
Just remove it, and instead show a (non-cancellable) message. If clients
want cancellation, workDone progress support is the way to provide it.
Also remove a redundant message on go-generate success, and attach logs
when tests fail. Without logs on failure, I find that the test command
is not very useful. I tested a bit with very verbose test output, and
both VS Code and coc.nvim handled it gracefully.
Finally, fix a bug causing benchmarks not to be run.
Change-Id: I05422bcefc857c25cd99e643e614a0bc33870586
Reviewed-on: https://go-review.googlesource.com/c/tools/+/249702
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
2020-08-21 12:18:37 -06:00
|
|
|
return nil
|
2020-07-15 21:33:55 -06:00
|
|
|
}
|