1
0
mirror of https://github.com/golang/go synced 2024-11-27 04:11:22 -07:00
go/test/method1.go

25 lines
727 B
Go
Raw Normal View History

// errorcheck
// Copyright 2009 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.
// Verify that method redeclarations are caught by the compiler.
// Does not compile.
package main
cmd/compile: ignore receiver parameters in Eqtype Receiver parameters generally aren't relevant to the function signature type. In particular: 1. When checking whether a type's method implements an interface's method, we specifically want to ignore the receiver parameters, because they'll be different. 2. When checking interface type equality, interface methods always use the same "fakethis" *struct{} type as their receiver. 3. Finally, method expressions and method values degenerate into receiver-less function types. The only case where we care about receiver types matching is in addmethod, which is easily handled by adding an extra Eqtype check of the receiver parameters. Also, added a test for this, since (surprisingly) there weren't any. As precedence, go/types.Identical ignores receiver parameters when comparing go/types.Signature values. Notably, this allows us to slightly simplify the "implements" function, which is used for checking whether type/interface t implements interface iface. Currently, cmd/compile actually works around Eqtype's receiver parameter checking by creating new throwaway TFUNC Types without the receiver parameter. (Worse, the compiler currently only provides APIs to build TFUNC Types from Nod syntax trees, so building those throwaway types also involves first building throwaway syntax trees.) Passes toolstash -cmp. Change-Id: Ib07289c66feacee284e016bc312e8c5ff674714f Reviewed-on: https://go-review.googlesource.com/20602 Reviewed-by: Robert Griesemer <gri@golang.org>
2016-03-11 15:38:16 -07:00
type T struct{}
cmd/compile: ignore receiver parameters in Eqtype Receiver parameters generally aren't relevant to the function signature type. In particular: 1. When checking whether a type's method implements an interface's method, we specifically want to ignore the receiver parameters, because they'll be different. 2. When checking interface type equality, interface methods always use the same "fakethis" *struct{} type as their receiver. 3. Finally, method expressions and method values degenerate into receiver-less function types. The only case where we care about receiver types matching is in addmethod, which is easily handled by adding an extra Eqtype check of the receiver parameters. Also, added a test for this, since (surprisingly) there weren't any. As precedence, go/types.Identical ignores receiver parameters when comparing go/types.Signature values. Notably, this allows us to slightly simplify the "implements" function, which is used for checking whether type/interface t implements interface iface. Currently, cmd/compile actually works around Eqtype's receiver parameter checking by creating new throwaway TFUNC Types without the receiver parameter. (Worse, the compiler currently only provides APIs to build TFUNC Types from Nod syntax trees, so building those throwaway types also involves first building throwaway syntax trees.) Passes toolstash -cmp. Change-Id: Ib07289c66feacee284e016bc312e8c5ff674714f Reviewed-on: https://go-review.googlesource.com/20602 Reviewed-by: Robert Griesemer <gri@golang.org>
2016-03-11 15:38:16 -07:00
func (t *T) M(int, string) // GCCGO_ERROR "previous"
func (t *T) M(int, float64) {} // ERROR "redeclared|redefinition"
cmd/compile: ignore receiver parameters in Eqtype Receiver parameters generally aren't relevant to the function signature type. In particular: 1. When checking whether a type's method implements an interface's method, we specifically want to ignore the receiver parameters, because they'll be different. 2. When checking interface type equality, interface methods always use the same "fakethis" *struct{} type as their receiver. 3. Finally, method expressions and method values degenerate into receiver-less function types. The only case where we care about receiver types matching is in addmethod, which is easily handled by adding an extra Eqtype check of the receiver parameters. Also, added a test for this, since (surprisingly) there weren't any. As precedence, go/types.Identical ignores receiver parameters when comparing go/types.Signature values. Notably, this allows us to slightly simplify the "implements" function, which is used for checking whether type/interface t implements interface iface. Currently, cmd/compile actually works around Eqtype's receiver parameter checking by creating new throwaway TFUNC Types without the receiver parameter. (Worse, the compiler currently only provides APIs to build TFUNC Types from Nod syntax trees, so building those throwaway types also involves first building throwaway syntax trees.) Passes toolstash -cmp. Change-Id: Ib07289c66feacee284e016bc312e8c5ff674714f Reviewed-on: https://go-review.googlesource.com/20602 Reviewed-by: Robert Griesemer <gri@golang.org>
2016-03-11 15:38:16 -07:00
func (t T) H() // GCCGO_ERROR "previous"
func (t *T) H() {} // ERROR "redeclared|redefinition"
func f(int, string) // GCCGO_ERROR "previous"
func f(int, float64) {} // ERROR "redeclared|redefinition"
func g(a int, b string) // GCCGO_ERROR "previous"
func g(a int, c string) // ERROR "redeclared|redefinition"