qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-19 05:34:40 -07:00
Code Releases Activity
774c71fcf1
go/internal/lsp/testdata/rank/convert_rank.go.in

43 lines
1.1 KiB
Go
Raw Normal View History

internal/lsp: improve completion support for type conversions Now when completing in code like: foo := int64(<>) we prefer candidates whose type is convertible to int64. Change-Id: Iadc6cdc7de097ac30d8807d6f5aa21d83f89d756 GitHub-Last-Rev: a86dd72496ba752a1f20877c0594ec6a0ed8160e GitHub-Pull-Request: golang/tools#127 Reviewed-on: https://go-review.googlesource.com/c/tools/+/183941 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-06-27 16:37:50 -06:00
package rank
func _() {
type strList []string
wantsStrList := func(strList) {}
var (
convA string //@item(convertA, "convA", "string", "var")
convB []string //@item(convertB, "convB", "[]string", "var")
)
wantsStrList(strList(conv)) //@complete("))", convertB, convertA)
}
internal/lsp: improve completion support for untyped constants Add some extra smarts when evaluating untyped constants as completion candidates. Previously we called types.Default() on the expected type and candidate type, but this loses the untypedness of an untyped constant which prevents it from being assignable to any type or named type other than the untyped constant's default type. Note that the added logic does not take into account the untyped constant's value, so you will still get some false positive completions (e.g. suggesting an untyped negative integer constant when only a uint would do). Unfortunately go/types doesn't provide a way of answering the question "is this *types.Const assignable to this types.Type" since types.AssignableTo only considers a constant's type, not its value. Change-Id: If7075642e928f712b127256ae7706a5190e2f42c GitHub-Last-Rev: 124d2f05b0aec09c9d7004d9da0d900524185b92 GitHub-Pull-Request: golang/tools#128 Reviewed-on: https://go-review.googlesource.com/c/tools/+/184477 Reviewed-by: Suzy Mueller <suzmue@golang.org>
2019-07-01 15:28:46 -06:00
func _() {
internal/lsp: downrank untyped completion candidates In cases like: type myInt int const ( a = 1 b myInt = 2 ) var foo myInt = <> We now prefer "b" over "a" since b's type matches the expected type exactly. Change-Id: I675934761cc17f6b303b63b4715b31dd1af7cea1 Reviewed-on: https://go-review.googlesource.com/c/tools/+/202737 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-10-22 22:50:40 -06:00
type myInt int
internal/lsp: improve completion support for untyped constants Add some extra smarts when evaluating untyped constants as completion candidates. Previously we called types.Default() on the expected type and candidate type, but this loses the untypedness of an untyped constant which prevents it from being assignable to any type or named type other than the untyped constant's default type. Note that the added logic does not take into account the untyped constant's value, so you will still get some false positive completions (e.g. suggesting an untyped negative integer constant when only a uint would do). Unfortunately go/types doesn't provide a way of answering the question "is this *types.Const assignable to this types.Type" since types.AssignableTo only considers a constant's type, not its value. Change-Id: If7075642e928f712b127256ae7706a5190e2f42c GitHub-Last-Rev: 124d2f05b0aec09c9d7004d9da0d900524185b92 GitHub-Pull-Request: golang/tools#128 Reviewed-on: https://go-review.googlesource.com/c/tools/+/184477 Reviewed-by: Suzy Mueller <suzmue@golang.org>
2019-07-01 15:28:46 -06:00
const (
convC = "hi" //@item(convertC, "convC", "string", "const")
convD = 123 //@item(convertD, "convD", "int", "const")
convE int = 123 //@item(convertE, "convE", "int", "const")
convF string = "there" //@item(convertF, "convF", "string", "const")
internal/lsp: downrank untyped completion candidates In cases like: type myInt int const ( a = 1 b myInt = 2 ) var foo myInt = <> We now prefer "b" over "a" since b's type matches the expected type exactly. Change-Id: I675934761cc17f6b303b63b4715b31dd1af7cea1 Reviewed-on: https://go-review.googlesource.com/c/tools/+/202737 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-10-22 22:50:40 -06:00
convG myInt = 123 //@item(convertG, "convG", "myInt", "const")
internal/lsp: improve completion support for untyped constants Add some extra smarts when evaluating untyped constants as completion candidates. Previously we called types.Default() on the expected type and candidate type, but this loses the untypedness of an untyped constant which prevents it from being assignable to any type or named type other than the untyped constant's default type. Note that the added logic does not take into account the untyped constant's value, so you will still get some false positive completions (e.g. suggesting an untyped negative integer constant when only a uint would do). Unfortunately go/types doesn't provide a way of answering the question "is this *types.Const assignable to this types.Type" since types.AssignableTo only considers a constant's type, not its value. Change-Id: If7075642e928f712b127256ae7706a5190e2f42c GitHub-Last-Rev: 124d2f05b0aec09c9d7004d9da0d900524185b92 GitHub-Pull-Request: golang/tools#128 Reviewed-on: https://go-review.googlesource.com/c/tools/+/184477 Reviewed-by: Suzy Mueller <suzmue@golang.org>
2019-07-01 15:28:46 -06:00
)
var foo int
internal/lsp: downrank untyped completion candidates In cases like: type myInt int const ( a = 1 b myInt = 2 ) var foo myInt = <> We now prefer "b" over "a" since b's type matches the expected type exactly. Change-Id: I675934761cc17f6b303b63b4715b31dd1af7cea1 Reviewed-on: https://go-review.googlesource.com/c/tools/+/202737 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-10-22 22:50:40 -06:00
foo = conv //@rank(" //", convertE, convertD)
internal/lsp: improve completion support for untyped constants Add some extra smarts when evaluating untyped constants as completion candidates. Previously we called types.Default() on the expected type and candidate type, but this loses the untypedness of an untyped constant which prevents it from being assignable to any type or named type other than the untyped constant's default type. Note that the added logic does not take into account the untyped constant's value, so you will still get some false positive completions (e.g. suggesting an untyped negative integer constant when only a uint would do). Unfortunately go/types doesn't provide a way of answering the question "is this *types.Const assignable to this types.Type" since types.AssignableTo only considers a constant's type, not its value. Change-Id: If7075642e928f712b127256ae7706a5190e2f42c GitHub-Last-Rev: 124d2f05b0aec09c9d7004d9da0d900524185b92 GitHub-Pull-Request: golang/tools#128 Reviewed-on: https://go-review.googlesource.com/c/tools/+/184477 Reviewed-by: Suzy Mueller <suzmue@golang.org>
2019-07-01 15:28:46 -06:00
var mi myInt
internal/lsp: downrank untyped completion candidates In cases like: type myInt int const ( a = 1 b myInt = 2 ) var foo myInt = <> We now prefer "b" over "a" since b's type matches the expected type exactly. Change-Id: I675934761cc17f6b303b63b4715b31dd1af7cea1 Reviewed-on: https://go-review.googlesource.com/c/tools/+/202737 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-10-22 22:50:40 -06:00
mi = conv //@rank(" //", convertG, convertD, convertE)
mi + conv //@rank(" //", convertG, convertD, convertE)
internal/lsp: improve completion support for untyped constants Add some extra smarts when evaluating untyped constants as completion candidates. Previously we called types.Default() on the expected type and candidate type, but this loses the untypedness of an untyped constant which prevents it from being assignable to any type or named type other than the untyped constant's default type. Note that the added logic does not take into account the untyped constant's value, so you will still get some false positive completions (e.g. suggesting an untyped negative integer constant when only a uint would do). Unfortunately go/types doesn't provide a way of answering the question "is this *types.Const assignable to this types.Type" since types.AssignableTo only considers a constant's type, not its value. Change-Id: If7075642e928f712b127256ae7706a5190e2f42c GitHub-Last-Rev: 124d2f05b0aec09c9d7004d9da0d900524185b92 GitHub-Pull-Request: golang/tools#128 Reviewed-on: https://go-review.googlesource.com/c/tools/+/184477 Reviewed-by: Suzy Mueller <suzmue@golang.org>
2019-07-01 15:28:46 -06:00
internal/lsp: fix variadic interface completion ranking In cases like: var foo []io.Writer var buf *bytes.Buffer foo = append(foo, <>) we weren't giving "buf" a good score. When comparing the candidate type *bytes.Buffer to the (variadic) expected type []io.Writer we were turning the candidate type into []*bytes.Buffer. However, of course, []*bytes.Buffer is not assignable to []io.Writer, so the types didn't match. Now we instead turn the expected type []io.Writer into io.Writer and compare to *bytes.Buffer. I fixed the @rank test note to check that the candidates' scores are strictly decreasing. Previously it would allow candidates with the same score if they happened to be in the right order. This made it easier to right a test for this issue, but also uncovered an issue with untyped completion logic. I fixed it to do the untyped constant check if _either_ the expected or candidate type is untyped (previously it required the candidate type to be untyped). Fixes golang/go#35625. Change-Id: I9a837d6a781669cb7a2f1d6d3d7f360c85be49eb Reviewed-on: https://go-review.googlesource.com/c/tools/+/207518 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-11-15 17:14:15 -07:00
1 + conv //@rank(" //", convertD, convertC),rank(" //", convertE, convertC),rank(" //", convertG, convertC)
internal/lsp: improve completion support for untyped constants Add some extra smarts when evaluating untyped constants as completion candidates. Previously we called types.Default() on the expected type and candidate type, but this loses the untypedness of an untyped constant which prevents it from being assignable to any type or named type other than the untyped constant's default type. Note that the added logic does not take into account the untyped constant's value, so you will still get some false positive completions (e.g. suggesting an untyped negative integer constant when only a uint would do). Unfortunately go/types doesn't provide a way of answering the question "is this *types.Const assignable to this types.Type" since types.AssignableTo only considers a constant's type, not its value. Change-Id: If7075642e928f712b127256ae7706a5190e2f42c GitHub-Last-Rev: 124d2f05b0aec09c9d7004d9da0d900524185b92 GitHub-Pull-Request: golang/tools#128 Reviewed-on: https://go-review.googlesource.com/c/tools/+/184477 Reviewed-by: Suzy Mueller <suzmue@golang.org>
2019-07-01 15:28:46 -06:00
type myString string
var ms myString
internal/lsp: downrank untyped completion candidates In cases like: type myInt int const ( a = 1 b myInt = 2 ) var foo myInt = <> We now prefer "b" over "a" since b's type matches the expected type exactly. Change-Id: I675934761cc17f6b303b63b4715b31dd1af7cea1 Reviewed-on: https://go-review.googlesource.com/c/tools/+/202737 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-10-22 22:50:40 -06:00
ms = conv //@rank(" //", convertC, convertF)
internal/lsp: improve completion support for untyped constants Add some extra smarts when evaluating untyped constants as completion candidates. Previously we called types.Default() on the expected type and candidate type, but this loses the untypedness of an untyped constant which prevents it from being assignable to any type or named type other than the untyped constant's default type. Note that the added logic does not take into account the untyped constant's value, so you will still get some false positive completions (e.g. suggesting an untyped negative integer constant when only a uint would do). Unfortunately go/types doesn't provide a way of answering the question "is this *types.Const assignable to this types.Type" since types.AssignableTo only considers a constant's type, not its value. Change-Id: If7075642e928f712b127256ae7706a5190e2f42c GitHub-Last-Rev: 124d2f05b0aec09c9d7004d9da0d900524185b92 GitHub-Pull-Request: golang/tools#128 Reviewed-on: https://go-review.googlesource.com/c/tools/+/184477 Reviewed-by: Suzy Mueller <suzmue@golang.org>
2019-07-01 15:28:46 -06:00
type myUint uint32
var mu myUint
internal/lsp: downrank untyped completion candidates In cases like: type myInt int const ( a = 1 b myInt = 2 ) var foo myInt = <> We now prefer "b" over "a" since b's type matches the expected type exactly. Change-Id: I675934761cc17f6b303b63b4715b31dd1af7cea1 Reviewed-on: https://go-review.googlesource.com/c/tools/+/202737 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-10-22 22:50:40 -06:00
mu = conv //@rank(" //", convertD, convertE)
internal/lsp: improve completion support for untyped constants Add some extra smarts when evaluating untyped constants as completion candidates. Previously we called types.Default() on the expected type and candidate type, but this loses the untypedness of an untyped constant which prevents it from being assignable to any type or named type other than the untyped constant's default type. Note that the added logic does not take into account the untyped constant's value, so you will still get some false positive completions (e.g. suggesting an untyped negative integer constant when only a uint would do). Unfortunately go/types doesn't provide a way of answering the question "is this *types.Const assignable to this types.Type" since types.AssignableTo only considers a constant's type, not its value. Change-Id: If7075642e928f712b127256ae7706a5190e2f42c GitHub-Last-Rev: 124d2f05b0aec09c9d7004d9da0d900524185b92 GitHub-Pull-Request: golang/tools#128 Reviewed-on: https://go-review.googlesource.com/c/tools/+/184477 Reviewed-by: Suzy Mueller <suzmue@golang.org>
2019-07-01 15:28:46 -06:00
}
Copy Permalink