Remove {#link} anchors, which do not work with github's markdown.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117766135

6 files changed, 56 insertions, 59 deletions

diff --git a/value/userguide/builders-howto.md b/value/userguide/builders-howto.md
index 76a5eadc..847e5177 100644
--- a/value/userguide/builders-howto.md
+++ b/value/userguide/builders-howto.md
@@ -30,7 +30,7 @@ How do I...
     *   ... [offer **both** accumulation and set-at-once methods for the same
         collection-valued property?](#collection_both)
 
-## ... use (or not use) `set` prefixes? {#beans}
+## <a name="beans"></a>... use (or not use) `set` prefixes?
 
 Just as you can choose to use JavaBeans-style names for property getters
 (`getFoo()` instead of plain `foo()`) in your value class, you can use them for
@@ -62,13 +62,13 @@ abstract class Animal {
 }
 ```
 
-## ... use different names besides `builder()`/`Builder`/`build()`? {#build_names}
+## <a name="build_names"></a>... use different names besides `builder()`/`Builder`/`build()`?
 
 Use whichever names you like; AutoValue doesn't actually care.
 
 (We would gently recommend these names as conventional.)
 
-## ... specify a default value for a property? {#default}
+## <a name="default"></a>... specify a default value for a property?
 
 What should happen when a caller does not supply a value for a property before
 calling `build()`? If the property in question is [nullable](howto.md#nullable),
@@ -105,7 +105,7 @@ abstract class Animal {
 }
 ```
 
-## ... initialize a builder to the same property values as an existing value instance {#to_builder}
+## <a name="to_builder"></a>... initialize a builder to the same property values as an existing value instance
 
 Suppose your caller has an existing instance of your value class, and wants to
 change only one or two of its properties. Of course, it's immutable, but it
@@ -120,7 +120,7 @@ your abstract builder type, to your value class. AutoValue will implement it.
   public abstract Builder toBuilder();
 ```
 
-## ... include `with-` methods on my value class for creating slightly altered instances? {#withers}
+## <a name="withers"></a>... include `with-` methods on my value class for creating slightly altered instances?
 
 This is a somewhat common pattern among immutable classes. You can't have
 setters, but you can have methods that act similarly to setters by returning a
@@ -156,7 +156,7 @@ public abstract class Animal {
 Note that it's your free choice what to make public (`toBuilder`, `withName`,
 neither, or both).
 
-## ... validate property values? {#validate}
+## <a name="validate"></a>... validate property values?
 
 Validating properties is a little less straightforward than it is in the
 [non-builder case](howto.md#validate).
@@ -196,7 +196,7 @@ public abstract class Animal {
 }
 ```
 
-## ... normalize (modify) a property value at `build` time? {#normalize}
+## <a name="normalize"></a>... normalize (modify) a property value at `build` time?
 
 Suppose you want to convert the animal's name to lower case.
 
@@ -237,14 +237,14 @@ been set on the `Builder`. If no value has been set for a non-[nullable]
 Getters should generally only be used within the `Builder` as shown, so they are
 not public.
 
-## ... expose *both* a builder *and* a factory method? {#both}
+## <a name="both"></a>... expose *both* a builder *and* a factory method?
 
 If you use the builder option, AutoValue will not generate a visible constructor
 for the generated concrete value class. If it's important to offer your caller
 the choice of a factory method as well as the builder, then your factory method
 implementation will have to invoke the builder itself.
 
-## ... use a collection-valued property? {#collection}
+## <a name="collection"></a>... use a collection-valued property?
 
 Value objects should be immutable, so if a property of one is a collection then
 that collection should be immutable too. We recommend using Guava's [immutable
@@ -290,7 +290,7 @@ public abstract class Animal {
 
 [immutable collections]: https://github.com/google/guava/wiki/ImmutableCollectionsExplained
 
-### ... let my builder *accumulate* values for a collection-valued property (not require them all at once)? {#accumulate}
+### <a name="accumulate"></a>... let my builder *accumulate* values for a collection-valued property (not require them all at once)?
 
 Instead of defining a setter for an immutable collection `foos`, you can define
 a method `foosBuilder()` that returns the associated builder type for that
@@ -347,7 +347,7 @@ Instead they are forced to hold the builder itself in a temporary variable:
 
 One solution for this problem is just below.
 
-### ... accumulate values for a collection-valued property, without "breaking the chain"? {#add}
+### <a name="add"></a>... accumulate values for a collection-valued property, without "breaking the chain"?
 
 Another option is to keep `countriesBuilder()` itself non-public, only use it to
 implement a public `addCountry` method:
diff --git a/value/userguide/builders.md b/value/userguide/builders.md
index a11e799d..37f137da 100644
--- a/value/userguide/builders.md
+++ b/value/userguide/builders.md
@@ -9,16 +9,15 @@ Fortunately, AutoValue can generate builder classes too! This page explains how.
 Note that we recommend reading and understanding the basic usage shown in the
 [introduction](index.md) first.
 
-<!-- TODO: table of contents that works both internal/external -->
 
-## How to use AutoValue with Builders {#howto}
+## How to use AutoValue with Builders<a name="howto"></a>
 
 As explained in the introduction, the AutoValue concept is that **you write an
 abstract value class, and AutoValue implements it**. Builder generation works in
 the exact same way: you also create an abstract builder class, nesting it inside
 your abstract value class, and AutoValue generates implementations for both.
 
-### In `Animal.java` {#example_java}
+### In `Animal.java`<a name="example_java"></a>
 
 ```java
 import com.google.auto.value.AutoValue;
@@ -45,7 +44,7 @@ Note that in real life, some classes and methods would presumably be public and
 have **Javadoc**. We're leaving these off in the User Guide only to keep the
 examples clean and short.
 
-### Usage {#usage}
+### Usage<a name="usage"></a>
 
 ```java
 public void testAnimal() {
@@ -62,19 +61,19 @@ public void testAnimal() {
 }
 ```
 
-### What does AutoValue generate? {#generated}
+### What does AutoValue generate?<a name="generated"></a>
 
 For the `Animal` example shown above, here is [typical code AutoValue might
 generate](generated-builder-example.md).
 
-## Warnings {#warnings}
+## Warnings<a name="warnings"></a>
 
 Be sure to put the static `builder()` method directly in your value class (e.g.,
 `Animal`) and not the nested abstract `Builder` class. That ensures that the
 `Animal` class is always initialized before `Builder`. Otherwise you may be
 exposing yourself to initialization-order problems.
 
-## How do I... {#howto}
+## <a name="howto"></a>How do I...
 
 *   ... [use (or not use) `set` **prefixes**?](builders-howto.md#beans)
 *   ... [use different **names** besides `builder()`/`Builder`/`build()`?]
diff --git a/value/userguide/howto.md b/value/userguide/howto.md
index e0777d55..574d0aea 100644
--- a/value/userguide/howto.md
+++ b/value/userguide/howto.md
@@ -36,11 +36,11 @@ How do I...
     API?](#public_constructor)
 *   ... [use AutoValue on an **interface**, not abstract class?](#interface)
 
-## ... also generate a builder for my value class? {#builder}
+## <a name="builder"></a>... also generate a builder for my value class?
 
 Please see [AutoValue with builders](builders.md).
 
-## ... use AutoValue with a nested class? {#nested}
+## <a name="nested"></a>... use AutoValue with a nested class?
 
 AutoValue composes the generated class name in the form
 `AutoValue_`*`Outer_Middle_Inner`*.
@@ -58,7 +58,7 @@ class Outer {
       ...
 ```
 
-## ... use (or not use) JavaBeans-style name prefixes? {#beans}
+## <a name="beans"></a>... use (or not use) JavaBeans-style name prefixes?
 
 Some developers prefer to name their accessors with a `get-` or `is-` prefix,
 but would prefer that only the "bare" property name be used in `toString` and
@@ -74,7 +74,7 @@ Note that, in keeping with the JavaBeans specification, the `is-` prefix is only
 allowed on `boolean`-returning methods. `get-` is allowed on any type of
 accessor.
 
-## ... use nullable properties? {#nullable}
+## <a name="nullable"></a>... use nullable properties?
 
 Ordinarily the generated constructor will reject any null values. If you want to
 accept null, simply apply any annotation named `@Nullable` to the appropriate
@@ -96,7 +96,7 @@ This example also shows annotating the corresponding `create` parameter with
 `@Nullable`. AutoValue does not actually require this annotation, only the one
 on the accessor, but we recommended it as useful documentation to your caller.
 
-## ... perform other validation? {#validate}
+## <a name="validate"></a>... perform other validation?
 
 Null checks are added automatically (as [above](#nullable)). For other types of
 precondition checks or pre-processing, just add them to your factory method:
@@ -108,7 +108,7 @@ static MyType create(String first, String second) {
 }
 ```
 
-## ... use a property of a mutable type? {#mutable_property}
+## <a name="mutable_property"></a>... use a property of a mutable type?
 
 First, check if the mutable type has a corresponding immutable cousin. For
 example, the types `List<String>` and `String[]` have the immutable counterpart
@@ -152,7 +152,7 @@ public abstract class MutableExample {
 
 Note: this is a perfectly ugly workaround, not a sensible practice!
 
-## ... use a custom implementation of `equals`, etc.? {#custom}
+## <a name="custom"></a>... use a custom implementation of `equals`, etc.?
 
 Simply write your custom implementation; AutoValue will notice this and will
 skip generating its own. Your hand-written logic will thus be inherited on the
@@ -184,12 +184,12 @@ class PleaseOverrideExample extends SuperclassThatDefinesToString {
 
 <!-- TODO(kevinb): should the latter part have been split out? -->
 
-## ... have multiple `create` methods, or name it/them differently? {#create}
+## <a name="create"></a>... have multiple `create` methods, or name it/them differently?
 
 Just do it! AutoValue doesn't actually care. This [best practice item]
 (practices.md#one_reference) may be relevant.
 
-## ... ignore certain properties in `equals`, etc.? {#ignore}
+## <a name="ignore"></a>... ignore certain properties in `equals`, etc.?
 
 Suppose your value class has an extra field that shouldn't be included in
 `equals` or `hashCode` computations. One common reason is that it is a "cached"
@@ -242,31 +242,31 @@ abstract class IgnoreExample {
 Note that in both cases the field ignored for `equals` and `hashCode` is also
 ignored by `toString`; to AutoValue it simply doesn't exist.
 
-## ... have AutoValue also implement abstract methods from my supertypes? {#supertypes}
+## <a name="supertypes"></a>... have AutoValue also implement abstract methods from my supertypes?
 
 AutoValue will recognize every abstract accessor method whether it is defined
 directly in your own hand-written class or in a supertype.
 
 <!-- TODO(kevinb): what about the order? -->
 
-## ... use AutoValue with a generic class? {#generic}
+## <a name="generic"></a>... use AutoValue with a generic class?
 
 There's nothing to it: just add type parameters to your class and to your call
 to the generated constructor.
 
-## ... make my class Java- or GWT-serializable? {#serialize}
+## <a name="serialize"></a>... make my class Java- or GWT-serializable?
 
 Just add `implements Serializable` or the `@GwtCompatible(serializable = true)`
 annotation (respectively) to your hand-written class; it (as well as any
 `serialVersionUID`) will be duplicated on the generated class, and you'll be
 good to go.
 
-## ... apply an annotation to a generated field? {#annotate_field}
+## <a name="annotate_field"></a>... apply an annotation to a generated field?
 
 Your only option is to put the same annotation on your hand-written abstract
 accessor method, if possible.
 
-## ... use AutoValue to implement an annotation type? {#annotation}
+## <a name="annotation"></a>... use AutoValue to implement an annotation type?
 
 Most users should never have the need to programmatically create "fake"
 annotation instances. But if you do, using `@AutoValue` in the usual way will
@@ -294,7 +294,7 @@ public class Names {
 For more details, see the [`AutoAnnotation` javadoc]
 (http://github.com/google/auto/blob/master/value/src/main/java/com/google/auto/value/AutoAnnotation.java#L24).
 
-## ... also include setter (mutator) methods? {#setters}
+## <a name="setters"></a>... also include setter (mutator) methods?
 
 You can't; AutoValue only generates immutable value classes.
 
@@ -303,7 +303,7 @@ questionable practice in the first place. Equal instances of a value class are
 treated as *interchangeable*, but they can't truly be interchangeable if one
 might be mutated and the other not.
 
-## ... also generate `compareTo`? {#compareTo}
+## <a name="compareTo"></a>... also generate `compareTo`?
 
 AutoValue intentionally does not provide this feature. It is better for you to
 roll your own comparison logic using the new methods added to [`Comparator`]
@@ -316,14 +316,14 @@ Since these mechanisms are easy to use, require very little code, and give you
 the flexibility you need, there's really no way for AutoValue to improve on
 them!
 
-## ... use a primitive array for a property value? {#primitive_array}
+## <a name="primitive_array"></a>... use a primitive array for a property value?
 
 Go right ahead! AutoValue will generate code that acts on the *values* stored
 the array, not the object identity of the array itself, which is (with virtual
 certainty) what you want. Heed the warnings given above about [mutable
 properties](#mutable_property).
 
-## ... use an object array for a property value? {#object_array}
+## <a name="object_array"></a>... use an object array for a property value?
 
 This is not allowed. Object arrays are very badly-behaved and unlike primitive
 arrays, they can be replaced with a proper `List` implementation for very little
@@ -333,24 +333,24 @@ added cost.
 If it's important to accept an object array at construction time, refer to the
 *first* example shown [here](#mutable_property).
 
-## ... have one `@AutoValue` class extend another? {#inherit}
+## <a name="inherit"></a>... have one `@AutoValue` class extend another?
 
 This ability is intentionally not supported, because there is no way to do it
 correctly. See *Effective Java, 2nd Edition* Item 8.
 
-## ... keep my accessor methods private? {#private_accessors}
+## <a name="private_accessors"></a>... keep my accessor methods private?
 
 We're sorry. This is one of the rare and unfortunate restrictions AutoValue's
 approach places on your API. Your accessor methods don't have to be *public*,
 but they must be at least package-visible.
 
-## ... expose a constructor, not factory method, as my public creation API? {#public_constructor}
+## <a name="public_constructor"></a>... expose a constructor, not factory method, as my public creation API?
 
 We're sorry. This is one of the rare restrictions AutoValue's approach places on
 your API. However, note that static factory methods are recommended over public
 constructors by *Effective Java*, Item 1.
 
-## ... use AutoValue on an interface, not abstract class? {#interface}
+## <a name="interface"></a>... use AutoValue on an interface, not abstract class?
 
 Interfaces are not allowed. The only advantage of interfaces we're aware of is
 that you can omit `public abstract` from the methods. That's not much. On the
diff --git a/value/userguide/index.md b/value/userguide/index.md
index 1f08d280..590a8234 100644
--- a/value/userguide/index.md
+++ b/value/userguide/index.md
@@ -12,9 +12,8 @@
 >
 > -- *Joshua Bloch, author, Effective Java*
 
-<!-- TODO: table of contents that works both internal/external -->
 
-## Background {#background}
+## <a name="background"></a>Background
 
 **Value classes** are extremely common in Java projects. These are classes for
 which you want to treat any two instances with suitably equal field values as
@@ -35,7 +34,7 @@ code almost any aspect of your class exactly the way you want it.
 This page will walk you through how to use AutoValue. Looking for a little more
 persuasion? Please see [Why AutoValue?](why.md).
 
-## How to use AutoValue {#howto}
+## <a name="howto"></a>How to use AutoValue
 
 The AutoValue concept is extremely simple: **You write an abstract class, and
 AutoValue implements it.** That is all there is to it; there is literally *no*
@@ -45,7 +44,7 @@ configuration.
 builder class. If you're more interested in the builder support, continue
 reading at [AutoValue with Builders](builders.md) instead.
 
-### In your value class {#example_java}
+### <a name="example_java"></a>In your value class
 
 Create your value class as an *abstract* class, with an abstract accessor method
 for each desired property, and bearing the `@AutoValue` annotation.
@@ -69,7 +68,7 @@ Note that in real life, some classes and methods would presumably be public and
 have Javadoc. We're leaving these off in the User Guide only to keep the
 examples short and simple.
 
-### In `pom.xml` {#example_pom}
+### In `pom.xml`
 
 Maven users, add the following to your configuration:
 
@@ -82,7 +81,7 @@ Maven users, add the following to your configuration:
 </dependency>
 ```
 
-### Usage {#usage}
+### <a name="usage"></a>Usage
 
 Your choice to use AutoValue is essentially *API-invisible*. That means that to
 the consumer of your class, your class looks and functions like any other. The
@@ -105,7 +104,7 @@ public void testAnimal() {
 }
 ```
 
-### What's going on here? {#whats_going_on}
+### <a name="whats_going_on"></a>What's going on here?
 
 AutoValue runs inside `javac` as a standard annotation processor. It reads your
 abstract class and infers what the implementation class should look like. It
@@ -131,7 +130,7 @@ generate](generated-example.md).
 Note that *consumers* of your value class *don't need to know any of this*. They
 just invoke your provided factory method and get a well-behaved instance back.
 
-## Warnings {#warnings}
+## <a name="warnings"></a>Warnings
 
 Be careful that you don't accidentally pass parameters to the generated
 constructor in the wrong order. You must ensure that **your tests are
@@ -146,11 +145,11 @@ Never persist the result of `hashCode` or use it for any other unintended
 purpose, and be careful never to depend on the order your values appear in
 unordered collections like `HashSet`.
 
-## Why should I use AutoValue? {#why}
+## <a name="why"></a>Why should I use AutoValue?
 
 See [Why AutoValue?](why.md).
 
-## How do I... {#more_howto}
+## <a name="more_howto"></a>How do I...
 
 How do I...
 
@@ -186,7 +185,7 @@ How do I...
 
 <!-- TODO(kevinb): should the above be only a selected subset? -->
 
-## More information {#more}
+## <a name="more"></a>More information
 
 See the links in the sidebar at the top left.
 
diff --git a/value/userguide/performance.md b/value/userguide/performance.md
index 1ad6c3b9..36d4315e 100644
--- a/value/userguide/performance.md
+++ b/value/userguide/performance.md
@@ -1,6 +1,6 @@
 # Performance notes
 
-TODO(kevinb): write a real page
+TODO: write a real page
 
 *   should perform like a hand-written class after HotSpot compiles it
     (generated accessors can be inlined)
diff --git a/value/userguide/practices.md b/value/userguide/practices.md
index c0c79b76..9e7320b6 100644
--- a/value/userguide/practices.md
+++ b/value/userguide/practices.md
@@ -1,14 +1,13 @@
 # Best practices
 
-[TOC]
 
-## "Equals means interchangeable" {#interchangeable}
+## <a name="interchangeable"></a>"Equals means interchangeable"
 
 Don't use AutoValue to implement value semantics unless you really want value
 semantics. In particular, you should never care about the difference between two
 equal instances.
 
-## Avoid mutable property types {#mutable_properties}
+## <a name="mutable_properties"></a>Avoid mutable property types
 
 Avoid mutable types, including arrays, for your properties, especially if you
 make your accessor methods `public`. The generated accessors don't copy the
@@ -28,7 +27,7 @@ public abstract class ListExample {
 }
 ```
 
-## Keep behavior simple and dependency-free {#simple}
+## <a name="simple"></a>Keep behavior simple and dependency-free
 
 Your class can (and should) contain *simple* intrinsic behavior. But it
 shouldn't require complex dependencies and shouldn't access static state.
@@ -40,7 +39,7 @@ actually needs to be mocked or faked, split it into a separate type that is
 *not* a value type. Otherwise it permits an instance with "real" behavior and
 one with "mock/fake" behavior to be `equals`, which does not make sense.
 
-## One reference only {#one_reference}
+## <a name="one_reference"></a>One reference only
 
 Other code in the same package will be able to directly access the generated
 class, but *should not*. It's best if each generated class has one and only one
@@ -50,7 +49,7 @@ delegate to the same hand-written method, so there is still only one point of
 contact with the generated code. This way, you have only one place to insert
 precondition checks or other pre- or postprocessing.
 
-## Mark all concrete methods `final` {#final}
+## <a name="final"></a>Mark all concrete methods `final`
 
 Consider that other developers will try to read and understand your value class
 while looking only at your hand-written class, not the actual (generated)
@@ -59,7 +58,7 @@ to wonder whether the generated subclass might be overriding them. This is
 especially helpful if you are *[underriding](howto.md#custom)* `equals`,
 `hashCode` or `toString`!
 
-## Maybe add an explicit, inaccessible constructor {#constructor}
+## <a name="constructor"></a>Maybe add an explicit, inaccessible constructor
 
 There are a few small advantages to adding a package-private, parameterless
 constructor to your abstract class. It prevents unwanted subclasses, and