Fix some typos in GN documentation.

tools/gn/docs/language.md

 # GN Language and Operation
 
 [TOC]
 
 ## Introduction
 
 This page describes many of the language details and behaviors.
 
 ### Use the built-in help!
 
@@ skipping 38 matching lines @@
 environment. See `gn help` for more.
 
 There are purposefully many omissions in the language. There are no
 loops or function calls, for example. As per the above design
 philosophy, if you need this kind of thing you're probably doing it
 wrong.
 
 The variable `sources` has a special rule: when assigning to it, a list
 of exclusion patterns is applied to it. This is designed to
 automatically filter out some types of files. See `gn help
-set_sources_assignment_filter` and `gn help patterns` for more.

[eroman, 2015/09/11 20:37:06]

(gn help patterns doesn't exist)

[brettw, 2015/09/11 21:03:14]

Ah, this should be `gn help label_pattern` instead.

[eroman, 2015/09/11 21:08:11]

Done.

+set_sources_assignment_filter` for more.
 
 ### Strings
 
 Strings are enclosed in double-quotes and use backslash as the escape
 character. The only escape sequences supported are
 
   * `\"` (for literal quote)
   * `\$` (for literal dollars sign)
   * `\\` (for literal backslash) Any other use of a backslash is treated
     as a literal backslash. So, for example, `\b` used in patterns does
@@ skipping 169 matching lines @@
 ```
 "//base/test:test_support"
 ```
 
 which consists of a source-root-absolute path, a colon, and a name. This
 means to look for the thing named "test\_support" in
 `src/base/test/BUILD.gn`.
 
 When loading a build file, if it doesn't exist in the given location
 relative to the source root, GN will look in the secondary tree in
-`tools/gn/secondary`. This structure of this tree mirrors the main
+`tools/gn/secondary`. The structure of this tree mirrors the main
 repository and is a way to add build files for directories that may be
 pulled from other repositories where we can't easily check in BUILD
 files.
 
 A canonical label also includes the label of the toolchain being used.
 Normally, the toolchain label is implicitly inherited, but you can
 include it to specify cross-toolchain dependencies (see "Toolchains"
 below).
 
 ```
 "//base/test:test_support(//build/toolchain/win:msvc)"
 ```
 
-In this case it will look for the a toolchain definition called "msvc"
+In this case it will look for the toolchain definition called "msvc"
 in the file `//build/toolchain/win` to know how to compile this target.
 
 If you want to refer to something in the same buildfile, you can omit
 the path name and just start with a colon.
 
 ```
 ":base"
 ```
 
 Labels can be specified as being relative to the current directory:
@@ skipping 99 matching lines @@
   * `action_foreach`: Run a script once for each source file.
   * `component`: Configurable to be another type of library.
   * `executable`: Generates an executable file.
   * `group`: A virtual dependency node that refers to one or more other
     targets.
   * `shared_library`: A .dll or .so.
   * `source_set`: A lightweight virtual static library (usually
     preferrable over a real static library since it will build faster).
   * `static_library`: A .lib or .a file (normally you'll want a
     source\_set instead).
-  * `test`: Generates an executable but annotates it as a test.

[eroman, 2015/09/11 20:37:06]

"test" does not appear to be a built-in (rather is a chrome-specific template).

[brettw, 2015/09/11 21:03:14]

Yeah, I moved this a while ago to being a template.

 
 You can extend this to make custom target types using templates (see below).
 
 ## Configs
 
 Configs are named objects that specify sets of flags, include
 directories, and defines. They can be applied to a target and pushed to
 dependent targets.
 
 To define a config:
@@ skipping 271 matching lines @@
 name relative to the current directory to be relative to the root build
 directory would be: ``` new_paths = rebase_path("myfile.c",
 root_build_dir) ```
 
 ### Patterns
 
 Patterns are used to generate the output file names for a given set of
 inputs for custom target types, and to automatically remove files from
 the `sources` variable (see `gn help set_sources_assignment_filter`).
 
-They are like simple regular expressions. See `gn help patterns` for more.
+They are like simple regular expressions. See `gn help set_sources_assignment_filter` for more.

[eroman, 2015/09/11 20:37:06]

Is this right? Do I need to wrap this?

[brettw, 2015/09/11 21:03:14]

label_pattern instead.

 
 ### Executing scripts
 
 There are two ways to execute scripts. All external scripts in GN are in
 Python. The first way is as a build step. Such a script would take some
 input and generate some output as part of the build. Targets that invoke
 scripts are declared with the "action" target type (see `gn help
 action`).
 
 The second way to execute scripts is synchronously during build file
@@ skipping 39 matching lines @@
 settings which work a bit differently in Blaze. This is partially to
 make conversion from the existing GYP code easier, and the GYP
 constructs generally offer more fine-grained control (which is either
 good or bad, depending on the situation).
 
 GN also uses GYP names like "sources" instead of "srcs" since
 abbreviating this seems needlessly obscure, although it uses Blaze's
 "deps" since "dependencies" is so hard to type. Chromium also compiles
 multiple languages in one target so specifying the language type on the
 target name prefix was dropped (e.g. from `cc_library`).