CL 49530047 made the (over-)simplifying assumption that the
Path of an ad-hoc (Created) package should default to its
Name, i.e. package declaration.
With this change, the Name is still always computed from the
package declaration (by go/types) but the Path may be
specified by the loader.Config. If "", the value of the Name
is used, which is not globally unique.
R=gri, axwalk
CC=golang-codereviews
https://golang.org/cl/55180043
Was: Now:
call.Graph callgraph.Graph
call.GraphNode callgraph.Node
call.Edge callgraph.Edge
Though call.Graph was cute, the original naming was a mistake:
'call' is too useful a var name to waste on a package.
R=gri, crawshaw
CC=golang-codereviews
https://golang.org/cl/53190043
The goal is to allow clients to distinguish function-local objects
from package-local objects and identify the specific function by
examining its scope. For example, a compiler may need to mangle
object names according to the outer function name.
R=gri
CC=golang-codereviews, golang-dev
https://golang.org/cl/52280043
Both gc and gccgo appear to use this size, so it seems appropriate
to use it here.
R=gri
CC=golang-codereviews, golang-dev, iant, rsc
https://golang.org/cl/52290043
The issue is addressed with the change in conversions.go.
Also:
- added corresponding API test
- made names for untyped ints, bools consistent with others
- use *Basic with names byte/rune instead of uint8/int32 for better output
- minor cleanups
Fixesgolang/go#6949.
R=adonovan
CC=golang-codereviews
https://golang.org/cl/50520043
Now that inner functions are processed "in line", usage errors
can be detected immediately after each function is processed.
R=adonovan
CC=golang-codereviews
https://golang.org/cl/49900044
Inner function bodies must be type-checked "in-place" for
them to see the correct state of the surrounding scopes.
Fixesgolang/go#7035.
R=adonovan
CC=golang-codereviews
https://golang.org/cl/49350043
This can import all of the standard library, and has been tested
by using gotype to type check libgo with gccgo's export data (this
would be nice to automate, but I can't see a good way to do it,
not least because system-specific source files cause errors which
I needed to identify manually).
It includes a builtin export locator. Unfortunately I can't see a
more reliable way to locate the builtin export files than to parse
the output of 'gccgo -###'.
R=gri, iant, gri
CC=golang-codereviews, golang-dev
https://golang.org/cl/31860043
- if a named type was imported before, read it again
and throw it away in favor of the existing type
(the old code did the same, but more circuitously)
- better tag name for int64 values
R=adonovan
CC=golang-codereviews
https://golang.org/cl/47650044
Anonymous field names are emitted as "" in the export data
since the actual name can be reconstructed easily from the
field's type name. But "" names are not exported names and
thus the respective qualified name emits complete package
information even if the actual field name is exported. Fix
the package upon import.
R=adonovan
CC=golang-codereviews
https://golang.org/cl/42090044
The package of a struct field is independent of the type of the
struct field - the old code was technically not correct. That said,
it does not seem possible (or very difficult) to create a test case
because for exported anonymous fields that field package doesn't matter
(it's not needed for name identity), and non-exported anonymous fields
cannot be accessed from an imported package.
R=adonovan
CC=golang-codereviews
https://golang.org/cl/47560043
Also: Provide GcCompatibilityMode for printing types
(intended for testing with gc-generated export data
only).
(TBR adonovan)
R=adonovan
TBR=adonovan
CC=golang-codereviews
https://golang.org/cl/44780043
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
Alan Donovan
Robert Griesemer
Peter Collingbourne