Comment 1:

Hello,
Could you please attach the exact file that was changed/added that caused this error.
Cheers
Dave

Status changed to WaitingForReply.

Comment 2:

i think add an untyped exported symbol to any non-test file in src/pkg with initial
value of false will trigger this.
(e.g. `var VariableName = false`)
this issue will be fixed when cmd/api make use of go/types to do proper type checking.
For now, the following patch could temporarily fix this issue, but as this issue doesn't
affect the official build,
i'm inclined to leave this as is, and wait until go/types is ready.
diff -r e61b6119272b src/cmd/api/goapi.go
--- a/src/cmd/api/goapi.go  Thu Dec 13 19:08:51 2012 +0800
+++ b/src/cmd/api/goapi.go  Thu Dec 13 20:28:50 2012 +0800
@@ -558,6 +558,11 @@
    token.IMAG:   "complex128",
 }
 
+var predeclaredType = map[string]string{
+   "true":  "bool",
+   "false": "bool",
+}
+
 var errTODO = errors.New("TODO")
 
 func (w *Walker) constValueType(vi interface{}) (string, error) {
@@ -671,7 +676,11 @@
    case *ast.Ident:
        node, _, ok := w.resolveName(v.Name)
        if !ok {
-           return "", fmt.Errorf("unresolved identifier: %q", v.Name)
+           typ, ok := predeclaredType[v.Name]
+           if !ok {
+               return "", fmt.Errorf("unresolved identifier: %q", v.Name)
+           }
+           return typ, nil
        }
        return w.varValueType(node)
    case *ast.BinaryExpr:

Comment 3 by zhaihj233:

Just as minux said, when I use a untyped exported symbol, this error occurs.
like
var (
    Threshold = 0.001
    Variance  = 0.8
    KMeansPP  = false
)
and there is a same question in go-sqlite
http://code.google.com/p/gosqlite/issues/detail?id=20
    Row            = Errno(100) //   /* sqlite3_step() has another row ready */
    Done           = Errno(101) //   /* sqlite3_step() has finished executing */
//this will cause api check error
    Row           error = Errno(100) //   /* sqlite3_step() has another row ready */
    Done          error = Errno(101) //   /* sqlite3_step() has finished executing */
//no problem

Comment 4:

Once Robert's type checker (exp/types, which is becoming go/types) is in, we can just
use that, and ditch cmd/api's crappy type checker.
I'd rather not spend too much effort on goapi until then.

Comment 5:

Labels changed: added priority-later, removed priority-triage.

Comment 6:

Status changed to Accepted.

Comment 7:

I think we're at a point where the transition is fairly easy now. Call types.Check with
the files belonging to the package and you get back a types.Package containing a
types.Scope with all top-level objects. The set of the exported objects simply needs to
be compared against the original set for this packages.

Comment 8:

Labels changed: added go1.1maybe, removed go1.1.

Comment 9:

Labels changed: added suggested.

Comment 10:

Even though this sounds fun, I probably won't have time to work on this before Go 1.1.
Anybody else interested? Robert and I could review.

Comment 11:

Caveat: There's a showstopper at the moment, and that's the fact that a small handfull
of std libs are not fully type checked yet due to errors in shift type checking which
are (still) not fixed (i.e., I spoke too early on Jan 14). I am planning to look into
this as the next thing. Once the entire std lib checks fine, the transition should be
possible.

Comment 13:

Labels changed: removed go1.1maybe.

Comment 14:

Is this plausible for Go 1.2?

Labels changed: added go1.2maybe.

Comment 15:

It should be possible. I'll have a look.

Comment 16:

Owner changed to @griesemer.

Status changed to Started.

Comment 17:

This is done but for the necessary updates to the build scripts (in bradfitz's court
now).
https://golang.org/cl/12300043

Comment 18:

This issue was closed by revision 9449c18.

Status changed to Fixed.