Since Put() makes a dynamic function call, this CL includes a long-overdue change to supply a *frame (and thus the call
stack and the interpreter) to intrinsics too.
This fixes the tests that were broken by (sound) revision e4a4cb47c141.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/57350043
Fast path for the common case. Avoids scanning GOPATH usually.
LGTM=r, crawshaw
R=david.crawshaw, adg, r, crawshaw
CC=golang-codereviews
https://golang.org/cl/56820043
Only send mail to golang-dev if updating the CL fails.
R=golang-codereviews, dvyukov, minux.ma, rsc
CC=golang-codereviews
https://golang.org/cl/43760043
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 Importer type has been replaced with Config and Program.
Clients populate a Config, directly or more usually via
convenience functions. They then call its Load() method to do
all of the typechecking and transitive-closure computation.
ssa.NewProgram and ssa.CreatePackages have been fused into
ssa.Create, which now cannot fail, since (*Config).Load()
reports all type errors.
Also:
- The addition of an ssa.GlobalDebug builder mode flag
eliminates a loop-over-packages repeated in many clients.
- PackageInfo.Err flag unexported. Clients never see bad infos now.
- cmd/ssadump: now only looks for func "main" in package "main".
- importsOf deleted, was dead code.
STILL TODO:
- ParseFile seems like API creep (though it's convenient)
and CreateFromFiles is dangerous (w.r.t. FileSet identity).
Need to think more...
- the need for clients to rely on elementwise correspondence
of Config.CreatePkgs and Program.Created is a little sad.
- The command-line interface has not changed.
That will happen in a follow-up.
r recommends using a repeated flag: -package p -package q ...
R=gri
CC=axwalk, frederik.zipp, golang-codereviews
https://golang.org/cl/49530047
- Add missing import.
- platform-specific files syswrite() wrapper presents
standard API to syscall.Write, even on Windows where
first arg is a Handle.
Fixesgolang/go#7100
R=gri, minux.ma, alex.brainman
CC=golang-codereviews
https://golang.org/cl/52250043
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
go/types no longer reports a constant value for a slice,
e.g. []byte("foo").
ssa.Const no longer support slice constants, only
bool/string/numeric and nil.
emitConv emits a Convert instruction for string->[]byte
conversions.
Added regression test for bug 6949.
R=gri
CC=golang-codereviews
https://golang.org/cl/50590043
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
Tested: by enabling debug info globally in stdlib_test,
the existing sanity checks catch it.
R=gri
CC=golang-codereviews
https://golang.org/cl/50570043
Packages were not being created for all types.Packages,
specifically, indirectly imported packages were missing.
(*Program).CreatePackages now iterates over the type-checker's
package map too.
Also: removed all concurrency from importer. I think it was
incorrect (and hard to fix).
Also: change LoadInitialPackages so that all named packages
are loaded from source. This happens regardless of whether
GCImporter is used to satisfy imports.
Details:
- importer.Config.SourceImports flag determines whether to
load all packages from *.go source.
(Before, this was indicated by Config.Build != nil.)
- importer.Config.Build field effectively defaults to
&go/build.Default. A zero importer.Config is now usable.
- importer.Importer.Config field is now exported.
- LoadPackage renamed to ImportPackage since the resulting
packages may come from GCImporter (and be incomplete).
- doImport and ImportPackage fused.
Fixesgolang/go#7028
R=gri, axwalk
CC=golang-codereviews
https://golang.org/cl/48770043
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
Also report an error for "cross-interpretation": not supported
due to the interpreter's assumption that host and target
{int,uint,uintptr} are the same. (Too tedious and messy to fix.)
Tested manually:
% cat d.go
package main
const m = ^uintptr(0)
const w = m>>8&1 + m>>16&1 + m>>32&1
func main() { println(m, w) }
% ./ssadump -build=P -run d.go
package main:
const m m = 18446744073709551615:uintptr
const w w = 3:uintptr
18446744073709551615 3
% GOARCH=386 ./ssadump -build=P -run d.go
package main:
const m m = 4294967295:uintptr
const w w = 2:uintptr
Error: Cross-interpretation is not yet supported (target has GOARCH 386, interpreter has amd64).
Fixesgolang/go#7080
R=gri
CC=golang-codereviews
https://golang.org/cl/49070043
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
(*CallCommon).Signature() now returns non-nil even for
built-ins. Builtins are now created with specialized types for
each use. Added sanity-check.
CallCommon.HasEllipsis field eliminated. It was an incorrect
memoization of Signature().IsVariadic() used only for
printing.
Also: introduce and use newTypeVar utility.
R=gri
CC=golang-codereviews
https://golang.org/cl/46880044
This allows us to show package synopsis in search results.
Fix skipping of test files (prefix changed from "test/" to "/test/").
R=bradfitz, bradfitz
CC=golang-codereviews
https://golang.org/cl/44790044
The display of search results can now be changed. A slice of functions for displaying the results can now be provided. By default, three functions are provided to display documentation, source code, and textual results.
This makes it possible to replace them with equivalents that, say,
obtain search results from alternative source code search engines.
R=bradfitz, adg
CC=golang-codereviews
https://golang.org/cl/43470043
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
