It is sometimes useful for API clients to be able to disable the unused
import check, although for good reason this should not be exposed as part of
a user-facing interface. There are at least two use cases that I am aware of:
1) It allows for automated test case reduction tools such as delta or C-Reduce
to be more easily applied to type checker input. Disabling the check
makes it possible for the tool to identify and remove code that depends
on imported packages without any specific knowledge of Go, as the import
need not be removed simultaneously with the code.
2) Interactive tools (such as REPLs) that may have previously received a
list of imports and subsequently receive a line of code that may use any
number of these imports. It is simpler for such tools to import all the
packages in its list than to try to identify the correct set of imports.
Change-Id: I00091a4e5c8e1bd664efd82a636f255eaaa5a2db
Reviewed-on: https://go-review.googlesource.com/2136
Reviewed-by: Robert Griesemer <gri@golang.org>
The new interface makes the functions more useful by allowing clients to
check the various properties that TypeAndValue provides.
Change-Id: I8b41a27316081bea24a18ffe6fa1812e809d6f67
Reviewed-on: https://go-review.googlesource.com/2134
Reviewed-by: Robert Griesemer <gri@golang.org>
+ Tests:
Extend function name uniqueness check to exported wrappers.
Check that expected synthetic functions are created, reachable, and not duplicated.
Change-Id: I0e87ebb2712e33e1f49da3fa9a9dde0085bf3850
Reviewed-on: https://go-review.googlesource.com/2013
Reviewed-by: Robert Griesemer <gri@golang.org>
+ test
Change-Id: Ie37835577ffcdd764cf6a0b611e02f04386755cf
Reviewed-on: https://go-review.googlesource.com/1580
Reviewed-by: Robert Griesemer <gri@golang.org>
...like we do for "runtime" functions, so that they fail informatively
if executed. They all need intrinsics, but only some are yet defined.
Also:
- added test for issue 9462
- "BUG" in test output is now a failure in all tests (not just $GOROOT tests)
- added intrinsic for reflect.SliceOf
- show dynamic type of panic value
Fixes issue 9462
Change-Id: I3a504c7faeed81e922fedc7dd59222717f3a7e95
Reviewed-on: https://go-review.googlesource.com/2145
Reviewed-by: Robert Griesemer <gri@golang.org>
Fixes various problems reported by go vet.
Change-Id: I12a6fdba8f911b21805d8e42903f8f6a5033790a
Reviewed-on: https://go-review.googlesource.com/2163
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
"static" ignores dynamic calls altogether.
"cha" uses Class Hierarchy Analysis, which assumes that a
dynamic call may dispatch to any func or method that satisfies
the type.
Both these algorithms can work on partial programs,
e.g. libraries without a main function or tests.
(This feature was requested after my talk last night.)
+ Tests.
LGTM=sameer
R=sameer, minux
CC=golang-codereviews, gri
https://golang.org/cl/176780043
Also use type assertions in a more defensive
way (check for != nil rather than ok).
LGTM=dsymonds, adonovan
R=adonovan, dsymonds
CC=golang-codereviews
https://golang.org/cl/169480043
This is an algorithm for callgraph construction that is faster
but much less precise than pointer analysis.
(I evaluated this for the Go Oracle last year but shelved it,
but it's a natural fit for the work Brian is doing on
automatic program minimization.)
LGTM=sameer
R=gri, crawshaw, sameer
CC=bwkster, golang-codereviews
https://golang.org/cl/124690043
Rewrite performed with this command:
sed -i '' 's_code.google.com/p/go\._golang.org/x/_g' \
$(grep -lr 'code.google.com/p/go.' *)
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/170920043
See regression test for explanation.
I audited the code for similar issues and found none.
Many thanks to Daniel Morsing for providing a small
reproducible test case, a rarity for PTA bugs!
Fixesgolang/go#9002
LGTM=crawshaw
R=crawshaw
CC=daniel.morsing, golang-codereviews
https://golang.org/cl/163350043
Also removes a potential race condition regarding the
used flag of Var objects when type-checking packages
concurrently.
Implementation: Rather than marking all used dot-imported
objects and then deduce which corresponding package was used,
now we consider all dot-imported packages as unused and remove
each package from the unused packages map as objects are used.
Now only objects that can be marked as used have a used field
(variables, labels, and packages).
As a result, the code became cleaner and simpler.
Fixesgolang/go#8969.
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/163740043
The previous logic would descend into (e.g.) .git repositories
and vendored packages with "_"-prefixed names.
Fixesgolang/go#8907
LGTM=gri
R=gri
CC=golang-codereviews, shurcool
https://golang.org/cl/157800043
The type-checker depended on (token.Pos) position information of
the presented files to determine source order. That information
is determined by the parse order of the files rather than the
order in which the files are presented to the type-checker.
Introduced an order number strictly determined by the file
order as presented to the type-checker and the AST structure
of each file; thus providing source order information even in
the absence of (token.Pos) position information.
Added test case (provided by adonovan).
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/151160043
- ParseFile (core of go/loader's parseFiles(); also used by refactor/rename)
- ContainingPackage (core of Oracle's guessImportPath; also used by refactor/rename)
- Accessors for effective "methods" of build.Context:
FileExists, OpenFile, IsAbsPath, JoinPath.
LGTM=sameer
R=dave, sameer
CC=golang-codereviews, gri
https://golang.org/cl/146120043
The needMethods cache logic was wrong: it would treat any
previous call as a cache hit, even if 'skip' was true for that
call. As a result it could fail to generate methods for some
'skip' types, i.e. anonymous structs.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/144750043
This CL is the first refactoring automated by "gorename". :)
Though I had to update the comments and run 'hg gofmt'. :(
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/142930043
It now has a main() function, which was confusing the logic to find the entry point.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/142860044
This function has been copied at least 6 times throughout
go.tools. This implementation is superior since it does
all I/O through the virtualized go/build file system, and it
is highly parallel (and much faster).
We expose two flavours, simple (for existing tests) and
parallel (for high-performance tools such as gorename).
This CL creates the go/buildutil package, which is intended for
utilities related to go/build.
+ test.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/137430043
- for unused packages where base(package path) != package name
- for conflicts between imported packages or dot-imported objects
and local declarations
Per suggestions from adonovan, inspired by the gc error messages.
LGTM=adonovan
R=adonovan, bradfitz
CC=golang-codereviews
https://golang.org/cl/135550043
(godoc is excluded from this CL since it will continue to use
/src/pkg in its URL namespace, making the necessary cleanup
more subtle.)
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/141770043
Robert Griesemer
Peter Collingbourne
Alan Donovan
Emil Hessman
David Symonds
Andrew Gerrand