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: