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: cannot parenthesize embedded type #52391

Closed
ddaa2000 opened this issue Apr 17, 2022 · 12 comments
Closed

cmd/compile: cannot parenthesize embedded type #52391

ddaa2000 opened this issue Apr 17, 2022 · 12 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@ddaa2000
Copy link

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

$ go version
go version go1.18.1 windows/amd64

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
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=      
set GOCACHE=C:\Users\ddaa\AppData\Local\go-build
set GOENV=C:\Users\ddaa\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\ddaa\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\ddaa\go
set GOPRIVATE=
set GOPROXY=https://goproxy.cn,direct
set GOROOT=C:\Users\ddaa\sdk\go1.18beta1
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Users\ddaa\sdk\go1.18beta1\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.18beta1
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=D:\programing\go\bugReview\go.mod
set GOWORK=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\ddaa\AppData\Local\Temp\go-build2142223041=/tmp/go-build -gno-rec
ord-gcc-switches

What did you do?

https://go.dev/play/p/nooihUfL3DB

What did you expect to see?

Compile successfully.
Or, Constraint0 and Constraint1 should behave consistently.

What did you see instead?

.\main.go:12:2: syntax error: cannot parenthesize embedded type

@mengzhuo mengzhuo changed the title affected/package: cmd/compile cmd/compile: cannot parenthesize embedded type Apr 18, 2022
@beoran
Copy link

beoran commented Apr 18, 2022

It works without the parentheses, but i agree it is somewhat inconsistent.

@thanm thanm added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 18, 2022
@thanm
Copy link
Contributor

thanm commented Apr 18, 2022

Related, #51655. I am not sure if there is anything to fix here, seems to me that the compiler is behaving according to the spec, no?

@ianlancetaylor
Copy link
Contributor

Note that this isn't quite the same as #51655, which is about embedding a type in a struct, not an interface. Embedding a type in a struct definitely does not permit parentheses.

But I'm not clear on why embedding a type in an interface doesn't permit parentheses. The current syntax says that an interface type can be a TypeElem which can be a TypeTerm which can be a Type which can be a "(" Type ")". So it seems to me that it should be permitted in this case.

CC @griesemer

@ianlancetaylor ianlancetaylor added this to the Go1.19 milestone Apr 18, 2022
@griesemer
Copy link
Contributor

Note that in 1.17 it's also not permitted to parenthesize an embedded interface (1.17 spec):

package p

type T0 interface{}

type T1 interface{
	(T0)
}

leads to:

x.go:6:2: syntax error: cannot parenthesize embedded type

so the behavior is simply in keeping with the existing pre-1.18 spec. At some point in the exploration of generics syntax we permitted parentheses everywhere (interfaces and structs) but eventually we went back to the more minimal changes to the syntax. #51655 is because we didn't fully revert the changes in go/parser.

I don't see any particular reason for not permitting parentheses here, but the code as is is intentional, not a bug.

@griesemer griesemer added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Apr 18, 2022
@griesemer griesemer self-assigned this Apr 18, 2022
@beoran
Copy link

beoran commented Apr 18, 2022

Does this mean the current 1.18 syntax spec is not correct?

@griesemer
Copy link
Contributor

@beoran Fair point - the spec's syntax here clearly does permit parentheses as @ianlancetaylor already observed. Agreed, this is a bug (presumably in the parser).

@griesemer griesemer added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Apr 18, 2022
@beoran
Copy link

beoran commented Apr 18, 2022

@griesemer Actually, I meant to say that this might be a bug in the spec. But if you say it is a bug in the compiler, then I will defer to your judgement. However, perhaps it would be good to see how gccgo reacts to this code?

@ianlancetaylor
Copy link
Contributor

gccgo does not yet support generics. I'm working on it.

@gopherbot
Copy link

Change https://go.dev/cl/400797 mentions this issue: cmd/compile/internal/types2: permit parentheses around types in interfaces

@griesemer
Copy link
Contributor

griesemer commented Apr 19, 2022

@beoran If the existing behavior is considered correct, then the spec is wrong. If the spec is correct, then the existing behavior is incorrect. Since it's permitted to write things like ~(chan<- int), we should also allow (chan<- int) for consistency. The spec already says so, it's more consistent, and adjusting the parser makes it simpler. So it seems like a win-win all around. CL pending.

@beoran
Copy link

beoran commented Apr 19, 2022

@griesemer well yes, it is either the spec or the go compiler that is wrong. I was just wondering which of the two it was. But you are right, in this case it is more consistent to say that the compiler is wrong.

@beoran
Copy link

beoran commented Apr 20, 2022

Thanks for the fix. I like how this actually makes the go compiler 's parser simpler.

@golang golang locked and limited conversation to collaborators Jun 22, 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

6 participants