Wrap advance_to doc to 80 columns
diff --git a/src/discouraged.rs b/src/discouraged.rs
index 3b05588..a86ba0d 100644
--- a/src/discouraged.rs
+++ b/src/discouraged.rs
@@ -6,22 +6,23 @@
pub trait Speculative {
/// Advance this parse stream to the position of a forked parse stream.
///
- /// This is the opposite operation to [`ParseStream::fork`].
- /// You can fork a parse stream, perform some speculative parsing, then join
- /// the original stream to the fork to "commit" the parsing from the fork to
- /// the main stream.
+ /// This is the opposite operation to [`ParseStream::fork`]. You can fork a
+ /// parse stream, perform some speculative parsing, then join the original
+ /// stream to the fork to "commit" the parsing from the fork to the main
+ /// stream.
///
/// If you can avoid doing this, you should, as it limits the ability to
/// generate useful errors. That said, it is often the only way to parse
/// syntax of the form `A* B*` for arbitrary syntax `A` and `B`. The problem
/// is that when the fork fails to parse an `A`, it's impossible to tell
/// whether that was because of a syntax error and the user meant to provide
- /// an `A`, or that the `A`s are finished and its time to start parsing `B`s.
- /// Use with care.
+ /// an `A`, or that the `A`s are finished and its time to start parsing
+ /// `B`s. Use with care.
///
- /// Also note that if `A` is a subset of `B`, `A* B*` can be parsed by parsing
- /// `B*` and removing the leading members of `A` from the repetition, bypassing
- /// the need to involve the downsides associated with speculative parsing.
+ /// Also note that if `A` is a subset of `B`, `A* B*` can be parsed by
+ /// parsing `B*` and removing the leading members of `A` from the
+ /// repetition, bypassing the need to involve the downsides associated with
+ /// speculative parsing.
///
/// [`ParseStream::fork`]: ../struct.ParseBuffer.html#method.fork
///
@@ -29,14 +30,15 @@
///
/// There has been chatter about the possibility of making the colons in the
/// turbofish syntax like `path::to::<T>` no longer required by accepting
- /// `path::to<T>` in expression position. Specifically, according to [RFC 2544],
- /// [`PathSegment`] parsing should always try to consume a following `<` token
- /// as the start of generic arguments, and reset to the `<` if that fails
- /// (e.g. the token is acting as a less-than operator).
+ /// `path::to<T>` in expression position. Specifically, according to [RFC
+ /// 2544], [`PathSegment`] parsing should always try to consume a following
+ /// `<` token as the start of generic arguments, and reset to the `<` if
+ /// that fails (e.g. the token is acting as a less-than operator).
///
- /// This is the exact kind of parsing behavior which requires the "fork, try,
- /// commit" behavior that [`ParseStream::fork`] discourages. With `advance_to`,
- /// we can avoid having to parse the speculatively parsed content a second time.
+ /// This is the exact kind of parsing behavior which requires the "fork,
+ /// try, commit" behavior that [`ParseStream::fork`] discourages. With
+ /// `advance_to`, we can avoid having to parse the speculatively parsed
+ /// content a second time.
///
/// This change in behavior can be implemented in syn by replacing just the
/// `Parse` implementation for `PathSegment`:
@@ -123,9 +125,9 @@
/// ```
///
/// but if parsed using the above speculative parsing, it falls back to
- /// assuming that the `<` is a less-than when it fails to parse the
- /// generic arguments, and tries to interpret the `&'a` as the start of a
- /// labelled loop, resulting in the much less helpful error
+ /// assuming that the `<` is a less-than when it fails to parse the generic
+ /// arguments, and tries to interpret the `&'a` as the start of a labelled
+ /// loop, resulting in the much less helpful error
///
/// ```text
/// error: expected `:`