Commit 06ad3b2d authored by Russ Cox's avatar Russ Cox

cmd/cgo: stop using compiler error message text to analyze C names

The old approach to determining whether "name" was a type, constant,
or expression was to compile the C program

        name;

and scan the errors and warnings generated by the compiler.
This requires looking for specific substrings in the errors and warnings,
which ties the implementation to specific compiler versions.
As compilers change their errors or drop warnings, cgo breaks.
This happens slowly but it does happen.
Clang in particular (now required on OS X) has a significant churn rate.

The new approach compiles a slightly more complex program
that is either valid C or not valid C depending on what kind of
thing "name" is. It uses only the presence or absence of an error
message on a particular line, not the error text itself. The program is:

        // error if and only if name is undeclared
        void f1(void) { typeof(name) *x; }

        // error if and only if name is not a type
        void f2(void) { name *x; }

        // error if and only if name is not an integer constant
        void f3(void) { enum { x = (name)*1 }; }

I had not been planning to do this until Go 1.3, because it is a
non-trivial change, but it fixes a real Xcode 5 problem in Go 1.2,
and the new code is easier to understand than the old code.
It should be significantly more robust.

Fixes #6596.
Fixes #6612.

R=golang-dev, r, james, iant
CC=golang-dev
https://golang.org/cl/15070043
parent 20f99ffa
...@@ -49,5 +49,6 @@ func TestFpVar(t *testing.T) { testFpVar(t) } ...@@ -49,5 +49,6 @@ func TestFpVar(t *testing.T) { testFpVar(t) }
func Test4339(t *testing.T) { test4339(t) } func Test4339(t *testing.T) { test4339(t) }
func Test6390(t *testing.T) { test6390(t) } func Test6390(t *testing.T) { test6390(t) }
func Test5986(t *testing.T) { test5986(t) } func Test5986(t *testing.T) { test5986(t) }
func TestNaming(t *testing.T) { testNaming(t) }
func BenchmarkCgoCall(b *testing.B) { benchCgoCall(b) } func BenchmarkCgoCall(b *testing.B) { benchCgoCall(b) }
// Copyright 2013 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.
// golang.org/issue/6612
// Test new scheme for deciding whether C.name is an expression, type, constant.
// Clang silences some warnings when the name is a #defined macro, so test those too
// (even though we now use errors exclusively, not warnings).
package cgotest
/*
void myfunc(void) {}
int myvar = 5;
const char *mytext = "abcdef";
typedef int mytype;
enum {
myenum = 1234,
};
#define myfunc_def myfunc
#define myvar_def myvar
#define mytext_def mytext
#define mytype_def mytype
#define myenum_def myenum
#define myint_def 12345
#define myfloat_def 1.5
#define mystring_def "hello"
*/
import "C"
import "testing"
func testNaming(t *testing.T) {
C.myfunc()
C.myfunc_def()
if v := C.myvar; v != 5 {
t.Errorf("C.myvar = %d, want 5", v)
}
if v := C.myvar_def; v != 5 {
t.Errorf("C.myvar_def = %d, want 5", v)
}
if s := C.GoString(C.mytext); s != "abcdef" {
t.Errorf("C.mytext = %q, want %q", s, "abcdef")
}
if s := C.GoString(C.mytext_def); s != "abcdef" {
t.Errorf("C.mytext_def = %q, want %q", s, "abcdef")
}
if c := C.myenum; c != 1234 {
t.Errorf("C.myenum = %v, want 1234", c)
}
if c := C.myenum_def; c != 1234 {
t.Errorf("C.myenum_def = %v, want 1234", c)
}
{
const c = C.myenum
if c != 1234 {
t.Errorf("C.myenum as const = %v, want 1234", c)
}
}
{
const c = C.myenum_def
if c != 1234 {
t.Errorf("C.myenum as const = %v, want 1234", c)
}
}
if c := C.myint_def; c != 12345 {
t.Errorf("C.myint_def = %v, want 12345", c)
}
{
const c = C.myint_def
if c != 12345 {
t.Errorf("C.myint as const = %v, want 12345", c)
}
}
// This would be nice, but it has never worked.
/*
if c := C.myfloat_def; c != 1.5 {
t.Errorf("C.myint_def = %v, want 1.5", c)
}
{
const c = C.myfloat_def
if c != 1.5 {
t.Errorf("C.myint as const = %v, want 1.5", c)
}
}
*/
if s := C.mystring_def; s != "hello" {
t.Errorf("C.mystring_def = %q, want %q", s, "hello")
}
}
...@@ -269,29 +269,30 @@ Next, cgo needs to identify the kinds for each identifier. For the ...@@ -269,29 +269,30 @@ Next, cgo needs to identify the kinds for each identifier. For the
identifiers C.foo and C.bar, cgo generates this C program: identifiers C.foo and C.bar, cgo generates this C program:
<preamble> <preamble>
void __cgo__f__(void) { #line 1 "not-declared"
#line 1 "cgo-test" void __cgo_f_xxx_1(void) { typeof(foo) *__cgo_undefined__; }
foo; #line 1 "not-type"
enum { _cgo_enum_0 = foo }; void __cgo_f_xxx_2(void) { foo *__cgo_undefined__; }
bar; #line 1 "not-const"
enum { _cgo_enum_1 = bar }; void __cgo_f_xxx_3(void) { enum { __cgo_undefined__ = (foo)*1 }; }
} #line 2 "not-declared"
void __cgo_f_xxx_1(void) { typeof(bar) *__cgo_undefined__; }
This program will not compile, but cgo can look at the error messages #line 2 "not-type"
to infer the kind of each identifier. The line number given in the void __cgo_f_xxx_2(void) { bar *__cgo_undefined__; }
error tells cgo which identifier is involved. #line 2 "not-const"
void __cgo_f_xxx_3(void) { enum { __cgo_undefined__ = (bar)*1 }; }
An error like "unexpected type name" or "useless type name in empty
declaration" or "declaration does not declare anything" tells cgo that This program will not compile, but cgo can use the presence or absence
the identifier is a type. of an error message on a given line to deduce the information it
needs. The program is syntactically valid regardless of whether each
An error like "statement with no effect" or "expression result unused" name is a type or an ordinary identifier, so there will be no syntax
tells cgo that the identifier is not a type, but not whether it is a errors that might stop parsing early.
constant, function, or global variable.
An error on not-declared:1 indicates that foo is undeclared.
An error like "not an integer constant" tells cgo that the identifier An error on not-type:1 indicates that foo is not a type (if declared at all, it is an identifier).
is not a constant. If it is also not a type, it must be a function or An error on not-const:1 indicates that foo is not an integer constant.
global variable. For now, those can be treated the same.
The line number specifies the name involved. In the example, 1 is foo and 2 is bar.
Next, cgo must learn the details of each type, variable, function, or Next, cgo must learn the details of each type, variable, function, or
constant. It can do this by reading object files. If cgo has decided constant. It can do this by reading object files. If cgo has decided
......
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment