cmd/cgo: more expansive test coverage #39537
Open
Labels
Milestone
Comments
I want to try to take this issue. |
Ideally the test should be added to the existing files misc/cgo/test/test.go and/or misc/cgo/test/testx.go. Thanks. |
Change https://golang.org/cl/240697 mentions this issue: |
Should I add some tests for union as well? |
@HowJMay Sure. Thanks. |
Change https://golang.org/cl/246057 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Jul 31, 2020
Consider this test package: package p // enum E { E0 }; // union U { long x; }; // void f(enum E e, union U* up) {} import "C" func f() { C.f(C.enum_E(C.E0), (*C.union_U)(nil)) } In Go 1.14, cgo translated this to (omitting irrelevant details): type _Ctype_union_U [8]byte func f() { _Cfunc_f(uint32(_Ciconst_E0), (*[8]byte)(nil)) } func _Cfunc_f(p0 uint32, p1 *[8]byte) (r1 _Ctype_void) { ... } Notably, _Ctype_union_U was declared as a defined type, but uses were being rewritten into uses of the underlying type, which matched how _Cfunc_f was declared. After CL 230037, cgo started consistently rewriting "C.foo" type expressions as "_Ctype_foo", which caused it to start emitting: type _Ctype_enum_E uint32 type _Ctype_union_U [8]byte func f() { _Cfunc_f(_Ctype_enum_E(_Ciconst_E0), (*_Ctype_union_U)(nil)) } // _Cfunc_f unchanged Of course, this fails to type-check because _Ctype_enum_E and _Ctype_union_U are defined types. This CL changes cgo to emit: type _Ctype_enum_E = uint32 type _Ctype_union_U = [8]byte // f unchanged since CL 230037 // _Cfunc_f still unchanged It would probably be better to fix this in (*typeConv).loadType so that cgo generated code uses the _Ctype_foo aliases too. But as it wouldn't have any effect on actual compilation, it's not worth the risk of touching it at this point in the release cycle. Updates #39537. Fixes #40494. Change-Id: I88269660b40aeda80a9a9433777601a781b48ac0 Reviewed-on: https://go-review.googlesource.com/c/go/+/246057 Reviewed-by: Ian Lance Taylor <iant@golang.org>
HowJMay
added a commit
to HowJMay/go
that referenced
this issue
Aug 15, 2020
HowJMay
added a commit
to HowJMay/go
that referenced
this issue
Aug 15, 2020
Add test for reading and writing C language union datatype For golang#39537
Change https://golang.org/cl/248683 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Oct 27, 2020
Allocate a C enum object, and test if it can be assigned a value successfully. For #39537 Change-Id: I7b5482112486440b9d99f2ee4051328d87f45dca GitHub-Last-Rev: 81890f4 GitHub-Pull-Request: #39977 Reviewed-on: https://go-review.googlesource.com/c/go/+/240697 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
cgo is very subtle, yet it's lacking in test coverage. For example, misc/cgo/test doesn't have any tests for C.enum_foo or C.struct_bar, and misc/cgo/testgodefs doesn't have any tests for constants (to be addressed by CL 237558).
/cc @ianlancetaylor
The text was updated successfully, but these errors were encountered: