qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-18 23:44:43 -07:00
Code Releases Activity
caa0b0f7d5
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: 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
1 + conv //@rank(" //", convertD, convertE, convertG)
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