These nodes are common in incomplete programs.
Change-Id: Iff9750050c78762f0cb8bebc7739584c197d661e
Reviewed-on: https://go-review.googlesource.com/19509
Reviewed-by: Michael Matloob <matloob@golang.org>
This is a backport of the respective changes in golang.org/cl/19393.
For golang/go#14215.
Change-Id: I8d60dd6daa827a60597f3af925e6732914537319
Reviewed-on: https://go-review.googlesource.com/19394
Reviewed-by: Alan Donovan <adonovan@google.com>
For the default build.Context, the Package.Goroot flag indicates when a
package was loaded from the standard library. Until now, the loader
used it to enable the typechecker's intrinsics for the "unsafe" package.
This seemed like a good check, but it is troublesome for clients that
use a nonstandard build.Context. For example, if a client defines
nonstandard Context hooks that load all packages, whether standard or
user-defined, from a flat sstable, there is no way for those hooks to
indicate which packages should have this flag set and which not. As a
result the contents of the "unsafe" package directory are treated as Go
source code when they are merely documentation.
Change-Id: Iea0a7cc9877507d73606391293971a28279c4e4b
Reviewed-on: https://go-review.googlesource.com/19188
Reviewed-by: Robert Griesemer <gri@golang.org>
This change prevents test code to slip into package gcimporter15 and
fixes a weird situation that the test passes but the package doesn't
exist.
For example, we can see the situation with Go 1.6 like the follwoing:
go build
./gcimporter_test16.go:20: undefined: MustHaveGoBuild
./gcimporter_test16.go:45: undefined: testPath
go test
PASS
ok golang.org/x/tools/go/gcimporter15 0.896s
Change-Id: I95550574ccd1b2273072c700c28a82c791c16c63
Reviewed-on: https://go-review.googlesource.com/18950
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The hosting service was shut down on January 25, 2016 and a few tests
started to fail like the following:
=== RUN TestRepoRootForImportPath
--- FAIL: TestRepoRootForImportPath (2.47s)
vcs_test.go:129: RepoRootForImport("code.google.com/p/go"):
unable to detect version control system for code.google.com/ path
FAIL
This change drops support for code.google.com and fixes test. See
http://google-opensource.blogspot.jp/2015/03/farewell-to-google-code.html
for further information.
Fixesgolang/go#14105
Change-Id: I87cb9a3d666c2a1af0f8bf39a66ba0f669c99fd5
Reviewed-on: https://go-review.googlesource.com/18951
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Also: rename setname15.go to setname.go for consistency
Change-Id: I3f7e37ef4ade716ce64674edb4d53a543a1150c5
Reviewed-on: https://go-review.googlesource.com/18772
Reviewed-by: Alan Donovan <adonovan@google.com>
This makes gcimporter15 build against Go 1.5.
Change-Id: I14e7ff80b28d99f996abc19a0a74b08e5e1bbd75
Reviewed-on: https://go-review.googlesource.com/18771
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Import path is a '/'-separated path. FromDir documentation says
on return, root is the import path corresponding to the root of
the repository. On Windows and other OSes where os.PathSeparator
is not '/', that wasn't true since root would contain characters
other than '/', and therefore it wasn't a valid import path
corresponding to the root of the repository. Fix that by using
filepath.ToSlash.
Add test coverage for root value returned from FromDir, it was
previously not tested.
Additionally, remove a dubious statement from the documentation
"(thus root is a prefix of importPath)". There is no variable
importPath that is being referred to. It's also redundant and
confusing. Without it, the description of root value matches
the documentation of RepoRoot.Root struct field:
// Root is the import path corresponding to the root of the
// repository.
Root string
Fixesgolang/go#7723.
Change-Id: If9f5f55b5751e01a7f88b79d9b039402af3e9312
Reviewed-on: https://go-review.googlesource.com/18461
Reviewed-by: Chris Manghane <cmang@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
...by making the cache non-blocking and duplicate-suppressing.
(The bottleneck was introduced while adding vendoring support.)
This reduces the 95th percentile map shard time for type-checking 120K
packages to 8min from 20min.
Also: move the I/O-limiting counting semaphore and the NoGoError check
from FindPackage to findPackage so that all implementations benefit.
Change-Id: I43527122262cf80475dd3212d78c340e1c71e36c
Reviewed-on: https://go-review.googlesource.com/18580
Reviewed-by: Robert Griesemer <gri@golang.org>
The loader treats GOROOT's "unsafe" package specially,
with no source files and a Package of types.Unsafe.
Tested on Go 1.4.1, 1.5, and ~1.6 (tip).
Fixes issue #13882
Change-Id: I86c4e394665d86a50ec3852d6d702f0e9c5d2276
Reviewed-on: https://go-review.googlesource.com/18457
Reviewed-by: Robert Griesemer <gri@golang.org>
(late response to comment in review of CL 18452)
Change-Id: I1fa80fd1c7fd22cec752c839d20a483e0732337c
Reviewed-on: https://go-review.googlesource.com/18454
Reviewed-by: Alan Donovan <adonovan@google.com>
(See https://go-review.googlesource.com/#/c/18450)
Details:
- delete buildutil.AllowVendor flag.
Instead use unexported 'go16' var in each package that needs it.
- delete buildutil.StripVendor; was never needed.
- remove inapplicable vendoring comments from loader14.go
- importgraph: go1.5: don't bother checking for 1.6 before calling
absolutize (minor simplifiication and deoptimization).
Tested on 1.4.1, 1.5, and ~1.6 (tip).
Change-Id: If692b0df2eb6c120a9c09d7b1ed99f1b4c6b0826
Reviewed-on: https://go-review.googlesource.com/18452
Reviewed-by: Russ Cox <rsc@golang.org>
Because the std go/importer's Lookup functionality is incomplete,
clients have no way to create a Go 1.5 types.Package from an io.Reader
reading from gc export data. This package provides a stopgap until
the standard library is complete.
The go/gcimporter package remains unchanged, and uses only the
golang.org/x/tools/go/types package.
Change-Id: I47a817f4b6a52ddab26c6b01de6e28099301faf5
Reviewed-on: https://go-review.googlesource.com/18382
Reviewed-by: Robert Griesemer <gri@golang.org>
A few files have been forked and tagged "go1.5,!go1.6" to work around
minor API changes between the two types packages:
- constant.Value.String() in oracle/describe.go and its tests;
- constant.ToInt must now be called before constant.Int64Val.
- types.Config{Importer: importer.Default()} in a number of places
- go/types/typeutil/import_test.go uses lowercase names to avoid 'import "C"'.
Files in go/types/typesutil, missing from my previous CL, have been
tagged !go1.5; these files will be deleted in February.
All affected packages were tested using 1.4.1, 1.5, and ~1.6 (tip).
Change-Id: Iec7fd370e1434508149b378438fb37f65b8d2ba8
Reviewed-on: https://go-review.googlesource.com/18207
Reviewed-by: Robert Griesemer <gri@golang.org>
This change will ensure that the tree continues to work with go1.4.1.
All files continue to depend on golang.org/x/tools/go/types, but in a
follow-up change, I will switch the primary files to depend on the
standard go/types package. Another (smaller) set of files will be
forked and tagged, this time !1.6, due to API differences between the
two packages.
All tests pass using 1.4.1, 1.5, and ~1.6 (tip).
Change-Id: Ifd75a6330e120957d646be91693daaba1ce0e8c9
Reviewed-on: https://go-review.googlesource.com/18333
Reviewed-by: Robert Griesemer <gri@golang.org>
Packages specified on the command line should be interpreted relative to
cwd iff they are local (e.g. ./http within $GOROOT/src/net), otherwise a
request for, say, "golang.org/x/net/http2/hpack" might return the vendored
package depending on the working directory.
The FindPackage hook function now takes a build.ImportMode parameter, so
it matches the signature of (*build.Context).Import. The AllowVendor
flag is enabled only for imports within source files, but not for the
initial packages.
+ test.
Change-Id: I756dc46b70928d2fd9f824e6670092d8169e0d64
Reviewed-on: https://go-review.googlesource.com/18318
Reviewed-by: Robert Griesemer <gri@golang.org>
Use an concurrency-limiting semaphore to reduce I/O parallelism in Import.
Also, start the producer in a new goroutine so that it runs in parallel
with the consumer. Paradoxically, this reduces the peak number of
goroutines.
Also, in buildutil.ForEachPackage, make the concurrency limiting
semaphore global, since I/O parallelism is a process-wide resource.
Change-Id: I282b717c50603361826e5675077c9f464c874132
Reviewed-on: https://go-review.googlesource.com/18215
Reviewed-by: Michael Matloob <matloob@golang.org>
...using same logic as in $GOROOT/go/src/cmd/go/discovery.go
See issue #13757
Change-Id: I2ace0abed0743f4a8675fa8780e190d640b57e6c
Reviewed-on: https://go-review.googlesource.com/18196
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We need a better approach for tests such as these.
Change-Id: I6fb608acc096088fe377f6f2c40ff6124cf3d09c
Reviewed-on: https://go-review.googlesource.com/18194
Reviewed-by: Alan Donovan <adonovan@google.com>
1. Added intrinsic for os.Pipe to avoid use of "unsafe". This makes
Example tests work in the interpreter, fixing the broken "unicode"
package (which recently sprouted some Examples) and allowing us to
enable tests for:
encoding/csv
flag
path
text/scanner
unicode/utf8
The implementation of os.Pipe may require tweaking for non-Linux platforms.
2. Added intrinsic for strings.Index to avoid assembly dependency.
3. Added dumb intrinsic for testing۰runExample to work around a bug in
go/ssa/testmain.go that requires an invasive fix
(Until then, the output of Example functions will not be checked.)
Change-Id: I6374c9c47aa802275b7cdc98525e057f5db0615a
Reviewed-on: https://go-review.googlesource.com/18191
Reviewed-by: Alan Donovan <adonovan@google.com>
(gcimporter does not support vendoring---see issue #13756)
Change-Id: Ief4101e4f33007d497ed1519845febfcffdded38
Reviewed-on: https://go-review.googlesource.com/18193
Reviewed-by: Alan Donovan <adonovan@google.com>
Prior to this change, the loader made the simplifying assumption
that an import path is equal to a package path, that is, a
subdirectory of src/. (This assumption was already false because
relative imports "../foo" are possible, though discouraged.)
Now, an import "foo" may denote "a/vendor/foo" or "b/vendor/foo"
depending on whether it appears beneath a/ or b/. Thus import
paths and package paths are no longer the same, and the directory
containing an import declaration is a necessary input to the
import resolution function.
This change makes the loader hygienic w.r.t. the directory of
each import declaration, and cleans up the terminology.
The only API change is to the FindPackage hook, which most
clients never use.
Details:
- Add a 'fromDir string' parameter to the FindPackage hook function.
- Add a dir field to each PackageInfo.
- doImport (called by go/types) now consists of two steps:
use FindPackage(dir, importPath) to locate the package,
then consult the import map using the canonical package path.
Only the first step can fail.
- Memoize FindPackage.
- Simplify importInfo now that it no longer has to deal with errors.
Replace a condition variable with a channel.
- Use a separate type to report importErrors.
- Rename loadAll to importAll
- Delete the importMode constant.
- Test.
Change-Id: I3defab51bfa12b48b1511a2172fb48dc8e9150e6
Reviewed-on: https://go-review.googlesource.com/18053
Reviewed-by: Robert Griesemer <gri@golang.org>
Makes programs like ssadump work on packages using vendored code,
for example net/http.
For golang/go#12278.
Depends on CL 17726 in main repository.
Change-Id: Ibabf564e397044a0f449087124dd96161081baaf
Reviewed-on: https://go-review.googlesource.com/17727
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Since Go 1.5, if a key expression in a map literal is itself a composite
literal, the type may be omitted. An & operation may be implied,
but was not generated, resulting in a type mismatch crash.
Added regression test.
Also, added missing intrinsic math.hasSSE4 to interpreter.
Fixes issue 13341
Change-Id: I6a5e560460cdcac295a500a3fc3738cbe8aa5853
Reviewed-on: https://go-review.googlesource.com/17123
Reviewed-by: Robert Griesemer <gri@golang.org>
The example incorrectly used buildutil.TagsDoc identifier which does not
exist. It should be buildutil.TagsFlagDoc instead.
The issue was introduced in https://golang.org/cl/9172 when this code was
first written.
Also use more idiomatic style for Go comments, '//' followed by a space,
then tab (instead of skipping the space). Although both render correctly
in godoc, this form is more correct and consistent.
Change-Id: I3b3c9767fe313106a8ff81e7887f3241c5806b59
Reviewed-on: https://go-review.googlesource.com/16743
Reviewed-by: Alan Donovan <adonovan@google.com>
This would cause oracle callee lookup failures when the RHS is an
invoke-style call.
Fixesgolang/go#12999
Change-Id: Ifd561c4e7bf26f57ace5f62afac746b926c70993
Reviewed-on: https://go-review.googlesource.com/16210
Reviewed-by: Alan Donovan <adonovan@google.com>
This adds a missing memory barrier at the end of Package.Build.
Change-Id: Ife35d5ad5a48ba121f35656fef682863d4f2aef6
Reviewed-on: https://go-review.googlesource.com/14761
Reviewed-by: Robert Griesemer <gri@golang.org>
until vendoring support is added (soon).
Change-Id: I954514b5c6b82622c0c831a289ccdcc16dbd37f8
Reviewed-on: https://go-review.googlesource.com/14130
Reviewed-by: Alan Donovan <adonovan@google.com>
Alan Donovan
Robert Griesemer
Alan Donovan
Brad Fitzpatrick
Mikio Hara
Dmitri Shuralyov
Kenji Kaneda
Russ Cox
David Symonds
Alex Brainman
Daniel Morsing