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

cmd/compile: better error message for type arguments used with unsatisfiable constraints (empty type sets) #40350

Closed
komuw opened this issue Jul 22, 2020 · 5 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@komuw
Copy link
Contributor

komuw commented Jul 22, 2020

What did you do?

Ran this program: https://go2goplay.golang.org/p/S4MLyTi6yA-

package main

import (
	"fmt"
)

type interger32 interface {
	type int32
}

type number interface {
	type float64, int, int32
	interger32
}

func Largest[type T number](s []T) T {
	var largest T
	for _, v := range s {
		if v > largest {
			largest = v
		}
	}
	return largest
}

func main() {
	arr := []int{101, -1, 45, 646, 3}
	l := Largest[int](arr)

	fmt.Printf("largest in %v is: %v", arr, l)
}

What did you expect to see?

  • Either it runs or produces a comprehensible error message about int32 been repeated in interfaces interger32 & number

What did you see instead?

type checking failed for main
prog.go2:28:15: int does not satisfy number (int not found in int32)
@toothrot toothrot added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 22, 2020
@toothrot toothrot added this to the Unreleased milestone Jul 22, 2020
@griesemer
Copy link
Contributor

Just for the record, the problem is not that int32 is repeated in both interfaces, the problem is that int is not repeated in both interfaces: When interfaces are embedded, all the type lists are intersected. This way we can guarantee that if a type T satisfies an interface that embeds an interface E, T also satisfies E.

Agreed that we could use a better error message. Not urgent.

@komuw
Copy link
Contributor Author

komuw commented Oct 30, 2021

seems resolved at tip.

@komuw komuw closed this as completed Oct 30, 2021
@griesemer
Copy link
Contributor

I'm going to re-open this. The error message at tip could be better. For:

package p

type interger32 interface {
	~int32
}

type number interface {
	~float64 | ~int | ~int32
	interger32
}

func f[T number]() {}

func _() {
	_ = f[int]
}

we get:

x.go:15:8: int does not satisfy number

We should say a bit more as to why.

@griesemer griesemer reopened this Oct 30, 2021
@griesemer griesemer added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Oct 30, 2021
@griesemer griesemer changed the title cmd/go2go: unclear error message in embedded type lists cmd/compile: better error message for type arguments used with unsatisfiable constraints (empty type sets) Oct 30, 2021
@griesemer griesemer modified the milestones: Unreleased, Go1.19 Mar 18, 2022
@gopherbot
Copy link

Change https://go.dev/cl/410894 mentions this issue: go/types, types2: use | rather than ∪ when printing term lists

@gopherbot
Copy link

Change https://go.dev/cl/410876 mentions this issue: go/types, types2: better error message if type is not in type set

gopherbot pushed a commit that referenced this issue Jun 7, 2022
With this change, the termlist String() function prints termlists
in the usual Go notation and thus we can use it in error reporting.
Preparation for fixing #40350.

For #40350.

Change-Id: Ia28318841305de234a71af3146ce0c59f5e601a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/410894
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

4 participants