Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

go/types: incorrect recursive interface call accepted inside interface method declaration #22992

Closed
griesemer opened this issue Dec 4, 2017 · 4 comments
Closed

go/types: incorrect recursive interface call accepted inside interface method declaration #22992

griesemer opened this issue Dec 4, 2017 · 4 comments
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. FrozenDueToAge
Milestone
Go1.11

Comments

@griesemer
Copy link
Contributor

griesemer commented Dec 4, 2017 •
edited by mdempsky 

type I interface {
	m([unsafe.Sizeof(func() { I.m(nil) })]byte)
}

type-checks without problems; yet the call I.m has two parameters (the interface I, and a byte array of appropriate length). For reference, cmd/compile produces:

x.go:8:31: not enough arguments in call to method expression I.m
	have (nil)
	want (I, [8]byte)

Clearly an esoteric case, but good for corner-case testing.
@griesemer griesemer added this to the Go1.11 milestone Dec 4, 2017
@griesemer griesemer self-assigned this Dec 4, 2017
@griesemer griesemer added the early-in-cycle A change that should be done early in the 3 month dev cycle. label Dec 8, 2017
@griesemer
Copy link
Contributor Author

griesemer commented Dec 8, 2017 •
edited

The problem is that type checking of closure bodies happens immediately, while type-checking the enclosing and thus incomplete signature, rather than delayed, as is the case for regular functions/methods.

There's already a TODO that this should be changed (go/types/expr.go:1034).

@gopherbot
Copy link

Change https://golang.org/cl/83017 mentions this issue: go/types: add lookup method to context and factor out LookupParent calls

@gopherbot
Copy link

Change https://golang.org/cl/83397 mentions this issue: go/types: delay type-checking of closures like any other function

@gopherbot
Copy link

Change https://golang.org/cl/84898 mentions this issue: go/types: perform delayed tests even for types.Eval

gopherbot pushed a commit that referenced this issue Feb 12, 2018
@griesemer
go/types: add lookup method to context and factor out LookupParent calls
574fc66 
R=go1.11

Also: Moved Checker.pos field into context where it belongs.

This is a cleanup/code factoring.

For #22992.

Change-Id: If9d4f0af537cb181f73735e709ebc8258b2a1378
Reviewed-on: https://go-review.googlesource.com/83017
Reviewed-by: Alan Donovan <adonovan@google.com>
gopherbot pushed a commit that referenced this issue Feb 12, 2018
@griesemer
go/types: perform delayed tests even for types.Eval
d5e47fd 
R=go1.11

types.Eval historically never evaluated any delayed tests, which
included verification of validity of map keys, but also function
literal bodies.

Now, embedded interfaces are also type-checked in a delayed fashion,
so it becomes imperative to do all delayed checks for eval (otherwise
obviously incorrect type expressions are silently accepted).

Enabling the delayed tests also removes the restriction that function
literals were not type-checked.

Also fixed a bug where eval wouldn't return a type-checking error
because check.handleBailout was using the wrong err variable.

Added tests that verify that method set computation is using the
right types when evaluating interfaces with embedded types.

For #18395.
For #22992.

Change-Id: I574fa84568b5158bca4b4ccd4ef5abb616fbf896
Reviewed-on: https://go-review.googlesource.com/84898
Reviewed-by: Alan Donovan <adonovan@google.com>
@golang golang locked and limited conversation to collaborators Feb 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. FrozenDueToAge
Projects
None yet
Milestone
Go1.11
Development

No branches or pull requests
2 participants
@griesemer @gopherbot