By using a simple (graph-based) serialization algorithm
and binary encoding, a significantly more compact export
data format is achieved than what the current compilers
use. Furthermore, the exporter and importer are completely
symmetric algorithms that are compact, and much easier to
change/expand.
R=adonovan
CC=golang-dev
https://golang.org/cl/42960043
Obviously in that mode, we can't correctly diagnose such
errors, so we shouldn't attempt it (and emit false positives).
R=gri
CC=golang-dev
https://golang.org/cl/41080043
This test generates a program that declares the constant
elements of an n*n Hilbert matrix, its inverse, and the
constant elements of the explicit product of the two.
The product should be the identity matrix; that check is
also expressed as a constant expression. Type-checking
verifies that the product is indeed the identity matrix
by asserting the result of the identity check (using the
assert built-in which is available for type-check tests).
The test is run for n = 5. Other values can be tested via
the -H flag, say: go test -run=Hilbert -H=100
The generated program can be written to a file for testing
the constant arithmetic of a compiler: go test -out=test.go
Because of the mathematically precise constant arithmetic
of go/types, this test should always succeed and is only
limited by the size of the matrix. It does run successfully
from n = 0 to values larger than 100.
The Hilbert matrix is famous for being ill-conditioned and
thus exposes arithmetic imprecision very quickly. The gc
compiler only produces a correct result for n = 0 (trivially),
and n = 1 at the moment.
R=adonovan, rsc
CC=golang-dev
https://golang.org/cl/35840043
The benchmarks don't permit clear-cut apples-to-apples
comparisons since they depend on the very source code
they are testing. But they do give an indication of
the approximate performance - as a sanity test.
Using 3 different code bases makes it apparent that
there's some difference in performance per code base;
i.e., the lines/s speed varies pretty strongly. This
may be due to setup costs, or other issues. We should
investigate eventually.
R=adonovan
CC=golang-dev
https://golang.org/cl/30650043
Also: Use defer to make sure scopes are always closed
even in case of early exits via bailout (and don't cause
an imbalanced scope error in debug mode).
R=adonovan, gri
CC=golang-dev
https://golang.org/cl/29300043
- consolidate them in (expr|type)string[_test].go
- support for printing all ast.Expr
- fix printing of type: chan (<-chan int) (parentheses)
- more consistent names, comments, and exports
R=adonovan
CC=golang-dev
https://golang.org/cl/28680043
These are variants of Type.String(), Object.String() that
accept a 'from *Package' argument. If provided, package
qualification is omitted when printing named types belonging
to that package.
This is useful for UIs where a package is implied by context
e.g. ssadump disassembly, oracle output.
+ Test.
R=gri, gri, gordon.klaus
CC=golang-dev
https://golang.org/cl/22190048
- fixed a couple of TODOs
- various cleanups along the way
- adjusted clients
Once submitted, clients of go/types that don't explicitly
specify Config.Import will need to add the extra import:
import _ "code.google.com/p/go.tools/go/gcimporter"
to install the default (gc) importer in go/types.
R=adonovan, gri
CC=golang-dev
https://golang.org/cl/26390043
Depending on the context, printing only the package name can
be ambiguous or even incorrect since it is valid only within
the environment of a given file's import specs.
(The standard library packages are mostly unique in their last
segment, but this is not the case for proprietary repos.)
R=gri, gri
CC=golang-dev
https://golang.org/cl/26300043
This check is currently done in go/parser as well but
eventually can be removed from there (after Go 1.2).
R=adonovan
CC=golang-dev
https://golang.org/cl/22240045
Initialization cycles need to reported for cycles
that contain variables, even if they don't end in
a variable.
This fixes the last known issue with the existing
std library tests.
R=adonovan, gri
CC=golang-dev
https://golang.org/cl/22200049
The gc compiler is inconsistent how it handles method
"mentions" with respect to initialization cycle detection
(see issue 6703 for details). Pending a spec clarification,
this CL assumes that for a method to be "mentioned", it
must be mentioned as a method expression rather than a
method value (closer in intent to "syntactic" mention).
R=adonovan
CC=golang-dev
https://golang.org/cl/22050044
- Info.InitOrder now provides list of Initializers
(vars + init expr), handling n:1 decls and blank
identifiers
- added respective API test
- cycles detected through function "mentions"
Missing: cycles through method "mentions" and via
closures
R=adonovan
CC=golang-dev
https://golang.org/cl/21810043
Robert Griesemer
Alan Donovan
Peter Collingbourne
Richard Musiol