|
|
Descriptioncmd/go: add go generate
First cut.
Works well enough to support yacc via
http://codereview.appspot.com/125620044.
Patch Set 1 #
Total comments: 40
Patch Set 2 : diff -r 82e0fbcd5d93f448f84a0ed594632a6dbae473dc https://code.google.com/p/go/ #
Total comments: 11
Patch Set 3 : diff -r 82e0fbcd5d93f448f84a0ed594632a6dbae473dc https://code.google.com/p/go/ #Patch Set 4 : diff -r 82e0fbcd5d93f448f84a0ed594632a6dbae473dc https://code.google.com/p/go/ #Patch Set 5 : diff -r 82e0fbcd5d93f448f84a0ed594632a6dbae473dc https://code.google.com/p/go/ #Patch Set 6 : diff -r 82e0fbcd5d93f448f84a0ed594632a6dbae473dc https://code.google.com/p/go/ #
Total comments: 4
Patch Set 7 : diff -r bebfeba1e59da4d4570048e941743ae2452690d9 https://code.google.com/p/go/ #
Total comments: 5
Patch Set 8 : diff -r fca097989c4f439dc4197fc924c23bf3494e1fb6 https://code.google.com/p/go/ #
MessagesTotal messages: 16
Hello rsc (cc: golang-codereviews@googlegroups.com), I'd like you to review this change to https://code.google.com/p/go
Sign in to reply to this message.
https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go File src/cmd/go/generate.go (right): https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode25 src/cmd/go/generate.go:25: addBuildFlags(cmdGenerate) move this into the func init below https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode30 src/cmd/go/generate.go:30: UsageLine: "generate [-run regexp] [file.go...|packagePath...]", [file.go... | packages] ([packages] is what the other commands say and also matches 'go help packages', suggested below) https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode47 src/cmd/go/generate.go:47: (/usr/you/bin/mytool), or a command alias (q.v.) that evaluates to s/(q.v.)/(described below)/ none of our readers will know what it means, and it's not anywhere else in go documentation that i know of. can probably also s/ that evaluates to such// and leave that condition for when they learn what an alias is. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode50 src/cmd/go/generate.go:50: The arguments are space-separated tokens (or double-quoted strings) s/(// s/)// https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode52 src/cmd/go/generate.go:52: Shell-like variable expansion is available for any environment drop this sentence until later. it raises some questions that aren't ready to be answered. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode64 src/cmd/go/generate.go:64: $GOPKG this might as well be $GOPACKAGE, since it corresponds exactly to the 'package' statement (and we didn't bother to shorten generate). https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode73 src/cmd/go/generate.go:73: $HOME, are expanded throughout the command line. I believe this mention of variable expansion makes the one I flagged above unnecessary. This is a good place to mention that: 1) The syntax is $NAME on all operating systems, even Windows. 2) A reference to $NAME where NAME is not in the environment expands to an empty string. 3) Variables are expanded even inside quoted strings. (This is implied by the order here but worth pointing out explicitly.) https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode75 src/cmd/go/generate.go:75: A directive with the flag -command, that is, one of the form // A directive of the form https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode96 src/cmd/go/generate.go:96: each package, in lexical file name order, honoring build tags. What does file name mean? directory name? import path? If a generator fails in one package, does that stop it from being run in the others? Should be specified one way or the other. (It would mean that 'go generate -run yacc all' would only tell you about the first failure, which is unusual for the go command, so it's worth saying.) https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode98 src/cmd/go/generate.go:98: Whether specified by file or package, the file name passed to the To date, everything the go command has invoked has been run in the directory of the corresponding package. If 'go generate' did this too, $GODIR would be unnecessary, and the absolute path here would also be unnecessary. I think that might be a better default. Also, this sentence seems in conflict with the description above, which says that $GOFILE is relative to $GODIR. Unless there is another way that a file name is passed to the generator that I've missed. (The command line is the obvious one but I don't think that happens automatically.) https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:124: if len(args) > 0 && strings.HasSuffix(args[0], ".go") { packages(args) takes care of a list of .go files too. You should be able to use the tiny loop at the end always. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:164: // getPkgName returns the package name for the file. It must read the file to If you use packages(args) unconditionally above, can delete this. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:205: g.dir = filepath.Clean(g.dir) // No final separator please. There will still be a final separator for files in the root directory. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:207: fmt.Fprintf(os.Stderr, "%s: %s\n", g.pkg, g.file) maybe just fmt.Fprintf(os.Stderr, "%s\n", shortPath(g.path)) https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:234: g.errorf("error reading %s: %s", g.path, s.Err()) s/g.path/shortPath(g.path)/ https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:287: words = append(g.commands[words[0]], words[1:]...) suggest bounding cap in setShorthand to avoid possible aliasing here. (see comment in setShorthand) since everything is single-threaded it doesn't really matter, but it's probably better to be tidy now. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:299: // Make the file name relative to here if sensible. There's a standard shortener and a standard fatalf, and I've tried to put file:line: at the beginning of the line in all errors so that it matches what various tool modes expect for error reporting. This whole function shortens to: fmt.Fprintf(os.Stderr, "%s:%d: %s\n", shortPath(g.path), g.lineNum, fmt.Sprintf(format, args...)) fatalf("go generate: generator failed") (Using fmt.Sprintf is maybe less elegant than concatenating format strings, but it will keep working if someone gets clever and uses positional formats.) https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:331: case "GODIR": maybe this can go away. (comments above.) https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:366: g.commands[command] = words[2:] = words[2:len(words):len(words)] // force later append to make copy https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:372: cmd := exec.Command(words[0], words[1:]...) The more I think about this the more sure I am that you should set cmd.Dir = g.dir here. Otherwise the generator will inherit the directory where you run the go command, and in that case the generator behavior might differ between: cd dir go generate x/y cd some/other/dir go generate x/y cd x/y go generate x/y and that's probably not a good thing. Running the generator in x/y makes that impossible. It also makes it impossible to 'forget' to use $GODIR to get at supporting files.
Sign in to reply to this message.
please answer question about source order (see TODO in new source) https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go File src/cmd/go/generate.go (right): https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode25 src/cmd/go/generate.go:25: addBuildFlags(cmdGenerate) On 2014/08/23 22:16:30, rsc wrote: > move this into the func init below Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode30 src/cmd/go/generate.go:30: UsageLine: "generate [-run regexp] [file.go...|packagePath...]", On 2014/08/23 22:16:30, rsc wrote: > [file.go... | packages] > > ([packages] is what the other commands say and also matches 'go help packages', > suggested below) Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode47 src/cmd/go/generate.go:47: (/usr/you/bin/mytool), or a command alias (q.v.) that evaluates to On 2014/08/23 22:16:31, rsc wrote: > s/(q.v.)/(described below)/ > none of our readers will know what it means, and it's not anywhere else in go > documentation that i know of. > > can probably also s/ that evaluates to such// and leave that condition for when > they learn what an alias is. > > Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode50 src/cmd/go/generate.go:50: The arguments are space-separated tokens (or double-quoted strings) On 2014/08/23 22:16:31, rsc wrote: > s/(// s/)// Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode52 src/cmd/go/generate.go:52: Shell-like variable expansion is available for any environment On 2014/08/23 22:16:30, rsc wrote: > drop this sentence until later. it raises some questions that aren't ready to be > answered. Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode64 src/cmd/go/generate.go:64: $GOPKG On 2014/08/23 22:16:31, rsc wrote: > this might as well be $GOPACKAGE, since it corresponds exactly to the 'package' > statement (and we didn't bother to shorten generate). Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode73 src/cmd/go/generate.go:73: $HOME, are expanded throughout the command line. On 2014/08/23 22:16:30, rsc wrote: > I believe this mention of variable expansion makes the one I flagged above > unnecessary. > This is a good place to mention that: > > 1) The syntax is $NAME on all operating systems, even Windows. > 2) A reference to $NAME where NAME is not in the environment expands to an empty > string. > 3) Variables are expanded even inside quoted strings. (This is implied by the > order here but worth pointing out explicitly.) > > Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode75 src/cmd/go/generate.go:75: A directive with the flag -command, that is, one of the form On 2014/08/23 22:16:30, rsc wrote: > // A directive of the form Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode96 src/cmd/go/generate.go:96: each package, in lexical file name order, honoring build tags. you tell me. what is the order in which the files will be processed? https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcode98 src/cmd/go/generate.go:98: Whether specified by file or package, the file name passed to the On 2014/08/23 22:16:31, rsc wrote: > To date, everything the go command has invoked has been run in the directory of > the corresponding package. > If 'go generate' did this too, $GODIR would be unnecessary, and the absolute > path here would also be unnecessary. > I think that might be a better default. > > Also, this sentence seems in conflict with the description above, which says > that $GOFILE is relative to $GODIR. Unless there is another way that a file name > is passed to the generator that I've missed. (The command line is the obvious > one but I don't think that happens automatically.) Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:124: if len(args) > 0 && strings.HasSuffix(args[0], ".go") { On 2014/08/23 22:16:30, rsc wrote: > packages(args) takes care of a list of .go files too. > You should be able to use the tiny loop at the end always. Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:164: // getPkgName returns the package name for the file. It must read the file to On 2014/08/23 22:16:31, rsc wrote: > If you use packages(args) unconditionally above, can delete this. Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:205: g.dir = filepath.Clean(g.dir) // No final separator please. On 2014/08/23 22:16:30, rsc wrote: > There will still be a final separator for files in the root directory. Acknowledged. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:207: fmt.Fprintf(os.Stderr, "%s: %s\n", g.pkg, g.file) On 2014/08/23 22:16:31, rsc wrote: > maybe just fmt.Fprintf(os.Stderr, "%s\n", shortPath(g.path)) Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:234: g.errorf("error reading %s: %s", g.path, s.Err()) On 2014/08/23 22:16:30, rsc wrote: > s/g.path/shortPath(g.path)/ Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:287: words = append(g.commands[words[0]], words[1:]...) On 2014/08/23 22:16:30, rsc wrote: > suggest bounding cap in setShorthand to avoid possible aliasing here. (see > comment in setShorthand) > since everything is single-threaded it doesn't really matter, but it's probably > better to be tidy now. > Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:299: // Make the file name relative to here if sensible. On 2014/08/23 22:16:31, rsc wrote: > There's a standard shortener and a standard fatalf, and I've tried to put > file:line: at the beginning of the line in all errors so that it matches what > various tool modes expect for error reporting. This whole function shortens to: > > fmt.Fprintf(os.Stderr, "%s:%d: %s\n", shortPath(g.path), g.lineNum, > fmt.Sprintf(format, args...)) > fatalf("go generate: generator failed") > > (Using fmt.Sprintf is maybe less elegant than concatenating format strings, but > it will keep working if someone gets clever and uses positional formats.) Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:331: case "GODIR": On 2014/08/23 22:16:30, rsc wrote: > maybe this can go away. (comments above.) > decided to leave it but with a different meaning: it's the directory in which the generator is running, so there's a standard way to get that if required. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:366: g.commands[command] = words[2:] On 2014/08/23 22:16:30, rsc wrote: > = words[2:len(words):len(words)] // force later append to make copy > Done. https://codereview.appspot.com/125580044/diff/1/src/cmd/go/generate.go#newcod... src/cmd/go/generate.go:372: cmd := exec.Command(words[0], words[1:]...) On 2014/08/23 22:16:30, rsc wrote: > The more I think about this the more sure I am that you should set cmd.Dir = > g.dir here. > Otherwise the generator will inherit the directory where you run the go command, > and in that case the generator behavior might differ between: > > cd dir > go generate x/y > cd some/other/dir > go generate x/y > cd x/y > go generate x/y > > and that's probably not a good thing. Running the generator in x/y makes that > impossible. > It also makes it impossible to 'forget' to use $GODIR to get at supporting > files. Done.
Sign in to reply to this message.
Hello rsc@golang.org (cc: golang-codereviews@googlegroups.com), Please take another look.
Sign in to reply to this message.
https://codereview.appspot.com/125580044/diff/20001/src/cmd/go/generate.go File src/cmd/go/generate.go (right): https://codereview.appspot.com/125580044/diff/20001/src/cmd/go/generate.go#ne... src/cmd/go/generate.go:328: cmd.Env = append(cmd.Env, fmt.Sprintf("GODIR=%s", g.dir)) What if your current environment already has GODIR? You will end up with 2 GODIR in cmd.Env. Which one will be used to set new process environment? https://codereview.appspot.com/125580044/diff/20001/src/cmd/go/generate.go#ne... src/cmd/go/generate.go:329: cmd.Env = append(cmd.Env, fmt.Sprintf("GOFILE=%s", g.file)) As above. https://codereview.appspot.com/125580044/diff/20001/src/cmd/go/generate.go#ne... src/cmd/go/generate.go:330: cmd.Env = append(cmd.Env, fmt.Sprintf("GOPACKAGE=%s", g.pkg)) As above.
Sign in to reply to this message.
https://codereview.appspot.com/125580044/diff/20001/src/cmd/go/generate.go File src/cmd/go/generate.go (right): https://codereview.appspot.com/125580044/diff/20001/src/cmd/go/generate.go#ne... src/cmd/go/generate.go:51: $GODIR Should we remove $GODIR entirely? Generators can call os.Getwd if they really care. https://codereview.appspot.com/125580044/diff/20001/src/cmd/go/generate.go#ne... src/cmd/go/generate.go:86: TODO: What is the true order? Are you asking for a description of the current behavior or are you asking whether the current behavior is the correct one? I think the current behavior is fine, although I am not sure I would abort the multipackage case on the first bad package. I think this describes the current behavior: Generate processes packages in the order given on the command line, one at a time; if the command line lists .go files, they are treated as a single package. Within a package, generate processes the source files in a package in file name order, one at a time. Within a source file, generate runs generators in the order they appear in the file, one at a time. If a generator exits with an error status, generate stops all processing: it does not process the rest of the source file, nor remaining files in the package, nor remaining packages. https://codereview.appspot.com/125580044/diff/20001/src/cmd/go/generate.go#ne... src/cmd/go/generate.go:328: cmd.Env = append(cmd.Env, fmt.Sprintf("GODIR=%s", g.dir)) On 2014/08/24 01:26:06, brainman wrote: > What if your current environment already has GODIR? You will end up with 2 GODIR > in cmd.Env. Which one will be used to set new process environment? Alex is right; use cmd.Env = mergeEnvLists([]string{"GODIR="+g.dir, "GOFILE="+g.file, "GOPACKAGE="+g.pkg}, os.Environ())
Sign in to reply to this message.
https://codereview.appspot.com/125580044/diff/20001/src/cmd/go/generate.go File src/cmd/go/generate.go (right): https://codereview.appspot.com/125580044/diff/20001/src/cmd/go/generate.go#ne... src/cmd/go/generate.go:51: $GODIR On 2014/08/24 02:52:35, rsc wrote: > Should we remove $GODIR entirely? Generators can call os.Getwd if they really > care. all right, you seem to care more than i do. https://codereview.appspot.com/125580044/diff/20001/src/cmd/go/generate.go#ne... src/cmd/go/generate.go:86: TODO: What is the true order? the former. done. again, you seem to care more than i about continuing processing in the case of failure, which i don't understand (the build is broken; why proceed?) but i've changed it and would happily change back. the only time it matters is with go install xxx/... and if it fails, the problem will be fixed and what's the first thing i'm going to run? why, go install xxx/.... and in such cases the likeliest problem is a broken generator. but i don't care as much as you, and go install xxx/... works fine whether processing continues or stops. so for consistency with the other tools, it's fine. https://codereview.appspot.com/125580044/diff/20001/src/cmd/go/generate.go#ne... src/cmd/go/generate.go:328: cmd.Env = append(cmd.Env, fmt.Sprintf("GODIR=%s", g.dir)) On 2014/08/24 01:26:06, brainman wrote: > What if your current environment already has GODIR? You will end up with 2 GODIR > in cmd.Env. Which one will be used to set new process environment? Done. https://codereview.appspot.com/125580044/diff/20001/src/cmd/go/generate.go#ne... src/cmd/go/generate.go:329: cmd.Env = append(cmd.Env, fmt.Sprintf("GOFILE=%s", g.file)) On 2014/08/24 01:26:06, brainman wrote: > As above. Done. https://codereview.appspot.com/125580044/diff/20001/src/cmd/go/generate.go#ne... src/cmd/go/generate.go:330: cmd.Env = append(cmd.Env, fmt.Sprintf("GOPACKAGE=%s", g.pkg)) On 2014/08/24 01:26:06, brainman wrote: > As above. Done.
Sign in to reply to this message.
Hello rsc@golang.org, alex.brainman@gmail.com (cc: golang-codereviews@googlegroups.com), Please take another look.
Sign in to reply to this message.
LGTM Alex https://codereview.appspot.com/125580044/diff/100001/src/cmd/go/doc.go File src/cmd/go/doc.go (right): https://codereview.appspot.com/125580044/diff/100001/src/cmd/go/doc.go#newcod... src/cmd/go/doc.go:253: $GODIR You have removed $GODIR from cmdGenerate. Why here? https://codereview.appspot.com/125580044/diff/100001/src/cmd/go/generate.go File src/cmd/go/generate.go (right): https://codereview.appspot.com/125580044/diff/100001/src/cmd/go/generate.go#n... src/cmd/go/generate.go:336: // cmd.Env starts out empty. This comment is confusing now. Remove it?
Sign in to reply to this message.
https://codereview.appspot.com/125580044/diff/100001/src/cmd/go/doc.go File src/cmd/go/doc.go (right): https://codereview.appspot.com/125580044/diff/100001/src/cmd/go/doc.go#newcod... src/cmd/go/doc.go:253: $GODIR On 2014/08/24 06:50:09, brainman wrote: > You have removed $GODIR from cmdGenerate. Why here? forgot to run mkdoc.sh. fixed. https://codereview.appspot.com/125580044/diff/100001/src/cmd/go/generate.go File src/cmd/go/generate.go (right): https://codereview.appspot.com/125580044/diff/100001/src/cmd/go/generate.go#n... src/cmd/go/generate.go:336: // cmd.Env starts out empty. On 2014/08/24 06:50:09, brainman wrote: > This comment is confusing now. Remove it? Done.
Sign in to reply to this message.
Hello rsc@golang.org, alex.brainman@gmail.com (cc: golang-codereviews@googlegroups.com), Please take another look.
Sign in to reply to this message.
LGTM https://codereview.appspot.com/125580044/diff/120001/src/cmd/go/generate.go File src/cmd/go/generate.go (right): https://codereview.appspot.com/125580044/diff/120001/src/cmd/go/generate.go#n... src/cmd/go/generate.go:90: If any generator returns an error exit status, "go generate" skips Dup of previous sentence? https://codereview.appspot.com/125580044/diff/120001/src/cmd/go/generate.go#n... src/cmd/go/generate.go:159: // Processing below here calls errorf on failure, which does panic(stop). s/errorf/g.errorf/ there's a top-level func errorf too, and it doesn't panic, so i was confused. https://codereview.appspot.com/125580044/diff/120001/src/cmd/go/generate.go#n... src/cmd/go/generate.go:270: panic(stop) call setExitStatus before panic? i don't know whether it should be 1 or 2 but it should probably be non-zero.
Sign in to reply to this message.
go1.4.txt too
Sign in to reply to this message.
https://codereview.appspot.com/125580044/diff/120001/src/cmd/go/generate.go File src/cmd/go/generate.go (right): https://codereview.appspot.com/125580044/diff/120001/src/cmd/go/generate.go#n... src/cmd/go/generate.go:90: If any generator returns an error exit status, "go generate" skips On 2014/08/24 17:43:00, rsc wrote: > Dup of previous sentence? Done. https://codereview.appspot.com/125580044/diff/120001/src/cmd/go/generate.go#n... src/cmd/go/generate.go:159: // Processing below here calls errorf on failure, which does panic(stop). On 2014/08/24 17:43:00, rsc wrote: > s/errorf/g.errorf/ > > there's a top-level func errorf too, and it doesn't panic, so i was confused. Done.
Sign in to reply to this message.
*** Submitted as https://code.google.com/p/go/source/detail?r=901a1adaf852 *** cmd/go: add go generate First cut. Works well enough to support yacc via http://codereview.appspot.com/125620044. LGTM=alex.brainman, rsc R=rsc, alex.brainman CC=golang-codereviews https://codereview.appspot.com/125580044
Sign in to reply to this message.
Message was sent while issue was closed.
On 2014/08/24 18:34:17, r wrote: > *** Submitted as https://code.google.com/p/go/source/detail?r=901a1adaf852 *** > > cmd/go: add go generate > First cut. > > Works well enough to support yacc via > http://codereview.appspot.com/125620044. > > LGTM=alex.brainman, rsc > R=rsc, alex.brainman > CC=golang-codereviews > https://codereview.appspot.com/125580044 FYI, minor typo at https://code.google.com/p/go/source/browse/src/cmd/go/generate.go#164 s/encouter/encounter/
Sign in to reply to this message.
|