2009-11-03 23:00:36 -07:00
|
|
|
// Copyright 2009 The Go Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
2009-11-09 12:45:15 -07:00
|
|
|
Gc is the generic label for the family of Go compilers
|
2009-11-03 23:00:36 -07:00
|
|
|
that function as part of the (modified) Plan 9 tool chain. The C compiler
|
|
|
|
documentation at
|
|
|
|
|
|
|
|
http://plan9.bell-labs.com/sys/doc/comp.pdf (Tools overview)
|
|
|
|
http://plan9.bell-labs.com/sys/doc/compiler.pdf (C compiler architecture)
|
|
|
|
|
|
|
|
gives the overall design of the tool chain. Aside from a few adapted pieces,
|
|
|
|
such as the optimizer, the Go compilers are wholly new programs.
|
|
|
|
|
|
|
|
The compiler reads in a set of Go files, typically suffixed ".go". They
|
|
|
|
must all be part of one package. The output is a single intermediate file
|
|
|
|
representing the "binary assembly" of the compiled package, ready as input
|
|
|
|
for the linker (6l, etc.).
|
|
|
|
|
|
|
|
The generated files contain type information about the symbols exported by
|
|
|
|
the package and about types used by symbols imported by the package from
|
|
|
|
other packages. It is therefore not necessary when compiling client C of
|
|
|
|
package P to read the files of P's dependencies, only the compiled output
|
|
|
|
of P.
|
|
|
|
|
2013-02-05 05:00:38 -07:00
|
|
|
Command Line
|
|
|
|
|
2010-10-18 16:26:11 -06:00
|
|
|
Usage:
|
2012-03-08 10:31:09 -07:00
|
|
|
go tool 6g [flags] file...
|
2010-10-18 16:26:11 -06:00
|
|
|
The specified files must be Go source files and all part of the same package.
|
|
|
|
Substitute 6g with 8g or 5g where appropriate.
|
2009-11-03 23:00:36 -07:00
|
|
|
|
|
|
|
Flags:
|
|
|
|
-o file
|
2010-11-05 12:21:54 -06:00
|
|
|
output file, default file.6 for 6g, etc.
|
2009-11-03 23:00:36 -07:00
|
|
|
-e
|
|
|
|
normally the compiler quits after 10 errors; -e prints all errors
|
2011-09-07 13:50:21 -06:00
|
|
|
-p path
|
|
|
|
assume that path is the eventual import path for this code,
|
|
|
|
and diagnose any attempt to import a package that depends on it.
|
cmd/go: fix relative imports again
I tried before to make relative imports work by simply
invoking the compiler in the right directory, so that
an import of ./foo could be resolved by ./foo.a.
This required creating a separate tree of package binaries
that included the full path to the source directory, so that
/home/gopher/bar.go would be compiled in
tmpdir/work/local/home/gopher and perhaps find
a ./foo.a in that directory.
This model breaks on Windows because : appears in path
names but cannot be used in subdirectory names, and I
missed one or two places where it needed to be removed.
The model breaks more fundamentally when compiling
a test of a package that lives outside the Go path, because
we effectively use a ./ import in the generated testmain,
but there we want to be able to resolve the ./ import
of the test package to one directory and all the other ./
imports to a different directory. Piggybacking on the compiler's
current working directory is then no longer possible.
Instead, introduce a new compiler option -D prefix that
makes the compiler turn a ./ import into prefix+that,
so that import "./foo" with -D a/b/c turns into import
"a/b/c/foo". Then we can invent a package hierarchy
"_/" with subdirectories named for file system paths:
import "./foo" in the directory /home/gopher becomes
import "_/home/gopher/foo", and since that final path
is just an ordinary import now, all the ordinary processing
works, without special cases.
We will have to change the name of the hierarchy if we
ever decide to introduce a standard package with import
path "_", but that seems unlikely, and the detail is known
only in temporary packages that get thrown away at the
end of a build.
Fixes #3169.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5732045
2012-03-02 20:16:02 -07:00
|
|
|
-D path
|
|
|
|
treat a relative import as relative to path
|
2010-09-30 13:02:43 -06:00
|
|
|
-L
|
|
|
|
show entire file path when printing line numbers in errors
|
2009-11-03 23:00:36 -07:00
|
|
|
-I dir1 -I dir2
|
|
|
|
add dir1 and dir2 to the list of paths to check for imported packages
|
2011-12-02 12:13:12 -07:00
|
|
|
-N
|
|
|
|
disable optimizations
|
2009-11-03 23:00:36 -07:00
|
|
|
-S
|
2012-06-07 10:05:34 -06:00
|
|
|
write assembly language text to standard output (code only)
|
2013-02-05 05:00:38 -07:00
|
|
|
-S -S
|
2012-06-07 10:05:34 -06:00
|
|
|
write assembly language text to standard output (code and data)
|
2011-03-04 21:21:26 -07:00
|
|
|
-u
|
|
|
|
disallow importing packages not marked as safe
|
2010-02-08 10:46:53 -07:00
|
|
|
-V
|
|
|
|
print the compiler version
|
2013-01-10 21:35:58 -07:00
|
|
|
-race
|
2012-10-02 00:05:46 -06:00
|
|
|
compile with race detection enabled
|
2009-11-03 23:00:36 -07:00
|
|
|
|
|
|
|
There are also a number of debugging flags; run the command with no arguments
|
|
|
|
to get a usage message.
|
|
|
|
|
2013-02-05 05:00:38 -07:00
|
|
|
Compiler Directives
|
|
|
|
|
|
|
|
The compiler accepts two compiler directives in the form of // comments at the
|
|
|
|
beginning of a line. To distinguish them from non-directive comments, the directives
|
|
|
|
require no space between the slashes and the name of the directive. However, since
|
|
|
|
they are comments, tools unaware of the directive convention or of a particular
|
|
|
|
directive can skip over a directive like any other comment.
|
|
|
|
|
|
|
|
//line path/to/file:linenumber
|
|
|
|
|
|
|
|
The //line directive specifies that the source line that follows should be recorded
|
|
|
|
as having come from the given file path and line number. Successive lines are
|
|
|
|
recorded using increasing line numbers, until the next directive. This directive
|
|
|
|
typically appears in machine-generated code, so that compilers and debuggers
|
|
|
|
will show lines in the original input to the generator.
|
|
|
|
|
|
|
|
//go:noescape
|
|
|
|
|
|
|
|
The //go:noescape directive specifies that the next declaration in the file, which
|
|
|
|
must be a func without a body (meaning that it has an implementation not written
|
|
|
|
in Go) does not allow any of the pointers passed as arguments to escape into the
|
|
|
|
heap or into the values returned from the function. This information can be used as
|
|
|
|
during the compiler's escape analysis of Go code calling the function.
|
2009-11-03 23:00:36 -07:00
|
|
|
*/
|
|
|
|
package documentation
|