fix overflow due to multiline error span

[oli-obk]

No description provided.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[mitaa]

... oops.

Thanks for fixing this. (I guess adding yet another testcase, here for "end-highlighted-multiline-but-less-than-6-lines-span", would be overkill)

[oli-obk]

@mitaa: the testcase would not help, we need to enable debug assertions in travis and homu. The test case for this situation was 10% of compile-fail ;)

[pnkfelix]

we need to enable debug assertions in travis and homu

In particular, I believe we have at least one buildbot that has --enable-debug turned one; but I also think it does not run the test suite. See in particular #27010 which suggested adding such a configuration, and rust-lang-deprecated/rust-buildbot#38 which turned on gating on it (but it does not run make check)

[nikomatsakis]

@oli-obk seems like it's still worth having focused tests, since many of us (e.g., me) run tests with --enable-debug-assertions

[nikomatsakis]

But then there is a test? (Also, the travis failures look...bogus to me?)

[mitaa]

But then there is a test? (Also, the travis failures look...bogus to me?)

Yes, but since the code path was never used, due to overflow, it is naturally off by one. (>=, instead of >)

Currently, running tests locally.. :-(

[nikomatsakis]

@mitaa

Yes, but since the code path was never used, due to overflow, it is naturally off by one.

I don't understand what you mean by this.

[mitaa]

@nikomatsakis

I don't understand what you mean by this.

Sorry, what I basically meant to say was that there is a test for this, that the travis failure is genuine, and that the final necessary fix is probably to change (hi.line - lo.line) > MAX_SP_LINES, which is off-by-one, to (hi.line - lo.line) >= MAX_SP_LINES

(make check-stage1-syntax passes locally for me with this fix)
(need to rerun make check due to probably bogus debuginfo test failures)

[oli-obk]

Travis likes it now

[nikomatsakis]

@bors r+ rollup

[bors]

📌 Commit 54927ac has been approved by nikomatsakis

[nikomatsakis]

lgtm!