languages/go
languages/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-10-01 13:44:47 +00:00
Code Issues Packages Projects Releases Wiki Activity

cmd/compile, types2: avoid confusing follow-on error in invalid type assertion

Browse source 
This CL avoids a useless follow-on error (that gets reported before the
actual error due to source position). This addresses the first part of
the issue below.

Thanks to @cuonglm for the suggestion for the fix.

For #49005.

Change-Id: Ifdd83072a05c32e115dc58a0233868a64f336f3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/356449
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This commit is contained in:
Robert Griesemer 2021-10-16 20:30:12 -07:00
parent fa7d11a0e9
commit cf51fb5d68
2 changed files with 20 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
src/cmd/compile/internal/types2/typexpr.go
View file

@ -312,6 +312,13 @@ func (check *Checker) typInternal(e0 syntax.Expr, def *Named) (T Type) {
typ := new(Pointer)
def.setUnderlying(typ)
typ.base = check.varType(e.X)
// If typ.base is invalid, it's unlikely that *base is particularly
// useful - even a valid dereferenciation will lead to an invalid
// type again, and in some cases we get unexpected follow-on errors
// (e.g., see #49005). Return an invalid type instead.
if typ.base == Typ[Invalid] {
return Typ[Invalid]
}
return typ
}

13
test/fixedbugs/issue49005a.go Normal file
View file

@ -0,0 +1,13 @@
// errorcheck
// Copyright 2021 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.
package p
type T interface{ M() }
func F() T
var _ = F().(*X) // ERROR "undefined: X"