code review 127980043: cmd/cgo, debug/dwarf: fix translation of zero-size arrays

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 issue 8428.

[mdempsky, 2014-08-13 04:47:42]

Hello iant (cc: golang-codereviews@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go

[mdempsky, 2014-08-13 04:51:57]

On 2014/08/13 04:47:42, mdempsky wrote:
> Hello iant (cc: mailto:golang-codereviews@googlegroups.com),
> 
> I'd like you to review this change to
> https://code.google.com/p/go

This CL touches a couple related issues.  I think it's small enough to be
reviewed as is, but let me know if you'd prefer I split it up into independent
CLs.

I tested with GCC 4.8.2 on Ubuntu 14.04 (linux/amd64), and also used CC=clang
(with Clang 3.5) and all the tests passed.  I also reviewed the LLVM source code
for DWARF information generation related to array types, and didn't see anything
that's significantly changed, so I think that should be reasonably
representative of older Clang-based systems too.

[iant, 2014-08-13 18:16:26]

LGTM

Thanks.

[iant, 2014-08-13 18:16:34]

*** Submitted as https://code.google.com/p/go/source/detail?r=132f262db488 ***

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 issue 8428.

LGTM=iant
R=iant
CC=golang-codereviews
https://codereview.appspot.com/127980043

Committer: Ian Lance Taylor <iant@golang.org>

[rsc, 2014-08-28 23:32:17]

mdempsky - 

The new test with [0] arrays breaks on OS X Lion. Rob just shared the _cgo_.o
containing the mishandled dwarf data on your google.com drive.

./issue8428.go:44: cannot use [1][2][3][0]C.char literal (type
[1][2][3][0]C.char) as type [0][2][3][1]C.char in field value

I believe that something is deciding that because the overall size is 0, the
leading array index must be 0 instead of the reported 1. It's possible that this
was always broken and your test just exercises it, but it's possible the new
code is not right in some way.

Could you take a look?

Thanks.
Russ

bismarck=% go test
# _/Users/r/go/misc/cgo/test
./issue8428.go:40: cannot use [0]C.char literal (type [0]C.char) as
type [1]C.char in field value
./issue8428.go:44: cannot use [1][2][3][0]C.char literal (type
[1][2][3][0]C.char) as type [0][2][3][1]C.char in field value
./issue8428.go:45: cannot use [2][3][0][1]C.char literal (type
[2][3][0][1]C.char) as type [0][3][1][1]C.char in field value
./issue8428.go:46: cannot use [3][0][1][2]C.char literal (type
[3][0][1][2]C.char) as type [0][1][1][2]C.char in field value
FAIL _/Users/r/go/misc/cgo/test [build failed]
bismarck=%

[r, 2014-08-28 23:34:02]

bismarck=% echo $GOARCH $GOOS; uname -a
amd64 darwin
Darwin bismarck.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23
16:26:45 PDT 2012; root:xnu-1699.32.7~1/RELEASE_I386 i386
bismarck=% clang --version
Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix
bismarck=%
It's running Darwin 10.7.5

[mdempsky, 2014-08-28 23:34:18]

On 2014/08/28 23:32:17, rsc wrote:
> Could you take a look?

Will do.