cmd/cgo, debug/dwarf: fix translation of zero-size arrays
In cgo, now that recursive calls to typeConv.Type() always work,
we can more robustly calculate the array sizes based on the size
of our element type.
Also, in debug/dwarf, the decision to call zeroType is made
based on a type's usage within a particular struct, but dwarf.Type
values are cached in typeCache, so the modification might affect
uses of the type in other structs. Current compilers don't appear
to share DWARF type entries for "[]foo" and "[0]foo", but they also
don't consistently share type entries in other cases. Arguably
modifying the types is an improvement in some cases, but varying
translated types according to compiler whims seems like a bad idea.
Lastly, also in debug/dwarf, zeroType only needs to rewrite the
top-level dimension, and only if the rest of the array size is
non-zero.
Fixes #8428.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/127980043
2014-08-13 12:16:30 -06:00
|
|
|
// Copyright 2014 The Go Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
2014-08-28 20:40:57 -06:00
|
|
|
// This test fails on older versions of OS X because they use older buggy
|
|
|
|
// versions of Clang that emit ambiguous DWARF info. See issue 8611.
|
|
|
|
// +build !darwin
|
|
|
|
|
cmd/cgo, debug/dwarf: fix translation of zero-size arrays
In cgo, now that recursive calls to typeConv.Type() always work,
we can more robustly calculate the array sizes based on the size
of our element type.
Also, in debug/dwarf, the decision to call zeroType is made
based on a type's usage within a particular struct, but dwarf.Type
values are cached in typeCache, so the modification might affect
uses of the type in other structs. Current compilers don't appear
to share DWARF type entries for "[]foo" and "[0]foo", but they also
don't consistently share type entries in other cases. Arguably
modifying the types is an improvement in some cases, but varying
translated types according to compiler whims seems like a bad idea.
Lastly, also in debug/dwarf, zeroType only needs to rewrite the
top-level dimension, and only if the rest of the array size is
non-zero.
Fixes #8428.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/127980043
2014-08-13 12:16:30 -06:00
|
|
|
package cgotest
|
|
|
|
|
|
|
|
// Issue 8428. Cgo inconsistently translated zero size arrays.
|
|
|
|
|
|
|
|
/*
|
|
|
|
struct issue8428one {
|
|
|
|
char b;
|
|
|
|
char rest[];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct issue8428two {
|
|
|
|
void *p;
|
|
|
|
char b;
|
|
|
|
char rest[0];
|
2015-07-29 23:04:09 -06:00
|
|
|
char pad;
|
cmd/cgo, debug/dwarf: fix translation of zero-size arrays
In cgo, now that recursive calls to typeConv.Type() always work,
we can more robustly calculate the array sizes based on the size
of our element type.
Also, in debug/dwarf, the decision to call zeroType is made
based on a type's usage within a particular struct, but dwarf.Type
values are cached in typeCache, so the modification might affect
uses of the type in other structs. Current compilers don't appear
to share DWARF type entries for "[]foo" and "[0]foo", but they also
don't consistently share type entries in other cases. Arguably
modifying the types is an improvement in some cases, but varying
translated types according to compiler whims seems like a bad idea.
Lastly, also in debug/dwarf, zeroType only needs to rewrite the
top-level dimension, and only if the rest of the array size is
non-zero.
Fixes #8428.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/127980043
2014-08-13 12:16:30 -06:00
|
|
|
};
|
|
|
|
|
|
|
|
struct issue8428three {
|
|
|
|
char w[1][2][3][0];
|
|
|
|
char x[2][3][0][1];
|
|
|
|
char y[3][0][1][2];
|
|
|
|
char z[0][1][2][3];
|
|
|
|
};
|
|
|
|
*/
|
|
|
|
import "C"
|
|
|
|
|
|
|
|
import "unsafe"
|
|
|
|
|
|
|
|
var _ = C.struct_issue8428one{
|
2015-07-29 23:04:09 -06:00
|
|
|
b: C.char(0),
|
|
|
|
// The trailing rest field is not available in cgo.
|
|
|
|
// See issue 11925.
|
|
|
|
// rest: [0]C.char{},
|
cmd/cgo, debug/dwarf: fix translation of zero-size arrays
In cgo, now that recursive calls to typeConv.Type() always work,
we can more robustly calculate the array sizes based on the size
of our element type.
Also, in debug/dwarf, the decision to call zeroType is made
based on a type's usage within a particular struct, but dwarf.Type
values are cached in typeCache, so the modification might affect
uses of the type in other structs. Current compilers don't appear
to share DWARF type entries for "[]foo" and "[0]foo", but they also
don't consistently share type entries in other cases. Arguably
modifying the types is an improvement in some cases, but varying
translated types according to compiler whims seems like a bad idea.
Lastly, also in debug/dwarf, zeroType only needs to rewrite the
top-level dimension, and only if the rest of the array size is
non-zero.
Fixes #8428.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/127980043
2014-08-13 12:16:30 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
var _ = C.struct_issue8428two{
|
|
|
|
p: unsafe.Pointer(nil),
|
|
|
|
b: C.char(0),
|
|
|
|
rest: [0]C.char{},
|
|
|
|
}
|
|
|
|
|
|
|
|
var _ = C.struct_issue8428three{
|
|
|
|
w: [1][2][3][0]C.char{},
|
|
|
|
x: [2][3][0][1]C.char{},
|
|
|
|
y: [3][0][1][2]C.char{},
|
|
|
|
z: [0][1][2][3]C.char{},
|
|
|
|
}
|