Latest docs on successful build 5965 auto-pushed to gh-pages

bugpattern/BindingToUnqualifiedCommonType.md

@@ -16,7 +16,7 @@ To make changes, edit the @BugPattern annotation or the explanation in docs/bugp
 ## The problem
 Guice bindings are keyed by a pair of (optional Annotation, Type).
 
-In most cirumstances, one doesn't need the annotation, as there's really just
+In most circumstances, one doesn't need the annotation, as there's really just
 one active implementation:
 
 ```java

bugpattern/IsInstanceOfClass.md

@@ -33,7 +33,7 @@ equal to `Class` (i.e. lhs is equal to `Class.class`).
 ```
 
 To test if the type represented by a class literal is a subtype of the type
-reprsented by some other class literal, `isAssignableFrom` should be used
+represented by some other class literal, `isAssignableFrom` should be used
 instead:
 
 ```java

bugpattern/OverridesGuiceInjectableMethod.md

@@ -20,7 +20,7 @@ with `@com.google.inject.Inject`, Guice will inject it even if it itself is not
 annotated. This differs from the behavior of methods that override
 `@javax.inject.Inject` methods since according to the JSR-330 spec, a method
 that overrides a method annotated with `@javax.inject.Inject` will not be
-injected unless it iself is annotated with `@Inject`. Because of this
+injected unless it itself is annotated with `@Inject`. Because of this
 difference, it is recommended that you annotate this method explicitly.
 
 ## Suppression

bugpattern/RedundantOverride.md

@@ -14,7 +14,7 @@ To make changes, edit the @BugPattern annotation or the explanation in docs/bugp
 
 ## The problem
 An override of a method that delegates its implementation to the super method is
-redudant, and can be removed.
+redundant, and can be removed.
 
 For example, the `equals` method in the following class implementation can be
 deleted.

bugpattern/StaticAssignmentOfThrowable.md

@@ -15,10 +15,11 @@ To make changes, edit the @BugPattern annotation or the explanation in docs/bugp
 
 ## The problem
 The problem we're trying to prevent is unhelpful stack traces that don't contain
-information about where the Exception was thrown from. This probem can sometimes
-arise when an attempt is being made to cache or reuse a Throwable (often, a
-particular Exception). In this case, consider whether this is really is
-necessary: it often isn't. Could a Throwable simply be instantiated when needed?
+information about where the Exception was thrown from. This problem can
+sometimes arise when an attempt is being made to cache or reuse a Throwable
+(often, a particular Exception). In this case, consider whether this is really
+is necessary: it often isn't. Could a Throwable simply be instantiated when
+needed?
 
 ``` {.bad}
 // this always has the same stack trace