Moves runtime/trace support (including its command line flag) behind
a "gc" build tag to allow goimports to build under gccgo, which does
not support runtime/trace.
Updates golang/go#15544.
Change-Id: I017a44089c0a4f3d3ba98815d57a141e25b3fe56
Reviewed-on: https://go-review.googlesource.com/26998
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
mmapfile.go uses symbols in the syscall package that are not defined
on windows and some other operating systems. Temporarily
buildtag-restrict mmapfile to darwin and linux (the platforms easiest
for me to test) to fix the build.
Change-Id: Ib056608a655b6d32170cd86deac785811e7bc0d1
Reviewed-on: https://go-review.googlesource.com/26830
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is based on github.com/tombergan/goheapdump/heapdump.
This CL mostly just copies over the 'raw' data structures based
on the profiler records' data structures. Many of them may need
to be changed, but I think it will be good to have these definitions
here to provide a base.
Change-Id: I609202b6b87d980b0835c8087b3d78e11bd6dfe3
Reviewed-on: https://go-review.googlesource.com/25584
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This will allow users to use a different flag name.
Change-Id: I252871b8efb6867e61ca507f59a9663cb7140b7d
Reviewed-on: https://go-review.googlesource.com/26632
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I've had too many issues with customelements v1. The interface for v0
isn't as nice, and v0 will eventually be deprecated. But v1's polyfill
library is better supported, and it will be easy to upgrade later.
Change-Id: I87b376376b750167a0464c6c249930edecbd59db
Reviewed-on: https://go-review.googlesource.com/25545
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
This CL's purpose is to introduce the dependency on the HTML Custom
Elements polyfill. Like we've done so far, I'm trying to keep
dependencies light by using current or polyfilling future webcomponents
standards.
Change-Id: I11d14db367b697cdd527fb66b9d7d160ac244b78
Reviewed-on: https://go-review.googlesource.com/25494
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add a configuration that allows unit testing of client Typescript
code using Karma and Jasmine. Add a basic test to exercise this.
Change-Id: I88af82b68547423efeaafb0fab8214ed39573ee9
Reviewed-on: https://go-review.googlesource.com/25411
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Evan Martin <evanm@google.com>
gcloud command no longer requires preview for deployment and is showing
warning when command is executed:
```
WARNING: The `gcloud preview app` command group is deprecated; please
use the `gcloud app` commands instead.
```
This change is removing "preview" text from README to make deploy
command up to date with gcloud.
Change-Id: I64d390ab4891f82fe608c64be20fae01a80d00fc
Reviewed-on: https://go-review.googlesource.com/25430
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change breaks out the code that adds handler funcs and
starts the HTTP server into separate functions, so that they
can be overridden in other environments, such as Google's.
For instance, listenAndServe can be overridden in an init method
in a different file to use a HTTP2 server.
Updates golang/go#16410
Change-Id: I074242af10486c60c374e9ac7ebe9d0e61a8fa22
Reviewed-on: https://go-review.googlesource.com/25273
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This change primarily exists to import Typescript and the
ES6 module loader polyfill as dependencies for this project.
Both dependencies are relatively lightweight and can be easily
removed if we decide we don't need them.
The module loader polyfill implements support for an upcoming
browser feature in ES6 (the next version of JavaScript). This
feature helps modularize Javascript code and conveniently split it
into multiple files. It should be supported by the stable versions
of the four major browsers (Chrome, Firefox, Safari and Edge)
by the end of the year. Once that happens, we can remove the polyfill.
The Typescript compiler provides two things: First, it compiles
new, but not-yet-supported ES6 Javascript features into ES5. It
also provides a typechecker similar to what Closure does, but types
are indicated in syntax rather than JSDoc comments. If we decide
we don't want this dependency, we can compile the Typescript code
into human-readable JavaScript code. (The compiler basically
strips out types and replaces ES6 language features with more
well-supported JavaScript equivalents). The Typescript compiler
is not required for development. typescript.js and a feature in
the module loader will be used to compile Typescript into JavaScript
at serving time. (We might want to do something different for the
production version, but we can get to that later).
The change also adds code to serve the HTML and Javascript files.
Updates golang/go#16410
Change-Id: I42c669d1de636d8b221fc03ed22aa7ac60554610
Reviewed-on: https://go-review.googlesource.com/25240
Reviewed-by: Austin Clements <austin@google.com>
This allows the caller to indicate they want certain
import paths to sort into another group after 3rd-party
imports when added by goimports. For example, running
'goimports -local example.com/' might produce
import (
"database/sql"
"io"
"strconv"
"golang.org/x/net/context"
"example.com/foo/bar"
"example.com/foo/baz"
)
Resolvesgolang/go#12420
Change-Id: If6d88599f6cca2f102313bce95ba6ac46ffec1fe
Reviewed-on: https://go-review.googlesource.com/25145
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The responsibility of flag.Usage is to print usage to stderr:
> Usage prints to standard error a usage message documenting all
> defined command-line flags.
Calling os.Exit(2) is outside of its scope, flag package does that.
Change-Id: I3eef2b796e5ddedff6d5927dbcdbfff3a6082270
Reviewed-on: https://go-review.googlesource.com/23788
Reviewed-by: Joseph Holsten <joseph@josephholsten.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
filepath.Rel will always fail if one parameter starts with
drive letter and the other does not. Make both filepath.Rel
parameters absolute paths, to give it chance to succeed.
Fixes broken tools build on windows.
Change-Id: Ibefcfe283f28977503323f01bc3a698478227f84
Reviewed-on: https://go-review.googlesource.com/25120
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Both functions had documentation referring to BuildAll when the
function is now called Build.
Change-Id: I59cce397a0a72bf7fa36f9798e2b07bb6b1da726
Reviewed-on: https://go-review.googlesource.com/25084
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change creates a place where we can start building
the 'heapdump' heap viewer and analyzer
Updates golang/go#16410
Change-Id: I216e13f1ceb6790bf492cfc8cbcc4f19f12b0b9e
Reviewed-on: https://go-review.googlesource.com/25085
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This brings goimports from 160ms to 100ms on my laptop, and under 50ms
on my Linux machine.
Using cmd/trace, I noticed that filepath.Walk is inherently slow.
See https://golang.org/issue/16399 for details.
Instead, this CL introduces a new (private) filepath.Walk
implementation, optimized for speed and avoiding unnecessary work.
In addition to avoid an Lstat per file, it also reads directories
concurrently. The old goimports code did that too, but now that logic
is removed from goimports and the code is simplified.
This also adds some profiling command line flags to goimports that I
found useful.
Updates golang/go#16367 (goimports is slow)
Updates golang/go#16399 (filepath.Walk is slow)
Change-Id: I708d570cbaad3fa9ad75a12054f5a932ee159b84
Reviewed-on: https://go-review.googlesource.com/25001
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This means a directory /gopath/src/foo/Go-Bar is considered as maybe
containing package "bar" or even "gobar".
Also, more tests.
Fixesgolang/go#16402
Change-Id: I14208d738e3a081cb6d9bcd83d777280e118f4e7
Reviewed-on: https://go-review.googlesource.com/25030
Reviewed-by: Andrew Gerrand <adg@golang.org>
The test expectation includes the text of a UNIX ENOENT message.
Also, make the same change for (deprecated) oracle tool.
Fixesgolang/go#16397
Change-Id: I8c3c6a300ff2366bfeb97cf41d34097c41aab680
Reviewed-on: https://go-review.googlesource.com/24968
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This prevents a JS error when the notes are not present.
Change-Id: Ib8875306027b7e43441310d4228c690e2249056e
Reviewed-on: https://go-review.googlesource.com/24963
Reviewed-by: Andrew Gerrand <adg@golang.org>
These are mostly comments for CL 24941 that didn't
get sent quickly enough.
strings.Trim(`\"`) works, but by accident.
It trims all leading and trailing "s and \s,
but there are never leading or trailing \s.
Semantic line breaks and punctuation cleanup.
The reflow of comments in the pkgName == "main" if
block is to silence this spurious vet failure:
fix.go:247: +build comment must appear before package clause and be followed by a blank line
Plain sync.Once values are enough.
Change-Id: I241f3025031b6f21605da78ea52066713a203327
Reviewed-on: https://go-review.googlesource.com/24983
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Each $GOPATH entry may have a file $GOPATH/src/.goimportsignore which
may contain blank lines, #comment lines, or lines naming a directory
relative to the configuration file to ignore when scanning. No
globbing or regex patterns are allowed.
Updates golang/go#16367 (goimports speed)
Fixesgolang/go#16386 (add mechanism to ignore directories)
Change-Id: I8f1a88ae6c4d0ed3075444d70aec3e2228c5ce6a
Reviewed-on: https://go-review.googlesource.com/24971
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When goimports was run on a file like:
package main
import (
"example.net/foo"
"example.net/bar"
)
var _, _ = foo.Foo, bar.Bar
... even though there looks to be no work to do, it still needs to
verify that "example.net/foo" is really package "foo" (even though it
looks like it) and "example.net/bar" is really package
"bar". (Packages in the standard library are hard-coded since the
previous commit and not verified for consistency since they're always consistent)
To do that verification for non-std packages, go/build.Import was
being used before, but Import reads all files in the directory to make
sure they're consistent. That's unnecessary. Instead, stop after the
first file. If example.net/foo has foo.go with "package foo" and
just_kidding.go with "package other", we never read that far to find
the inconsistency. Oh well. Prefer speed.
Updates golang/go#16367
Change-Id: I9fc3fefbee0e8a6bc287bf2a565257fb9523fd5c
Reviewed-on: https://go-review.googlesource.com/24948
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
I was going to add a hook to enable go-guru-hl-identifier-mode
as a side effect of go-mode, but a person I consulted said that
was bad form; instead I merely documented it.
Change-Id: I48b00b71c7ba485b3d632211923509a74281acbe
Reviewed-on: https://go-review.googlesource.com/24834
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In the package, the added import declarations used backslashes.
In the test, filenames in warning messages used backslashes.
Now both use forward slash.
Fixesgolang/go#16384
Change-Id: I43116aab0b3209305f23ed9def7c4adf3259941e
Reviewed-on: https://go-review.googlesource.com/24943
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I felt the burn of my laptop on my legs, spinning away while processing
goimports, and felt that it was time to make goimports great again.
Over the past few years goimports fell into a slow state of disrepair
with too many feature additions and no attention to the performance
death by a thousand cuts. This was particularly terrible on OS X with
its lackluster filesystem buffering.
This CL makes goimports stronger, together with various optimizations
and more visibility into what goimports is doing.
* adds more internal documentation
* avoids scanning $GOPATH for answers when running goimports on a file
under $GOROOT (for Go core hackers)
* don't read all $GOROOT & $GOPATH directories' Go code looking for
their package names until much later. Require the package name of
missing imports to be present in the last two directory path
components. Then only try importing them in order from best to
worst (shortest to longest, as before), so we can stop early.
* when adding imports, add names to imports when the imported package name
doesn't match the baes of its import path. For example:
import foo "example.net/foo/v1"
* don't read all *.go files in a package directory once the first file
in a directory has revealed itself to be a package we're not looking
for. For example, if we're looking for the right "client" for "client.Foo",
we used to consider a directory "bar/client" as a candidate and read
all 50 of its *.go files instead of stopping after its first *.go
file had a "package main" line.
* add some fast paths to remove allocations
* add some fast paths to remove disk I/O when looking up the base
package name of a standard library import (of existing imports in a
file, which are very common)
* adds a special case for import "C", to avoid some disk I/O.
* add a -verbose flag to goimports for debugging
On my Mac laptop with a huge $GOPATH, with a test file like:
package foo
import (
"fmt"
"net/http"
)
/*
*/
import "C"
var _ = cloudbilling.New
var _ = http.NewRequest
var _ = client.New
... this took like 10 seconds before, and now 1.3 seconds. (Still
slow; disk-based caching can come later)
Updates golang/go#16367 (goimports is slow)
Updates golang/go#16384 (refactor TestRename is broken on Windows)
Change-Id: I97e85d3016afc9f2ad5501f97babad30c7989183
Reviewed-on: https://go-review.googlesource.com/24941
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
There is no need to check for import conflicts when the package name
doesn't change. Add test.
Also, when reporting a (non-spurious) import conflict, make clear that
the error is just a warning. Add a test for same.
Change-Id: Idde0483b502cd041fd893230fec06b8533f54f3c
Reviewed-on: https://go-review.googlesource.com/24917
Reviewed-by: Michael Matloob <matloob@golang.org>
In Go 1.7, math/rand.Read was added. Previously, the only package
containing "rand.Read" was "crypto/rand".
goimports was updated to know that, and zstdlib.go contains a note
that it's ambiguous:
"rand.Perm": "math/rand",
"rand.Prime": "crypto/rand",
"rand.Rand": "math/rand",
// "rand.Read" is ambiguous
"rand.Reader": "crypto/rand",
"rand.Seed": "math/rand",
"rand.Source": "math/rand",
The intention originally was that such ambiguous things would
never be resolved, even randomly.
But a later change added support for build.Default.SrcDirs, which
meant GOROOT was also searched for ambiguous things. Or maybe I forget
the history.
In any case, when goimports tried to resolve "rand.Read", the
findImportStdlib check was returning nothing, which lead to the
$GOROOT being searched, where math/rand was picked by chance. That's a
dangerous default when the intentional might've been crypto/rand.
Special case it and prefer crypto/rand if there's no more specific
clue either way.
Change-Id: Ib5f8f297f72fa309d5ca9b15a37493df2e17567c
Reviewed-on: https://go-review.googlesource.com/24847
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
combine-and-quote-strings is buggy. The value of this expression:
(split-string-and-unquote (combine-and-quote-strings '("a" "" "b")))
is ("a" "b"). Consequently, if go-guru-scope is "", the following
"-tags" flag is interpreted as the scope.
Change-Id: I2955ffa2b95914e01d44b52690e810f816076d5c
Reviewed-on: https://go-review.googlesource.com/24746
Reviewed-by: Dominik Honnef <dominik@honnef.co>
Reviewed-by: Alan Donovan <adonovan@google.com>
This comment was written and has not been changed since this package was
created: https://www.youtube.com/watch?v=1rZ-JorHJEY
It is no longer called 'tipgodoc', and it is no longer all that 'new'. This
change request updates that text to reflect the current state of the 'tip'
command.
Change-Id: I4ce56fb9a3bd617cf92f8d53df5a2d4726085a9a
Reviewed-on: https://go-review.googlesource.com/24860
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Only unary CallExprs with no ellipsis, f(x), are ambiguous.
Change-Id: If4f17445ab0725dee916992db133eac5536133a7
Reviewed-on: https://go-review.googlesource.com/24552
Reviewed-by: Robert Griesemer <gri@golang.org>
When building the corpus of local packages, a "too many open files"
error would cause some directories inside GOPATH to be skipped.
Further, the error would not be reported because it was masked by a
"file not found" error from the GOROOT VFS layer.
This change adds a rate limit around parsing files when buildling
the directory tree, error reporting when godoc is run with -v, and
fixes the masked error issue in the vfs package.
It's possible that the rate limiting could be put into the
godoc/vfs/gatefs package, but I tried making the gate account for
open files (not just individual open/close/read/write operations)
but then godoc just hard locks (it wasn't designed to only open 20
files at once).
Change-Id: I925d120b53d9a86430b6977cb90eb143785ecc48
Reviewed-on: https://go-review.googlesource.com/24060
Reviewed-by: Dave Day <djd@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The go tool will import a package with a import path that traverses
symlinks with no problems, but goimports would remove that import
because it would fail to recognize the package as existent.
Fixesgolang/go#14845
Note: if the file you are currently processing also has a name inside
the symlink, you might have to use the "long" path for vendoring to
work, as it wouldn't be recognized as "deeper" than the vendor folder
otherwise. For example in this tree:
.
├── myfile.go
└── x
├── vendor
│ └── mypkg
│ └── foo.go
└── y -> ..
If myfile.go imports mypkg, you will have to process it as
./x/y/myfile.go, not ./myfile.go.
Change-Id: Ic8f41baed3f28d4e9b813160d91aef09ece1fc9f
Reviewed-on: https://go-review.googlesource.com/23803
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
