Regression on beta: three dots in a trait leads to an infinite loop(?)

[nodakai]

trait T { ... }

(Yes, just a single line.)

$ ulimit -t 3
$ multirust run stable rustc ~tmp/lone-incl-range-in-trait.rs
/tmp/nodakai//lone-incl-range-in-trait.rs:1:11: 1:14 error: expected one of `const`, `extern`, `fn`, `type`, or `unsafe`, found `...`
/tmp/nodakai//lone-incl-range-in-trait.rs:1 trait T { ... }
                                                      ^~~
error: aborting due to previous error
$ multirust run stable rustc --version
rustc 1.7.0 (a5d1e7a59 2016-02-29)
$ multirust run beta rustc ~tmp/lone-incl-range-in-trait.rs
zsh: cpu limit exceeded  multirust run beta rustc ~tmp/lone-incl-range-in-trait.rs
$ multirust run beta rustc --version
rustc 1.8.0-beta.1 (facbfdd71 2016-03-02)
$ multirust run nightly rustc ~tmp/lone-incl-range-in-trait.rs
zsh: cpu limit exceeded  multirust run nightly rustc ~tmp/lone-incl-range-in-trait.rs
$ multirust run nightly rustc --version
rustc 1.9.0-nightly (21922e1f4 2016-03-21)

Possibly related to #32245 ?

Like #32445 , it was found during make check-docs. One doctest contained three dots probably just to mean some codes had been omitted.

• https://doc.rust-lang.org/error-index.html#E0273

[nodakai]

Rustdoc not only falls into an infinite loop but also consumes infinitely growing amount of memory (only) when the bad trait with dots is surrounded by definitions:

```
const X: i32 = 0;
trait T { ... }
const Y: i32 = 0;
```

This must have caused the Travis failure in #31689

[durka]

#32267 (the fix for #32245) does not fix this.

[durka]

I don't think this is about inclusive ranges. trait T { .. } or even trait T { . } seems to do the trick as well.

[alexcrichton]

triage: I-nominated

[nikomatsakis]

cc @nrc

[nikomatsakis]

triage: P-high

[nikomatsakis]

My guess is that we are trying to recover from an invalid token but forgetting to bump or eat the token.