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: constraints that are impossible to satisfy are not caught #67025

Closed
mertcandav opened this issue Apr 24, 2024 · 3 comments
Closed
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. generics Issue is related to generics NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@mertcandav
Copy link

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

$ go version
go version go1.20.3 darwin/arm64

Does this issue reproduce with the latest release?

Yes.

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

go env Output
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/mertcandav/Library/Caches/go-build"
GOENV="/Users/mertcandav/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/mertcandav/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/mertcandav/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.20.3"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/jq/_8zwvbpd0qd5sd2yk4ypk7w40000gn/T/go-build1983794575=/tmp/go-build -gno-record-gcc-switches -fno-common"
GOROOT/bin/go version: go version go1.20.3 darwin/arm64
GOROOT/bin/go tool compile -V: compile version go1.20.3
uname -v: Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:49 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6020
ProductName:		macOS
ProductVersion:		14.4.1
BuildVersion:		23E224
lldb --version: lldb-1500.0.404.7
Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)

What did you do?

I used generic types that refer to each other. This will result in a cycle that is impossible to satisfy (please correct me if I am wrong). From what I've seen the compiler doesn't complain about this loop.

This isn't something I actually do in practice, I was just curious. I don't know if this is legal or reported before. I just thought it would be a good idea to let you know.

Here is Go Playground.

What did you expect to see?

I expect the compiler to complain that this isn't possible.

What did you see instead?

A compiler error regarding types incompatibility. It is not possible to fix this, but the compiler seems to leave the impression that it is possible.

@seankhliao seankhliao changed the title compiler: constraints that are impossible to satisfy are not catched cmd/compile: constraints that are impossible to satisfy are not catched Apr 24, 2024
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Apr 24, 2024
@seankhliao seankhliao changed the title cmd/compile: constraints that are impossible to satisfy are not catched cmd/compile: constraints that are impossible to satisfy are not caught Apr 24, 2024
@seankhliao seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 24, 2024
@randall77
Copy link
Contributor

We do not promise to detect unsatisfiable type parameters. See https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#empty-type-sets
My understanding is that is because the problem is in general NP-complete.
Your case does seem a simple case that could be caught. Probably not a high priority though, as any use is guaranteed to fail at compile time.

@zigo101
Copy link

zigo101 commented Apr 26, 2024

Spec mentions:

Implementation restriction: A compiler need not report an error if an operand's type is a type parameter with an empty type set. Functions with such type parameters cannot be instantiated; any attempt will lead to an error at the instantiation site.

See the end of this article for more empty type set examples.

@mknyszek mknyszek added this to the Backlog milestone May 8, 2024
@mknyszek mknyszek added the generics Issue is related to generics label May 8, 2024
@griesemer
Copy link
Contributor

What @randall77 said.

The compiler could detect such constraints in many cases (don't know about all of them, or this specific case) but we early on decided that reporting such errors are not important because the respective generic types/functions cannot be instantiated anyway and thus cannot be used. Detecting that a type set is empty is potentially expensive, and it may also depend on how a related constraint is instantiated (in which case an early error wouldn't be possible in the first place).

Closing as working as intended.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. generics Issue is related to generics NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Development

No branches or pull requests

7 participants