profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/findleyr/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

findleyr/gopherjs 0

A compiler from Go to JavaScript for running Go code in a browser

findleyr/govim 0

govim is a Go development plugin for Vim8, written in Go

issue commentgolang/go

x/pkgsite: add support for type parameters

@carlmjohnson this will definitely ship before 1.18.

Since no objections and #47781 has been accepted, I will start soon.

findleyr

comment created time in 10 hours

issue closedgolang/go

go/ast, go/token: additions to support type parameters

This proposal formally introduces the changes we’ve made to support parameterized functions and types in the go/ast and go/token packages. See the full write-up here: https://go.googlesource.com/proposal/+/master/design/47781-parameterized-go-ast.md

There will be a separate issue for go/types, where type parameters add a much larger API surface.

We’ve gotten some experience with these new APIs over the last few months by using them in go/types. The additional ~MultiIndexExpr~IndexListExpr node type is the most significant change, but felt cleanest of the alternatives we considered.

Any feedback is appreciated.

CC @griesemer

Changelog:

  • TParams fields were renamed to TypeParams
  • MultiIndexExpr was renamed to IndexListExpr

closed time in 3 days

findleyr

issue commentgolang/go

go/ast, go/token: additions to support type parameters

Thanks for the feedback, all!

Closing, as the accepted proposal matches the current implementation at tip.

findleyr

comment created time in 3 days

issue commentgolang/go

x/tools/gopls: show full comments for constant or variable declaration

We've just discussed this issue, and consensus was that formatting a truncated form of the full const decl (as shown in https://github.com/golang/go/issues/48200#issuecomment-914417728) makes sense. However, it isn't something we're likely to work on soon, so leaving this as 'help wanted'.

katsusan

comment created time in 4 days

issue commentgolang/go

proposal: go/types: additions to support type parameters

Thanks all who attended the tools call today. We had a good discussion, hopefully the first of several regarding support for type parameters in tools.

Unfortunately we forgot to start recording (:facepalm: my mistake). Here are some concrete suggestions that came up during the call:

  • @rogpeppe suggested that we rename Named.Orig to Origin; Origin is a better expansion than Original. I agree, and spelling it out is better.
  • @mvdan suggested we switch from SetTypeParams APIs to new constructors (NewGenericNamed, NewGenericSignature), and others agreed. The point being that we should not expose a mutable API if it is not strictly necessary. We've gone back and forth on this, and perhaps we arrived at the wrong conclusion.
  • @rogpeppe suggested to use a pointer receiver for ArgumentError methods.
  • @rogpeppe asked what Interface.IsConstraint will mean if type restricting elements are permitted in any interface? Will it always return false? What if others rely on it meaning 'has type restricting elements? Maybe if we choose to expose something like Interface.UnderIs, this method can be removed.
  • On that note, I think there was consensus that UnderIs would be useful, though @jba questioned the name UnderIs. We should think of a better name before officially proposing this API.
  • There also seemed to be consensus that providing a transistional package like x/tools/internal/typeparams would be helpful.

(to those who attended: please correct inaccuracies/omissions).

findleyr

comment created time in 6 days

issue commentgolang/go

proposal: go/types: additions to support type parameters

We've made some good progress on this proposal over the past week.

  • As mentioned in https://github.com/golang/go/issues/47916#issuecomment-920009890, I think we've found the correct additions to types.Info.
  • We've figured out a clean way to instantiate methods on type instances during type checking.
  • Instantation should now be concurrency-safe.
  • We're pretty sure that we can (and should) support type parameters on aliases (#46477) via an Alias type, though I'd prefer if we worked out the details a bit more.

At this point, I am starting to feel satisfied with the proposed APIs, though I do think we'll need at least one additional API:

  • For updating something like the printf analyzer, we really want a normalized view of the type set for a type parameter. Having users walk embedded Union types is not good enough: they'd need to re-implement the type set algorithms we use internally to compute things like intersections. We should expose something like func (*Interface) UnderIs(func(Type) bool) bool.
  • For x/tools/go/ssa, we'll need a more generalized type substituter in order to instantiate function bodies. We should perhaps expose this from go/types (we have an internal substituter for instantiation), but in fact our types.subster is currently insufficient for generalized substitution -- it makes certain assumptions that are only valid in the context of a declaration. My current feeling on this after discussing with @timothy-king is that we should write our own subtituter while working on go/ssa, and perhaps consider porting it to go/types in the future.

I'll note that there are really two milestones for the go/types API: (1) the point at which existing new APIs don't change, and (2) the point at which we're satisfied with the completeness of our APIs. I don't think these milestones need to be the same proposal, so perhaps if there is no change in the current APIs over the next couple weeks, we should consider accepting this proposal to mean (1), with the understanding that if/when we encounter new APIs that would help us add support for type parameters in tools and libraries, we can have additional proposal(s).

findleyr

comment created time in 6 days

issue commentgolang/go

proposal: go/types: additions to support type parameters

After several discussions regarding Info.Inferred, with CL 349629 I think we've found a clean API. Specifically, this CL

  • Renames Info.Inferred to Info.Instances
  • Keys the Info.Instances map on the *ast.Ident denoting the parameterized object
  • Changes type Inferred to type Instance struct { TypeArgs *TypeList; Type Type }
  • Records all instances (both *Named and *Signature), not just inferred signatures

Here are some indicators that this is the correct API:

  • It is easy to describe. The previous API required a longish doc comment describing which expressions could be map keys, and when information was recorded.
  • It will be useful if/when we support inference for type instances, which is being discussed.
  • It is easy to look up the generic type, via Info.Uses[id].Type().
  • Keying on identifier is flexible: at whichever level you're considering an instantiation expression, you should have access to the identifier.
  • Recording all instances helps answer the following question: what is the position of an instance? For *Named instances we had little option but to have Obj() return the generic declaration type name (else we'd depend on where the instance was first type-checked). But it is easy to imagine situations where we'd want to map an instance back to source positions where it occurs.
  • Recording all instances makes it easy for users like go/ssa to precompute instantiated function bodies.
findleyr

comment created time in 6 days

issue openedgolang/go

x/tools/internal/gcimporter: update iexport.go to support generics

CL 349949 updates x/tools/internal/gcimporter/iimport.go to support generics, by porting over changes from the standard library go/internal/gcimporter package. It will take longer to port iexport.go, as it must be translated from cmd/compile/internal/typecheck/iexport.go. In the meantime (~days, I expect), I think we should skip x/tools/go/internal/gcimporter.TestIExportData_stdlib on Go 1.18, in order to avoid failures on the x/tools Trybots on Go repo CLs that use generics.

This issue tracks that process (skipping the test, updating the exporter, and unskipping).

CC @griesemer @mdempsky @danscales @ianlancetaylor

created time in 6 days

issue openedgolang/go

x/tools/gopls: experimentalWorkspaceModule does not work for the standard library

Reminder issue: the experimentalWorkspaceModule setting does not behave correctly for std and cmd. We should (1) document this, and (2) investigate.

Moving this to v0.7.3 for at least improving the documentation.

CC @stamblerre

created time in 7 days

issue commentgolang/go

proposal: go/types: additions to support type parameters

In case anyone is interested in this proposal but doesn't follow the #tools slack, I'll be available at 15:30 UTC on Wednesday to go over this proposal and the AST proposal (#47781). My plan is to briefly go over the proposals, talk about some use-cases, and have a discussion with anyone who is interested (if anyone shows up!). More info here: https://groups.google.com/g/golang-tools/c/d5wjyBUjLEI

findleyr

comment created time in 7 days

issue commentgolang/go

proposal: go/types: additions to support type parameters

You mean we only set Info.Types for lib.F? Can't you use Info.Uses for (bare) F instead?

But I'm not opposed to keeping Sig if you think it's valuable.

I mean that in the following case: lib.F(args...), where do we look up the non-generic signature, if we don't provide Sig? We can look up Info.Uses["F"] to get the generic signature, but if we want non-generic type information we'd need to look up Info.Types["lib.F"] (assuming this type has been updated to the inferred type), or change the way we record type information for selectors. I feel like we shouldn't make users find the selector. For example, one can imagine a use case that starts from info.Inferred.

findleyr

comment created time in 8 days

issue commentgolang/go

proposal: go/types: additions to support type parameters

@mdempsky I experimented with the first two of your suggested changes to Info.Inferred here: https://golang.org/cl/349629. This keys off of the *ast.Ident and always records type arguments even if no inference occurred. However, I didn't get rid of Sig: if the inferred function is imported (as in lib.F), we don't record type information for the identifier F, only for lib.F. I like the idea of being able to join on *ast.Ident to access all information, and having to find the SelectorExpr to get the instantiated type breaks this. WDYT?

@scott-cotton I thought more about having TypeArgs and Orig on Signature, and think that we should leave it as-is. In the case of a Named type, type arguments and the original type are part of the type identity, but this isn't the case for Signatures. I think a good general rule is that we should avoid exposing information on types that isn't part of their identity, both to keep the API minimal and to avoid memory bloat (applications like gopls hold a lot of types in memory). If we change our minds we can always add these methods to Signature, but we could never reverse the decision.

findleyr

comment created time in 8 days

issue commentgolang/go

x/tools/gopls: crashes when instantiating generic function types with multiple parameters

Apologies for missing this.

Unfortunately I am unable to reproduce, either at tip or at that exact go commit, or even an older commit (I tried both with a go/types test and a gopls session, in case gopls' AST mangling had something to do with it). I just get the expected error from go/types: "got 1 argument but 2 type parameters".

Is there any additional information you can share? Are you sure you had built gopls at that exact Go commit, or is it possible you had built gopls earlier?

Otherwise, I'll see if I can reverse engineer a repro from the stack trace.

CC @griesemer

lu4p

comment created time in 8 days

issue closedgolang/go

x/tools/gopls: versions >= 0.7.0 consume entire cpu, whereas v0.6.11 works perfectly

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version go1.16.7 linux/amd64 </pre>

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

<pre> $ go env GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/nonroot/home/.cache/go-build"
GOENV="/nonroot/home/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/nonroot/home/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/nonroot/home/go"
GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GOVCS="" GOVERSION="go1.16.7" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/nonroot/home/workspaces/app/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3294291348=/tmp/go-build -gno-record-gcc-switches" </pre>

What did you do?

Using coc.nvim and gopls v0.7.1, after about 1min 30secs of jumping around function definitions (specifically :call CocAction('jumpDefinition'), gopls consumes the entire cpu of the machine and editing slows to a crawl/the machine is no longer responsive.

Downgrading to gopls v0.6.11 alleviates all issues.

Here is a picture of htop with gopls v0.7.1 that shows the high cpu consumption: IMG_0019

Here is a picture of htop with gopls v0.6.11 that shows normal cpu consumption: IMG_0020

Note: this seems to only occur on low powered machines. I am using a digital ocean droplet with 1 CPU. On high powered machines (8-core, ubuntu), this is not a problem. However, it appears to be a regression from v0.6.11 and makes gopls unusable for a basic VM.

Here are the machine details where the problem occurs:

<pre> $ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 40 bits physical, 48 bits virtual CPU(s): 1 On-line CPU(s) list: 0 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 85 Model name: DO-Premium-Intel Stepping: 4 CPU MHz: 2494.138 BogoMIPS: 4988.27 Virtualization: VT-x Hypervisor vendor: KVM Virtualization type: full L1d cache: 32 KiB L1i cache: 32 KiB L2 cache: 4 MiB NUMA node0 CPU(s): 0 Vulnerability Itlb multihit: KVM: Mitigation: Split huge pages Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled Vulnerability Mds: Mitigation; Clear CPU buffers; SMT Host state unknown Vulnerability Meltdown: Mitigation; PTI Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and user pointer sanitization Vulnerability Spectre v2: Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP disabled, RSB filling Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1 gb rdtscp lm constant_tsc arch_perfmon rep_good nopl cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4 1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid fault invpcid_single pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 sm ep bmi2 erms invpcid mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 pku ospke md_clear </pre>

Here is my coc-settings.json, taken from the gopls documentation:

<pre> { "languageserver": { "golang": { "command": "gopls", "rootPatterns": ["go.mod", ".vim/", ".git/", ".hg/"], "filetypes": ["go"] } } } </pre>

To reproduce this issue, you can use a docker container that I have built to show the problem.

step-by-step: (1) Spin up a low powered VM (2) Run docker run --rm -it -v ${PWD}:/home/nonroot/workspaces/app mperel/dev-container. This container has coc.nvim and gopls v0.6.11. It maps your current directory into the container, so you can edit files in the container. (3) Create a basic main.go and use :call CocAction(‘jumpDefinition’) to jump around the standard library (specifically, I jumped into fmt.Println and jumped around to different files from there). Notice that everything is fine. (4) Run go install golang.org/x/tools/gopls@latest to update gopls to v0.7.1 (5) Jump around using :call CocAction(‘jumpDefinition’) and notice after a little while that the machine becomes unresponsive. Consider running htop in another window to see the cpu consumption as the photos show.

What did you expect to see?

I expected gopls >= v0.7.0 to work on a low powered linux VM, just as gopls v0.6.11 does.

What did you see instead?

I saw excessive cpu consumption that drew the machine to a halt when using gopls >= v0.7.0.

closed time in 10 days

michaelperel

issue commentgolang/go

x/tools/gopls: versions >= 0.7.0 consume entire cpu, whereas v0.6.11 works perfectly

I'm going to close this, not because there isn't a poor experience here -- it's definitely a problem std consumes so many resources -- but because the root cause of this memory jump is not a regression. We have other open issues for performance.

michaelperel

comment created time in 10 days

issue commentgolang/go

x/tools/gopls: versions >= 0.7.0 consume entire cpu, whereas v0.6.11 works perfectly

@michaelperel https://golang.org/cl/330529 is in v0.7.1 but not v0.7.0, so the fact that v0.7.0 is fine supports the hypothesis that this is the root cause.

Have you tried the settings listed in the coc.nvim documentation to prevent GOROOT/src from being set as a workspace folder? Unfortunately, it looks like coc.nvim really wants to place each open buffer inside a workspace.

I don't think we can (or rather should) do anything about this on the gopls side: coc.nvim is telling us that it wants GOROOT/src to be a workspace folder, and it wouldn't be correct for us to ignore this request. If you can't get this to work with the coc.nvim documentation, raising an issue with coc.nvim makes sense to me.

michaelperel

comment created time in 10 days

issue commentgolang/go

proposal: go/types: additions to support type parameters

As a follow-up, I guess what I am trying to say in the last remark above about Inferred, is it seems like it would be much easier to use if both Signatures and Named had TArgs had TArgs() and Orig(), and then at all call sites, the Info.Type of the caller expression would always be the instantiated type.

Just wanted to point out that this suggestion by @scott-cotton still needs to be resolved -- I forgot to include it in https://github.com/golang/go/issues/47916#issuecomment-913751576 above. My intuition is that while this could be done, though the implementation may be a bit awkward. This needs experimentation.

findleyr

comment created time in 11 days

issue commentgolang/go

x/tools/gopls: panic in hover on v0.7.2-pre.1

Filed #48300 for the idiosyncracy in go/ast and go/parser that contributed to this panic, though the gopls code should have been more robust.

I think we can close this with CL 348930. Thanks again @egonelbre for reporting.

findleyr

comment created time in 12 days

issue openedgolang/go

go/parser: StructType.End() can overflow the File

As encountered in #48249, StructType.End() can overflow the file (such that File.Offset panics).

This is due to the error recovery here: https://cs.opensource.google/go/go/+/master:src/go/parser/parser.go;l=675;drc=0406d3a8e5301bd5fd697018e6e8fbb9c75eeb42

Which will set the StructType.Fields.Closing to the end of the file, and then StructType.Fields.End overflows: https://cs.opensource.google/go/go/+/master:src/go/ast/ast.go;l=252;drc=master

This is a low priority (the logic that gopls was using should have been more robust), but I feel like it should be an invariant of nodes that if Pos() or End() is not token.NoPos, they have a valid offset.

Are there counter-arguments or contradicting precedent?

CC @griesemer @stamblerre

created time in 12 days

issue commentgolang/go

x/tools/gopls: versions >= 0.7.0 consume entire cpu, whereas v0.6.11 works perfectly

Ah, I think I know what this is.

I believe this is a consequence of https://golang.org/cl/330529, which fixed loading std and cmd, plus the way that coc.nvim sets workspace roots.

IIRC When you jump to definition in std in coc.nvim, it detects that you are jumping out of your workspace, and attempts to add a new workspace due to detecting the workspace root from the go.mod file in std. In other words, it sets the standard library as a new workspace. For workspaces, gopls loads everything (all packages, including function bodies) so that it can compute things like references. When the standard library is a workspace root, this pulls quite a lot of code into memory.

By comparison, other LSP clients (such as vscode-go) don't add a new workspace root, so gopls only fully parses and type checks packages that you have open in the standard library, not the entire standard library.

The CL above fixed a bug causing gopls to essentially not load the standard library. Before that CL, coc.nvim would have behaved very similarly to vscode-go or other LSP clients. After that CL, coc.nvim will incur a penalty for loading the entire standard library.

I wouldn't categorize this as a regression in gopls per se, but it is certainly a problem that one can't use gopls to work on the standard library on an underpowered machine. While we have some distant plans to improve this by limiting the scope of the workspace gopls has to consider, can you try managing your workspaces explicitly in coc.nvim (using :CocList folders, I think?).

michaelperel

comment created time in 12 days

issue commentgolang/go

x/tools/gopls: versions >= 0.7.0 consume entire cpu, whereas v0.6.11 works perfectly

Hi, thanks very much for the report. We weren't aware of this regression, and with your reproducer hopefully we can bisect.

You mention v0.7.1 specifically, but cite this problem for gopls >=v0.7.0. Just to clarify: did you test this explicitly on v0.7.0 and confirm that it reproduces with that version?

michaelperel

comment created time in 12 days

issue commentgolang/go

cmd/compile: import issue with self-referential generic interface type

The problem only happens when import package.

Ack, right. Perhaps your suggested fix is the way to proceed.

rogpeppe

comment created time in 12 days

issue commentgolang/go

types2, go/types: repeated identical external instantiations of the same type will lead to different types

I do think we need more testing. Want to repurpose this issue, or shall I open a new one?

griesemer

comment created time in 12 days

issue commentgolang/go

cmd/compile: import issue with self-referential generic interface type

Thanks for the report. Somewhat related: #48098. We need more controls around recursive instantiation.

CC @griesemer

rogpeppe

comment created time in 12 days

issue commentgolang/go

x/pkgsite: add support for type parameters

One point you don't mention: none of those packages would be able to use 1.18 features

Right, that's a good point. In https://golang.org/cl/321949 I had to add a stub io/fs for this reason.

IIRC @griesemer and I had discussed and thought this was OK for these packages in particular. We also have a history of maintaining ports like x/tools/go/internal/gcimporter, but that's more work.

findleyr

comment created time in 12 days

issue closedgolang/go

go/types, types2: panic in eager error reporting for interface types

Type checking the following code panics at tip in go/types:

package p                                                                                                                                                                                                            
                                                                                                                                                                                                                     
var _ int = interface{m();m()}(nil)

Stack snippet:

<details>

panic: 198: duplicate method m [recovered]                                                                                                                                                                           
        panic: 198: duplicate method m [recovered]                                                        
        panic: 198: duplicate method m                                                                                                                                                                               
                                                     
goroutine 7 [running]:                                                                                    
testing.tRunner.func1.2({0x643160, 0xc00012c7e0})                                                                                                                                                                    
        /home/rfindley/src/go/src/testing/testing.go:1209 +0x24e                                                                                                                                                     
testing.tRunner.func1()                              
        /home/rfindley/src/go/src/testing/testing.go:1212 +0x225                                                                                                                                                     
panic({0x643160, 0xc00012c7e0})                                                                           
        /home/rfindley/src/go/src/runtime/panic.go:814 +0x207                                                                                                                                                        
go/types.(*Checker).handleBailout(0xc000140780, 0xc0000c5b58)                                                                                                                                                        
        /home/rfindley/src/go/src/go/types/check.go:244 +0x8b                                                                                                                                                        
panic({0x643160, 0xc00012c7e0})                                                                           
        /home/rfindley/src/go/src/runtime/panic.go:814 +0x207                                                                                                                                                        
go/types.computeInterfaceTypeSet.func2(0xc6, 0xc00014e0f0, 0x1)                                                                                                                                                      
        /home/rfindley/src/go/src/go/types/typeset.go:224 +0x565                                                                                                                                                     
go/types.computeInterfaceTypeSet(0x0, 0x6ea580, 0xc00010bf90)                                                                                                                                                        
        /home/rfindley/src/go/src/go/types/typeset.go:251 +0x208                                                                                                                                                     
go/types.(*Interface).typeSet(...)                                                                        
        /home/rfindley/src/go/src/go/types/interface.go:27                                                                                                                                                           
go/types.(*Interface).IsConstraint(0x6ea580)                                                              
        /home/rfindley/src/go/src/go/types/interface.go:107 +0x25                                                                                                                                                    
go/types.(*Checker).callExpr(0xc000140780, 0xc000029fc0, 0xc000029ec0)                                                                                                                                               
        /home/rfindley/src/go/src/go/types/call.go:121 +0x492                                                                                                                                                        
go/types.(*Checker).exprInternal(0xc000140780, 0xc000029fc0, {0x6eabc8, 0xc000029ec0}, {0x0, 0x0})                                                                                                                   
        /home/rfindley/src/go/src/go/types/expr.go:1436 +0x945                                                                                                                                                       
go/types.(*Checker).rawExpr(0x8583c0, 0xc000029fc0, {0x6eabc8, 0xc000029ec0}, {0x0, 0x0}, 0x0)                                                                                                                       
        /home/rfindley/src/go/src/go/types/expr.go:1075 +0x45                                                                                                                                                        
go/types.(*Checker).expr(0xc000140780, 0x6eaec8, {0x6eabc8, 0xc000029ec0})                                                                                                                                           
        /home/rfindley/src/go/src/go/types/expr.go:1559 +0x35                                                                                                                                                        
go/types.(*Checker).varDecl(0x64c9e0, 0xc00010bf40, {0xc00000e4b8, 0x20, 0x1}, {0x6eaec8, 0xc00013e180}, {0x6eabc8, 0xc000029ec0})
        /home/rfindley/src/go/src/go/types/decl.go:537 +0x176                                                                                                                                                        
go/types.(*Checker).objDecl(0xc000140780, {0x6f4958, 0xc00010bf40}, 0x589780)                                                                                                                                        
        /home/rfindley/src/go/src/go/types/decl.go:193 +0x665

</details>

On the dev.typeparams branch, we'd whittled down the need for explicit interface completion, but missed this type of eager error reporting (the error is encountered when checking assignability of the interface type, before all objects are resolved and interface type sets computed normally).

CC @griesemer

closed time in 12 days

findleyr

issue commentgolang/go

go/types, types2: panic in eager error reporting for interface types

Ported to types2 in https://golang.org/cl/348575

findleyr

comment created time in 12 days

GollumEvent
GollumEvent

issue openedgolang/go

x/pkgsite: add support for type parameters

As the proposal for go/ast has stabilized (#47781), I think it is time to start adding support for type parameters in pkgsite.

There is one major obstacle for this, which is that App Engine will not support 1.18 until some time after the 1.18 release, and we want to support type parameters well before then.

My thoughts on how to do this:

  • write a tool to maintain copies of stdlib packages in pkgsite. I made a working prototype of this in https://golang.org/cl/322411
  • copy the following packages to pkgsite: go/ast, go/build/constraint, go/format, go/internal/typeparams, go/parser, go/token, go/printer, go/scanner.
  • Wire these in to pkgsite, which already uses a modified copy of go/doc.

I tested that this was possible in https://golang.org/cl/321949.

Once this is done, we should be able to sync these copied packages to tip using go generate. Out of the box this should resolve parsing errors for generic code, and we can proceed with adding any additional features that make it easier to browse code with type parameters in pkgsite. After App Engine supports 1.18, we can delete these copies.

I can do this, but will hold of for a week or two to see if anyone has concerns or better ideas.

CC @julieqiu @jba @jamalc

created time in 13 days