1
0
mirror of https://github.com/golang/go synced 2024-11-05 20:36:10 -07:00
go/internal/lsp/cache/parse.go

1155 lines
28 KiB
Go
Raw Normal View History

// Copyright 2019 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.
package cache
import (
"bytes"
"context"
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
"fmt"
"go/ast"
"go/parser"
"go/scanner"
"go/token"
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
"reflect"
"strconv"
"golang.org/x/tools/internal/event"
"golang.org/x/tools/internal/lsp/debug/tag"
"golang.org/x/tools/internal/lsp/protocol"
"golang.org/x/tools/internal/lsp/source"
"golang.org/x/tools/internal/memoize"
"golang.org/x/tools/internal/span"
errors "golang.org/x/xerrors"
)
// parseKey uniquely identifies a parsed Go file.
type parseKey struct {
file source.FileIdentity
mode source.ParseMode
}
// astCacheKey is similar to parseKey, but is a distinct type because
// it is used to key a different value within the same map.
type astCacheKey parseKey
type parseGoHandle struct {
handle *memoize.Handle
file source.FileHandle
mode source.ParseMode
astCacheHandle *memoize.Handle
}
type parseGoData struct {
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
parsed *source.ParsedGoFile
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
// If true, we adjusted the AST to make it type check better, and
// it may not match the source code.
fixed bool
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
err error // any other errors
}
func (s *snapshot) parseGoHandle(ctx context.Context, fh source.FileHandle, mode source.ParseMode) *parseGoHandle {
key := parseKey{
file: fh.FileIdentity(),
mode: mode,
}
if pgh := s.getGoFile(key); pgh != nil {
return pgh
}
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
parseHandle := s.generation.Bind(key, func(ctx context.Context, arg memoize.Arg) interface{} {
snapshot := arg.(*snapshot)
return parseGo(ctx, snapshot.view.session.cache.fset, fh, mode)
})
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
astHandle := s.generation.Bind(astCacheKey(key), func(ctx context.Context, arg memoize.Arg) interface{} {
snapshot := arg.(*snapshot)
return buildASTCache(ctx, snapshot, parseHandle)
})
pgh := &parseGoHandle{
handle: parseHandle,
file: fh,
mode: mode,
astCacheHandle: astHandle,
}
return s.addGoFile(key, pgh)
}
func (pgh *parseGoHandle) String() string {
return pgh.File().URI().Filename()
}
func (pgh *parseGoHandle) File() source.FileHandle {
return pgh.file
}
func (pgh *parseGoHandle) Mode() source.ParseMode {
return pgh.mode
}
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
func (s *snapshot) ParseGo(ctx context.Context, fh source.FileHandle, mode source.ParseMode) (*source.ParsedGoFile, error) {
pgh := s.parseGoHandle(ctx, fh, mode)
pgf, _, err := s.parseGo(ctx, pgh)
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
return pgf, err
}
func (s *snapshot) parseGo(ctx context.Context, pgh *parseGoHandle) (*source.ParsedGoFile, bool, error) {
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
d, err := pgh.handle.Get(ctx, s.generation, s)
if err != nil {
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
return nil, false, err
}
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
data := d.(*parseGoData)
return data.parsed, data.fixed, data.err
}
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
func (s *snapshot) PosToDecl(ctx context.Context, pgf *source.ParsedGoFile) (map[token.Pos]ast.Decl, error) {
fh, err := s.GetFile(ctx, pgf.URI)
if err != nil {
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
return nil, err
}
pgh := s.parseGoHandle(ctx, fh, pgf.Mode)
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
d, err := pgh.astCacheHandle.Get(ctx, s.generation, s)
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
if err != nil {
return nil, err
}
data := d.(*astCacheData)
return data.posToDecl, data.err
}
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
func (s *snapshot) PosToField(ctx context.Context, pgf *source.ParsedGoFile) (map[token.Pos]*ast.Field, error) {
fh, err := s.GetFile(ctx, pgf.URI)
if err != nil {
return nil, err
}
pgh := s.parseGoHandle(ctx, fh, pgf.Mode)
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
d, err := pgh.astCacheHandle.Get(ctx, s.generation, s)
if err != nil || d == nil {
return nil, err
}
data := d.(*astCacheData)
return data.posToField, data.err
}
type astCacheData struct {
err error
posToDecl map[token.Pos]ast.Decl
posToField map[token.Pos]*ast.Field
}
// buildASTCache builds caches to aid in quickly going from the typed
// world to the syntactic world.
func buildASTCache(ctx context.Context, snapshot *snapshot, parseHandle *memoize.Handle) *astCacheData {
var (
// path contains all ancestors, including n.
path []ast.Node
// decls contains all ancestors that are decls.
decls []ast.Decl
)
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
v, err := parseHandle.Get(ctx, snapshot.generation, snapshot)
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
if err != nil {
return &astCacheData{err: err}
}
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
file := v.(*parseGoData).parsed.File
if err != nil {
return &astCacheData{err: fmt.Errorf("nil file")}
}
data := &astCacheData{
posToDecl: make(map[token.Pos]ast.Decl),
posToField: make(map[token.Pos]*ast.Field),
}
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
ast.Inspect(file, func(n ast.Node) bool {
if n == nil {
lastP := path[len(path)-1]
path = path[:len(path)-1]
if len(decls) > 0 && decls[len(decls)-1] == lastP {
decls = decls[:len(decls)-1]
}
return false
}
path = append(path, n)
switch n := n.(type) {
case *ast.Field:
addField := func(f ast.Node) {
if f.Pos().IsValid() {
data.posToField[f.Pos()] = n
if len(decls) > 0 {
data.posToDecl[f.Pos()] = decls[len(decls)-1]
}
}
}
// Add mapping for *ast.Field itself. This handles embedded
// fields which have no associated *ast.Ident name.
addField(n)
// Add mapping for each field name since you can have
// multiple names for the same type expression.
for _, name := range n.Names {
addField(name)
}
// Also map "X" in "...X" to the containing *ast.Field. This
// makes it easy to format variadic signature params
// properly.
if elips, ok := n.Type.(*ast.Ellipsis); ok && elips.Elt != nil {
addField(elips.Elt)
}
case *ast.FuncDecl:
decls = append(decls, n)
if n.Name != nil && n.Name.Pos().IsValid() {
data.posToDecl[n.Name.Pos()] = n
}
case *ast.GenDecl:
decls = append(decls, n)
for _, spec := range n.Specs {
switch spec := spec.(type) {
case *ast.TypeSpec:
if spec.Name != nil && spec.Name.Pos().IsValid() {
data.posToDecl[spec.Name.Pos()] = n
}
case *ast.ValueSpec:
for _, id := range spec.Names {
if id != nil && id.Pos().IsValid() {
data.posToDecl[id.Pos()] = n
}
}
}
}
}
return true
})
return data
}
func parseGo(ctx context.Context, fset *token.FileSet, fh source.FileHandle, mode source.ParseMode) *parseGoData {
ctx, done := event.Start(ctx, "cache.parseGo", tag.File.Of(fh.URI().Filename()))
defer done()
if fh.Kind() != source.Go {
return &parseGoData{err: errors.Errorf("cannot parse non-Go file %s", fh.URI())}
}
buf, err := fh.Read()
if err != nil {
return &parseGoData{err: err}
}
parserMode := parser.AllErrors | parser.ParseComments
if mode == source.ParseHeader {
parserMode = parser.ImportsOnly | parser.ParseComments
}
file, parseError := parser.ParseFile(fset, fh.URI().Filename(), buf, parserMode)
var tok *token.File
var fixed bool
if file != nil {
tok = fset.File(file.Pos())
if tok == nil {
tok = fset.AddFile(fh.URI().Filename(), -1, len(buf))
tok.SetLinesForContent(buf)
return &parseGoData{
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
parsed: &source.ParsedGoFile{
URI: fh.URI(),
Mode: mode,
Src: buf,
File: file,
Tok: tok,
Mapper: &protocol.ColumnMapper{
URI: fh.URI(),
Content: buf,
Converter: span.NewTokenConverter(fset, tok),
},
ParseErr: parseError,
},
}
}
// Fix any badly parsed parts of the AST.
fixed = fixAST(ctx, file, tok, buf)
// Fix certain syntax errors that render the file unparseable.
newSrc := fixSrc(file, tok, buf)
if newSrc != nil {
newFile, _ := parser.ParseFile(fset, fh.URI().Filename(), newSrc, parserMode)
if newFile != nil {
// Maintain the original parseError so we don't try formatting the doctored file.
file = newFile
buf = newSrc
tok = fset.File(file.Pos())
fixed = fixAST(ctx, file, tok, buf)
}
}
if mode == source.ParseExported {
trimAST(file)
}
}
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
// A missing file is always an error; use the parse error or make one up if there isn't one.
if file == nil {
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
if parseError == nil {
parseError = errors.Errorf("parsing %s failed with no parse error reported", fh.URI())
}
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
err = parseError
}
m := &protocol.ColumnMapper{
URI: fh.URI(),
Converter: span.NewTokenConverter(fset, tok),
Content: buf,
}
return &parseGoData{
internal/lsp: replace ParseGoHandle with concrete data ParseGoHandles serve two purposes: they pin cache entries so that redundant calculations are cached, and they allow users to obtain the actual parsed AST. The former is an implementation detail, and the latter turns out to just be an annoyance. Parsed Go files are obtained from two places. By far the most common is from a type checked package. But a type checked package must by definition have already parsed all the files it contains, so the PGH is already computed and cannot have failed. Type checked packages can simply return the parsed file without requiring a separate Check operation. We do want to pin the cache entries in this case, which I've done by holding on to the PGH in cache.pkg. There are some cases where we directly parse a file, such as for the FoldingRange LSP call, which doesn't need type information. Those parses can actually fail, so we do need an error check. But we don't need the PGH; in all cases we are immediately using and discarding it. So it turns out we don't actually need the PGH type at all, at least not in the public API. Instead, we can pass around a concrete struct that has the various pieces of data directly available. This uncovered a bug in typeCheck: it should fail if it encounters any real errors. Change-Id: I203bf2dd79d5d65c01392d69c2cf4f7744fde7fc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244021 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-07-21 13:15:06 -06:00
parsed: &source.ParsedGoFile{
URI: fh.URI(),
Mode: mode,
Src: buf,
File: file,
Tok: tok,
Mapper: m,
ParseErr: parseError,
},
fixed: fixed,
err: err,
}
}
// trimAST clears any part of the AST not relevant to type checking
// expressions at pos.
func trimAST(file *ast.File) {
ast.Inspect(file, func(n ast.Node) bool {
if n == nil {
return false
}
switch n := n.(type) {
case *ast.FuncDecl:
n.Body = nil
case *ast.BlockStmt:
n.List = nil
case *ast.CaseClause:
n.Body = nil
case *ast.CommClause:
n.Body = nil
case *ast.CompositeLit:
// types.Info.Types for long slice/array literals are particularly
// expensive. Try to clear them out.
at, ok := n.Type.(*ast.ArrayType)
if !ok {
break
}
// Removing the elements from an ellipsis array changes its type.
// Try to set the length explicitly so we can continue.
if _, ok := at.Len.(*ast.Ellipsis); ok {
length, ok := arrayLength(n)
if !ok {
break
}
at.Len = &ast.BasicLit{
Kind: token.INT,
Value: fmt.Sprint(length),
ValuePos: at.Len.Pos(),
}
}
n.Elts = nil
}
return true
})
}
// arrayLength returns the length of some simple forms of ellipsis array literal.
// Notably, it handles the tables in golang.org/x/text.
func arrayLength(array *ast.CompositeLit) (int, bool) {
litVal := func(expr ast.Expr) (int, bool) {
lit, ok := expr.(*ast.BasicLit)
if !ok {
return 0, false
}
val, err := strconv.ParseInt(lit.Value, 10, 64)
if err != nil {
return 0, false
}
return int(val), true
}
largestKey := -1
for _, elt := range array.Elts {
kve, ok := elt.(*ast.KeyValueExpr)
if !ok {
continue
}
switch key := kve.Key.(type) {
case *ast.BasicLit:
if val, ok := litVal(key); ok && largestKey < val {
largestKey = val
}
case *ast.BinaryExpr:
// golang.org/x/text uses subtraction (and only subtraction) in its indices.
if key.Op != token.SUB {
break
}
x, ok := litVal(key.X)
if !ok {
break
}
y, ok := litVal(key.Y)
if !ok {
break
}
if val := x - y; largestKey < val {
largestKey = val
}
}
}
if largestKey != -1 {
return largestKey + 1, true
}
return len(array.Elts), true
}
// fixAST inspects the AST and potentially modifies any *ast.BadStmts so that it can be
// type-checked more effectively.
func fixAST(ctx context.Context, n ast.Node, tok *token.File, src []byte) (fixed bool) {
var err error
walkASTWithParent(n, func(n, parent ast.Node) bool {
switch n := n.(type) {
case *ast.BadStmt:
if fixed = fixDeferOrGoStmt(n, parent, tok, src); fixed {
// Recursively fix in our fixed node.
_ = fixAST(ctx, parent, tok, src)
} else {
err = errors.Errorf("unable to parse defer or go from *ast.BadStmt: %v", err)
}
return false
case *ast.BadExpr:
if fixed = fixArrayType(n, parent, tok, src); fixed {
// Recursively fix in our fixed node.
_ = fixAST(ctx, parent, tok, src)
internal/lsp: improve completion after accidental keywords Sometimes the prefix of the thing you want to complete is a keyword. For example: variance := 123 fmt.Println(var<>) In this case the parser produces an *ast.BadExpr which breaks completion. We now repair this BadExpr by replacing it with an *ast.Ident named "var". We also repair empty decls using a similar approach. This fixes cases like: var typeName string type<> // want to complete to "typeName" We also fix accidental keywords in selectors, such as: foo.var<> The parser produces a phantom "_" in place of the keyword, so we swap it back for an *ast.Ident named "var". In general, though, accidental keywords wreak havoc on the AST so we can only do so much. There are still many cases where a keyword prefix breaks completion. Perhaps in the future the parser can be cursor/in-progress-edit aware and turn accidental keywords into identifiers. Fixes golang/go#34332. PS I tweaked nodeContains() to include n.End() to fix a test failure against tip related to a change to go/parser. When a syntax error is present, an *ast.BlockStmt's End() is now set to the block's final statement's End() (earlier than what it used to be). In order for the cursor pos to test "inside" the block in this case I had to relax the End() comparison. Change-Id: Ib45952cf086cc974f1578298df3dd12829344faa Reviewed-on: https://go-review.googlesource.com/c/tools/+/209438 Run-TryBot: Muir Manders <muir@mnd.rs> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-11-20 12:15:53 -07:00
return false
}
// Fix cases where parser interprets if/for/switch "init"
// statement as "cond" expression, e.g.:
//
// // "i := foo" is init statement, not condition.
// for i := foo
//
fixInitStmt(n, parent, tok, src)
return false
internal/lsp: improve completion after accidental keywords Sometimes the prefix of the thing you want to complete is a keyword. For example: variance := 123 fmt.Println(var<>) In this case the parser produces an *ast.BadExpr which breaks completion. We now repair this BadExpr by replacing it with an *ast.Ident named "var". We also repair empty decls using a similar approach. This fixes cases like: var typeName string type<> // want to complete to "typeName" We also fix accidental keywords in selectors, such as: foo.var<> The parser produces a phantom "_" in place of the keyword, so we swap it back for an *ast.Ident named "var". In general, though, accidental keywords wreak havoc on the AST so we can only do so much. There are still many cases where a keyword prefix breaks completion. Perhaps in the future the parser can be cursor/in-progress-edit aware and turn accidental keywords into identifiers. Fixes golang/go#34332. PS I tweaked nodeContains() to include n.End() to fix a test failure against tip related to a change to go/parser. When a syntax error is present, an *ast.BlockStmt's End() is now set to the block's final statement's End() (earlier than what it used to be). In order for the cursor pos to test "inside" the block in this case I had to relax the End() comparison. Change-Id: Ib45952cf086cc974f1578298df3dd12829344faa Reviewed-on: https://go-review.googlesource.com/c/tools/+/209438 Run-TryBot: Muir Manders <muir@mnd.rs> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-11-20 12:15:53 -07:00
case *ast.SelectorExpr:
// Fix cases where a keyword prefix results in a phantom "_" selector, e.g.:
//
// foo.var<> // want to complete to "foo.variance"
//
fixPhantomSelector(n, tok, src)
return true
case *ast.BlockStmt:
switch parent.(type) {
case *ast.SwitchStmt, *ast.TypeSwitchStmt, *ast.SelectStmt:
// Adjust closing curly brace of empty switch/select
// statements so we can complete inside them.
fixEmptySwitch(n, tok, src)
}
return true
default:
return true
}
})
return fixed
}
// walkASTWithParent walks the AST rooted at n. The semantics are
// similar to ast.Inspect except it does not call f(nil).
func walkASTWithParent(n ast.Node, f func(n ast.Node, parent ast.Node) bool) {
var ancestors []ast.Node
ast.Inspect(n, func(n ast.Node) (recurse bool) {
defer func() {
if recurse {
ancestors = append(ancestors, n)
}
}()
if n == nil {
ancestors = ancestors[:len(ancestors)-1]
return false
}
var parent ast.Node
if len(ancestors) > 0 {
parent = ancestors[len(ancestors)-1]
}
return f(n, parent)
})
}
// fixSrc attempts to modify the file's source code to fix certain
// syntax errors that leave the rest of the file unparsed.
func fixSrc(f *ast.File, tok *token.File, src []byte) (newSrc []byte) {
walkASTWithParent(f, func(n, parent ast.Node) bool {
if newSrc != nil {
return false
}
switch n := n.(type) {
case *ast.BlockStmt:
newSrc = fixMissingCurlies(f, n, parent, tok, src)
case *ast.SelectorExpr:
newSrc = fixDanglingSelector(n, tok, src)
}
return newSrc == nil
})
return newSrc
}
// fixMissingCurlies adds in curly braces for block statements that
// are missing curly braces. For example:
//
// if foo
//
// becomes
//
// if foo {}
func fixMissingCurlies(f *ast.File, b *ast.BlockStmt, parent ast.Node, tok *token.File, src []byte) []byte {
// If the "{" is already in the source code, there isn't anything to
// fix since we aren't missing curlies.
if b.Lbrace.IsValid() {
braceOffset := tok.Offset(b.Lbrace)
if braceOffset < len(src) && src[braceOffset] == '{' {
return nil
}
}
parentLine := tok.Line(parent.Pos())
if parentLine >= tok.LineCount() {
// If we are the last line in the file, no need to fix anything.
return nil
}
// Insert curlies at the end of parent's starting line. The parent
// is the statement that contains the block, e.g. *ast.IfStmt. The
// block's Pos()/End() can't be relied upon because they are based
// on the (missing) curly braces. We assume the statement is a
// single line for now and try sticking the curly braces at the end.
insertPos := tok.LineStart(parentLine+1) - 1
// Scootch position backwards until it's not in a comment. For example:
//
// if foo<> // some amazing comment |
// someOtherCode()
//
// insertPos will be located at "|", so we back it out of the comment.
didSomething := true
for didSomething {
didSomething = false
for _, c := range f.Comments {
if c.Pos() < insertPos && insertPos <= c.End() {
insertPos = c.Pos()
didSomething = true
}
}
}
// Bail out if line doesn't end in an ident or ".". This is to avoid
// cases like below where we end up making things worse by adding
// curlies:
//
// if foo &&
// bar<>
switch precedingToken(insertPos, tok, src) {
case token.IDENT, token.PERIOD:
// ok
default:
return nil
}
var buf bytes.Buffer
buf.Grow(len(src) + 3)
buf.Write(src[:tok.Offset(insertPos)])
// Detect if we need to insert a semicolon to fix "for" loop situations like:
//
// for i := foo(); foo<>
//
// Just adding curlies is not sufficient to make things parse well.
if fs, ok := parent.(*ast.ForStmt); ok {
if _, ok := fs.Cond.(*ast.BadExpr); !ok {
if xs, ok := fs.Post.(*ast.ExprStmt); ok {
if _, ok := xs.X.(*ast.BadExpr); ok {
buf.WriteByte(';')
}
}
}
}
// Insert "{}" at insertPos.
buf.WriteByte('{')
buf.WriteByte('}')
buf.Write(src[tok.Offset(insertPos):])
return buf.Bytes()
}
// fixEmptySwitch moves empty switch/select statements' closing curly
// brace down one line. This allows us to properly detect incomplete
// "case" and "default" keywords as inside the switch statement. For
// example:
//
// switch {
// def<>
// }
//
// gets parsed like:
//
// switch {
// }
//
// Later we manually pull out the "def" token, but we need to detect
// that our "<>" position is inside the switch block. To do that we
// move the curly brace so it looks like:
//
// switch {
//
// }
//
func fixEmptySwitch(body *ast.BlockStmt, tok *token.File, src []byte) {
// We only care about empty switch statements.
if len(body.List) > 0 || !body.Rbrace.IsValid() {
return
}
// If the right brace is actually in the source code at the
// specified position, don't mess with it.
braceOffset := tok.Offset(body.Rbrace)
if braceOffset < len(src) && src[braceOffset] == '}' {
return
}
braceLine := tok.Line(body.Rbrace)
if braceLine >= tok.LineCount() {
// If we are the last line in the file, no need to fix anything.
return
}
// Move the right brace down one line.
body.Rbrace = tok.LineStart(braceLine + 1)
}
// fixDanglingSelector inserts real "_" selector expressions in place
// of phantom "_" selectors. For example:
//
// func _() {
// x.<>
// }
// var x struct { i int }
//
// To fix completion at "<>", we insert a real "_" after the "." so the
// following declaration of "x" can be parsed and type checked
// normally.
func fixDanglingSelector(s *ast.SelectorExpr, tok *token.File, src []byte) []byte {
if !isPhantomUnderscore(s.Sel, tok, src) {
return nil
}
if !s.X.End().IsValid() {
return nil
}
// Insert directly after the selector's ".".
insertOffset := tok.Offset(s.X.End()) + 1
if src[insertOffset-1] != '.' {
return nil
}
var buf bytes.Buffer
buf.Grow(len(src) + 1)
buf.Write(src[:insertOffset])
buf.WriteByte('_')
buf.Write(src[insertOffset:])
return buf.Bytes()
}
internal/lsp: improve completion after accidental keywords Sometimes the prefix of the thing you want to complete is a keyword. For example: variance := 123 fmt.Println(var<>) In this case the parser produces an *ast.BadExpr which breaks completion. We now repair this BadExpr by replacing it with an *ast.Ident named "var". We also repair empty decls using a similar approach. This fixes cases like: var typeName string type<> // want to complete to "typeName" We also fix accidental keywords in selectors, such as: foo.var<> The parser produces a phantom "_" in place of the keyword, so we swap it back for an *ast.Ident named "var". In general, though, accidental keywords wreak havoc on the AST so we can only do so much. There are still many cases where a keyword prefix breaks completion. Perhaps in the future the parser can be cursor/in-progress-edit aware and turn accidental keywords into identifiers. Fixes golang/go#34332. PS I tweaked nodeContains() to include n.End() to fix a test failure against tip related to a change to go/parser. When a syntax error is present, an *ast.BlockStmt's End() is now set to the block's final statement's End() (earlier than what it used to be). In order for the cursor pos to test "inside" the block in this case I had to relax the End() comparison. Change-Id: Ib45952cf086cc974f1578298df3dd12829344faa Reviewed-on: https://go-review.googlesource.com/c/tools/+/209438 Run-TryBot: Muir Manders <muir@mnd.rs> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-11-20 12:15:53 -07:00
// fixPhantomSelector tries to fix selector expressions with phantom
// "_" selectors. In particular, we check if the selector is a
// keyword, and if so we swap in an *ast.Ident with the keyword text. For example:
//
// foo.var
//
// yields a "_" selector instead of "var" since "var" is a keyword.
func fixPhantomSelector(sel *ast.SelectorExpr, tok *token.File, src []byte) {
if !isPhantomUnderscore(sel.Sel, tok, src) {
return
}
// Only consider selectors directly abutting the selector ".". This
// avoids false positives in cases like:
//
// foo. // don't think "var" is our selector
// var bar = 123
//
if sel.Sel.Pos() != sel.X.End()+1 {
return
}
internal/lsp: improve completion after accidental keywords Sometimes the prefix of the thing you want to complete is a keyword. For example: variance := 123 fmt.Println(var<>) In this case the parser produces an *ast.BadExpr which breaks completion. We now repair this BadExpr by replacing it with an *ast.Ident named "var". We also repair empty decls using a similar approach. This fixes cases like: var typeName string type<> // want to complete to "typeName" We also fix accidental keywords in selectors, such as: foo.var<> The parser produces a phantom "_" in place of the keyword, so we swap it back for an *ast.Ident named "var". In general, though, accidental keywords wreak havoc on the AST so we can only do so much. There are still many cases where a keyword prefix breaks completion. Perhaps in the future the parser can be cursor/in-progress-edit aware and turn accidental keywords into identifiers. Fixes golang/go#34332. PS I tweaked nodeContains() to include n.End() to fix a test failure against tip related to a change to go/parser. When a syntax error is present, an *ast.BlockStmt's End() is now set to the block's final statement's End() (earlier than what it used to be). In order for the cursor pos to test "inside" the block in this case I had to relax the End() comparison. Change-Id: Ib45952cf086cc974f1578298df3dd12829344faa Reviewed-on: https://go-review.googlesource.com/c/tools/+/209438 Run-TryBot: Muir Manders <muir@mnd.rs> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-11-20 12:15:53 -07:00
maybeKeyword := readKeyword(sel.Sel.Pos(), tok, src)
if maybeKeyword == "" {
return
}
replaceNode(sel, sel.Sel, &ast.Ident{
Name: maybeKeyword,
NamePos: sel.Sel.Pos(),
})
}
// isPhantomUnderscore reports whether the given ident is a phantom
// underscore. The parser sometimes inserts phantom underscores when
// it encounters otherwise unparseable situations.
func isPhantomUnderscore(id *ast.Ident, tok *token.File, src []byte) bool {
if id == nil || id.Name != "_" {
return false
}
// Phantom underscore means the underscore is not actually in the
// program text.
offset := tok.Offset(id.Pos())
return len(src) <= offset || src[offset] != '_'
}
// fixInitStmt fixes cases where the parser misinterprets an
// if/for/switch "init" statement as the "cond" conditional. In cases
// like "if i := 0" the user hasn't typed the semicolon yet so the
// parser is looking for the conditional expression. However, "i := 0"
// are not valid expressions, so we get a BadExpr.
func fixInitStmt(bad *ast.BadExpr, parent ast.Node, tok *token.File, src []byte) {
if !bad.Pos().IsValid() || !bad.End().IsValid() {
return
}
// Try to extract a statement from the BadExpr.
stmtBytes := src[tok.Offset(bad.Pos()) : tok.Offset(bad.End()-1)+1]
stmt, err := parseStmt(bad.Pos(), stmtBytes)
if err != nil {
return
}
// If the parent statement doesn't already have an "init" statement,
// move the extracted statement into the "init" field and insert a
// dummy expression into the required "cond" field.
switch p := parent.(type) {
case *ast.IfStmt:
if p.Init != nil {
return
}
p.Init = stmt
p.Cond = &ast.Ident{
Name: "_",
NamePos: stmt.End(),
}
case *ast.ForStmt:
if p.Init != nil {
return
}
p.Init = stmt
p.Cond = &ast.Ident{
Name: "_",
NamePos: stmt.End(),
}
case *ast.SwitchStmt:
if p.Init != nil {
return
}
p.Init = stmt
p.Tag = nil
}
}
internal/lsp: improve completion after accidental keywords Sometimes the prefix of the thing you want to complete is a keyword. For example: variance := 123 fmt.Println(var<>) In this case the parser produces an *ast.BadExpr which breaks completion. We now repair this BadExpr by replacing it with an *ast.Ident named "var". We also repair empty decls using a similar approach. This fixes cases like: var typeName string type<> // want to complete to "typeName" We also fix accidental keywords in selectors, such as: foo.var<> The parser produces a phantom "_" in place of the keyword, so we swap it back for an *ast.Ident named "var". In general, though, accidental keywords wreak havoc on the AST so we can only do so much. There are still many cases where a keyword prefix breaks completion. Perhaps in the future the parser can be cursor/in-progress-edit aware and turn accidental keywords into identifiers. Fixes golang/go#34332. PS I tweaked nodeContains() to include n.End() to fix a test failure against tip related to a change to go/parser. When a syntax error is present, an *ast.BlockStmt's End() is now set to the block's final statement's End() (earlier than what it used to be). In order for the cursor pos to test "inside" the block in this case I had to relax the End() comparison. Change-Id: Ib45952cf086cc974f1578298df3dd12829344faa Reviewed-on: https://go-review.googlesource.com/c/tools/+/209438 Run-TryBot: Muir Manders <muir@mnd.rs> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-11-20 12:15:53 -07:00
// readKeyword reads the keyword starting at pos, if any.
func readKeyword(pos token.Pos, tok *token.File, src []byte) string {
var kwBytes []byte
for i := tok.Offset(pos); i < len(src); i++ {
// Use a simplified identifier check since keywords are always lowercase ASCII.
if src[i] < 'a' || src[i] > 'z' {
break
}
kwBytes = append(kwBytes, src[i])
// Stop search at arbitrarily chosen too-long-for-a-keyword length.
if len(kwBytes) > 15 {
return ""
}
}
if kw := string(kwBytes); token.Lookup(kw).IsKeyword() {
return kw
}
return ""
}
// fixArrayType tries to parse an *ast.BadExpr into an *ast.ArrayType.
// go/parser often turns lone array types like "[]int" into BadExprs
// if it isn't expecting a type.
func fixArrayType(bad *ast.BadExpr, parent ast.Node, tok *token.File, src []byte) bool {
// Our expected input is a bad expression that looks like "[]someExpr".
from := bad.Pos()
to := bad.End()
if !from.IsValid() || !to.IsValid() {
return false
}
exprBytes := make([]byte, 0, int(to-from)+3)
// Avoid doing tok.Offset(to) since that panics if badExpr ends at EOF.
exprBytes = append(exprBytes, src[tok.Offset(from):tok.Offset(to-1)+1]...)
exprBytes = bytes.TrimSpace(exprBytes)
// If our expression ends in "]" (e.g. "[]"), add a phantom selector
// so we can complete directly after the "[]".
if len(exprBytes) > 0 && exprBytes[len(exprBytes)-1] == ']' {
exprBytes = append(exprBytes, '_')
}
// Add "{}" to turn our ArrayType into a CompositeLit. This is to
// handle the case of "[...]int" where we must make it a composite
// literal to be parseable.
exprBytes = append(exprBytes, '{', '}')
expr, err := parseExpr(from, exprBytes)
if err != nil {
return false
}
cl, _ := expr.(*ast.CompositeLit)
if cl == nil {
return false
}
at, _ := cl.Type.(*ast.ArrayType)
if at == nil {
return false
}
return replaceNode(parent, bad, at)
}
// precedingToken scans src to find the token preceding pos.
func precedingToken(pos token.Pos, tok *token.File, src []byte) token.Token {
s := &scanner.Scanner{}
s.Init(tok, src, nil, 0)
var lastTok token.Token
for {
p, t, _ := s.Scan()
if t == token.EOF || p >= pos {
break
}
lastTok = t
}
return lastTok
}
// fixDeferOrGoStmt tries to parse an *ast.BadStmt into a defer or a go statement.
//
// go/parser packages a statement of the form "defer x." as an *ast.BadStmt because
// it does not include a call expression. This means that go/types skips type-checking
// this statement entirely, and we can't use the type information when completing.
// Here, we try to generate a fake *ast.DeferStmt or *ast.GoStmt to put into the AST,
// instead of the *ast.BadStmt.
func fixDeferOrGoStmt(bad *ast.BadStmt, parent ast.Node, tok *token.File, src []byte) bool {
// Check if we have a bad statement containing either a "go" or "defer".
s := &scanner.Scanner{}
s.Init(tok, src, nil, 0)
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
var (
pos token.Pos
tkn token.Token
)
for {
if tkn == token.EOF {
return false
}
if pos >= bad.From {
break
}
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
pos, tkn, _ = s.Scan()
}
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
var stmt ast.Stmt
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
switch tkn {
case token.DEFER:
stmt = &ast.DeferStmt{
Defer: pos,
}
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
case token.GO:
stmt = &ast.GoStmt{
Go: pos,
}
default:
return false
}
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
var (
from, to, last token.Pos
lastToken token.Token
braceDepth int
phantomSelectors []token.Pos
)
FindTo:
for {
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
to, tkn, _ = s.Scan()
if from == token.NoPos {
from = to
}
switch tkn {
case token.EOF:
break FindTo
case token.SEMICOLON:
// If we aren't in nested braces, end of statement means
// end of expression.
if braceDepth == 0 {
break FindTo
}
case token.LBRACE:
braceDepth++
}
// This handles the common dangling selector case. For example in
//
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
// defer fmt.
// y := 1
//
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
// we notice the dangling period and end our expression.
//
// If the previous token was a "." and we are looking at a "}",
// the period is likely a dangling selector and needs a phantom
// "_". Likewise if the current token is on a different line than
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
// the period, the period is likely a dangling selector.
if lastToken == token.PERIOD && (tkn == token.RBRACE || tok.Line(to) > tok.Line(last)) {
// Insert phantom "_" selector after the dangling ".".
phantomSelectors = append(phantomSelectors, last+1)
// If we aren't in a block then end the expression after the ".".
if braceDepth == 0 {
to = last + 1
break
}
}
lastToken = tkn
last = to
switch tkn {
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
case token.RBRACE:
braceDepth--
if braceDepth <= 0 {
if braceDepth == 0 {
// +1 to include the "}" itself.
to += 1
}
break FindTo
}
}
}
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
if !from.IsValid() || tok.Offset(from) >= len(src) {
return false
}
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
if !to.IsValid() || tok.Offset(to) >= len(src) {
return false
}
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
// Insert any phantom selectors needed to prevent dangling "." from messing
// up the AST.
exprBytes := make([]byte, 0, int(to-from)+len(phantomSelectors))
for i, b := range src[tok.Offset(from):tok.Offset(to)] {
if len(phantomSelectors) > 0 && from+token.Pos(i) == phantomSelectors[0] {
exprBytes = append(exprBytes, '_')
phantomSelectors = phantomSelectors[1:]
}
exprBytes = append(exprBytes, b)
}
if len(phantomSelectors) > 0 {
exprBytes = append(exprBytes, '_')
}
expr, err := parseExpr(from, exprBytes)
if err != nil {
return false
}
// Package the expression into a fake *ast.CallExpr and re-insert
// into the function.
call := &ast.CallExpr{
Fun: expr,
Lparen: to,
Rparen: to,
}
switch stmt := stmt.(type) {
case *ast.DeferStmt:
stmt.Call = call
case *ast.GoStmt:
stmt.Call = call
}
return replaceNode(parent, bad, stmt)
}
// parseStmt parses the statement in src and updates its position to
// start at pos.
func parseStmt(pos token.Pos, src []byte) (ast.Stmt, error) {
// Wrap our expression to make it a valid Go file we can pass to ParseFile.
fileSrc := bytes.Join([][]byte{
[]byte("package fake;func _(){"),
src,
[]byte("}"),
}, nil)
// Use ParseFile instead of ParseExpr because ParseFile has
// best-effort behavior, whereas ParseExpr fails hard on any error.
fakeFile, err := parser.ParseFile(token.NewFileSet(), "", fileSrc, 0)
if fakeFile == nil {
return nil, errors.Errorf("error reading fake file source: %v", err)
}
// Extract our expression node from inside the fake file.
if len(fakeFile.Decls) == 0 {
return nil, errors.Errorf("error parsing fake file: %v", err)
}
fakeDecl, _ := fakeFile.Decls[0].(*ast.FuncDecl)
if fakeDecl == nil || len(fakeDecl.Body.List) == 0 {
return nil, errors.Errorf("no statement in %s: %v", src, err)
}
stmt := fakeDecl.Body.List[0]
// parser.ParseFile returns undefined positions.
// Adjust them for the current file.
offsetPositions(stmt, pos-1-(stmt.Pos()-1))
return stmt, nil
}
// parseExpr parses the expression in src and updates its position to
// start at pos.
func parseExpr(pos token.Pos, src []byte) (ast.Expr, error) {
stmt, err := parseStmt(pos, src)
if err != nil {
return nil, err
}
exprStmt, ok := stmt.(*ast.ExprStmt)
if !ok {
return nil, errors.Errorf("no expr in %s: %v", src, err)
}
return exprStmt.X, nil
}
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
var tokenPosType = reflect.TypeOf(token.NoPos)
// offsetPositions applies an offset to the positions in an ast.Node.
func offsetPositions(n ast.Node, offset token.Pos) {
ast.Inspect(n, func(n ast.Node) bool {
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
if n == nil {
return false
}
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
v := reflect.ValueOf(n).Elem()
switch v.Kind() {
case reflect.Struct:
for i := 0; i < v.NumField(); i++ {
f := v.Field(i)
if f.Type() != tokenPosType {
continue
}
if !f.CanSet() {
continue
}
f.SetInt(f.Int() + int64(offset))
internal/lsp: improve completions in go and defer statements Improve the existing fix-the-AST code to better identify the expression following the "go" or "defer" keywords: - Don't slurp the expression start outside the loop since the expression might only have a single token. - Set expression end to the position after the final token, not the position of the final token. - Track curly brace nesting to properly capture an entire "func() {}" expression. - Fix parent node detection to work when BadStmt isn't first statement of block. - Add special case to detect dangling period, e.g. "defer fmt.". We insert phantom "_" selectors like go/parser does to prevent the dangling "." from messing up the AST. - Use reflect in offsetPositions so it updates positions in all node types. This code shouldn't be called often, so I don't think performance is a concern. I also tweaked the function snippet code so it properly expands "defer" and "go" expressions to function calls. It thought it didn't have to expand since there was already a *ast.CallExpr, but the CallExpr was faked by us and the source doesn't actually contain the "()" calling parens. Note that this does not work for nested go/defer statements. For example, completions won't work properly in cases like this: go func() { defer fmt.<> } I think we can fix this as well with some more work. Change-Id: I8f9753fda76909b0e3a83489cdea69ad04ee237a Reviewed-on: https://go-review.googlesource.com/c/tools/+/193997 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-06 15:22:54 -06:00
}
}
return true
})
}
// replaceNode updates parent's child oldChild to be newChild. It
// returns whether it replaced successfully.
func replaceNode(parent, oldChild, newChild ast.Node) bool {
if parent == nil || oldChild == nil || newChild == nil {
return false
}
parentVal := reflect.ValueOf(parent).Elem()
if parentVal.Kind() != reflect.Struct {
return false
}
newChildVal := reflect.ValueOf(newChild)
tryReplace := func(v reflect.Value) bool {
if !v.CanSet() || !v.CanInterface() {
return false
}
// If the existing value is oldChild, we found our child. Make
// sure our newChild is assignable and then make the swap.
if v.Interface() == oldChild && newChildVal.Type().AssignableTo(v.Type()) {
v.Set(newChildVal)
return true
}
return false
}
// Loop over parent's struct fields.
for i := 0; i < parentVal.NumField(); i++ {
f := parentVal.Field(i)
switch f.Kind() {
// Check interface and pointer fields.
case reflect.Interface, reflect.Ptr:
if tryReplace(f) {
return true
}
// Search through any slice fields.
case reflect.Slice:
for i := 0; i < f.Len(); i++ {
if tryReplace(f.Index(i)) {
return true
}
}
}
}
return false
}