Show multiline spans in full if short enough

[estebank]

When dealing with multiline spans that span few lines, show the complete span instead of restricting to the first character of the first line.

For example, instead of:

% ./rustc file2.rs
error[E0277]: the trait bound `{integer}: std::ops::Add<()>` is not satisfied
  --> file2.rs:13:9
   |
13 |    foo(1 + bar(x,
   |        ^ trait `{integer}: std::ops::Add<()>` not satisfied
   |

show

% ./rustc file2.rs
error[E0277]: the trait bound `{integer}: std::ops::Add<()>` is not satisfied
  --> file2.rs:13:9
   |
13 |      foo(1 + bar(x,
   |  ________^ starting here...
14 | |            y),
   | |_____________^ ...ending here: trait `{integer}: std::ops::Add<()>` not satisfied
   |

The proposal in internals outlines the reasoning behind this.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @arielb1 (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.

[estebank]

This will need to be much lower. I propose a value between 5 and 10.

[fabric-and-ink]

Hi there! I think this is nice work but I am unsure if this is the right way. I would suggest to use the box-drawing characters for the lines. This would result in a cleaner look. Like this

error[E0277]: the trait bound `{integer}: std::ops::Add<()>` is not satisfied
  --> file2.rs:13:9
   |
13 |      foo(1 + bar(x,
   | ┌────────┘ starting here...
14 | │            y),
   | └─────────────┘ ...ending here: trait `{integer}: std::ops::Add<()>` not satisfied
   |

[estebank]

@dawirstejeck as per @nikomatsakis in the original PR:

I am avoiding unicode because many terminals can't handle it, so in the past we've tried to stick to ASCII.

I think it'd be neat if there were a way to probe for unicode awareness and use ascii safe characters or unicode accordingly, but that's beyond the scope of this PR :)

[alexcrichton]

r? @nikomatsakis

Carrying over reviewer from the original PR. Looks like the conclusion there was to close in favor of an internals thread and open up a new one upon reaching consensus.

With my reading of the internals thread it looks like we haven't quite reached consensus yet, but @nikomatsakis seems to have been following more closely than I and may know more! @jonathandturner you were also interested in the first PR so you're likely to be interested in this one :)

[brson]

Neat feature!

[nikomatsakis]

Hmm, so I see that the #[test] infrastructure for testing snippet highlighting has been removed and move to UI tests. That's a bit unfortunate here, as it would have been really easy to make a bunch of tests for edge cases. I'm trying to think now if there is an easy way to reproduce it. Perhaps just adding back the #[test] stuff, but as @jonathandturner pointed out, it IS kind of a pain.

Let me poke around a bit. I'd love to land this PR and don't want to block it on extensive work to build up a nice unit-testing infrastructure -- on the other hand, I'd feel a lot more comfortable if we could just write down tests for various edge cases (even if they don't occur in rustc...yet). The code seems pretty clean but oveall this formatting logic is easier to verify as a block-box, frankly.

[nikomatsakis]

Hmm, so I see that the #[test] infrastructure for testing snippet highlighting has been removed and move to UI tests. That's a bit unfortunate here, as it would have been really easy to make a bunch of tests for edge cases. I'm trying to think now if there is an easy way to reproduce it. Perhaps just adding back the #[test] stuff, but as @jonathandturner pointed out, it IS kind of a pain.

Let me poke around a bit. I'd love to land this PR and don't want to block it on extensive work to build up a nice unit-testing infrastructure -- on the other hand, I'd feel a lot more comfortable if we could just write down tests for various edge cases (even if they don't occur in rustc...yet). The code seems pretty clean but oveall this formatting logic is easier to verify as a block-box, frankly.

[nikomatsakis]

This code confuses me a bit -- why doesn't it have to consider lines at all?

What if the input was like

X0
...
X1
Y0
...
Y1

With two multi-line spans stretching from X0..X1 and Y0..Y1... wouldn't that cause it to indent the Y case even though they do not in fact overlap?

I think I would expect this indentation to be done on the basis not of start_col and end_col but rather a (line, col) pair, or something like that.

[estebank]

Only the line needs to be taken into account. I probably just made a mistake here that, as I didn't have any overlapping example to test against, I didn't catch.

[estebank]

Fixed.

[nikomatsakis]

all the annotations in this vector should be multiline, right? If so, can you add else { panic!("non-multiline annotation inmultiline_annotations!"); } to make this clearer?

[estebank]

Added.

[nikomatsakis]

Bah, I didn't get time to finish implementing that test harness. =(

The basic idea was just going to be adding some #[test] functions to librustc_errors which would gin up a file map etc.

[nikomatsakis]

OK, so, I'm sorry I've been letting the perfect be the enemy of the good here. Let's land this PR and hack on a test harness separately. I've been toying with some stuff locally but the setup is kind of a pain so I don't want to block things on it.

@bors r+

[bors]

📌 Commit 41c9950 has been approved by nikomatsakis

[nikomatsakis]

@bors r-

Actually, I'd still like to know the answer to this question and have this nit addressed.

@estebank, you around?

[estebank]

@nikomatsakis sure thing. I'll update the PR this afternoon.

[estebank]

I've been toying with some stuff locally but the setup is kind of a pain so I don't want to block things on it.

If you publish branch I can use as a base to help, please let me know. Also, #12182 covers exactly that work, I believe.

[nikomatsakis]

@estebank ok I got something working in this branch:

https://github.com/nikomatsakis/rust/tree/multiline-span

In particular, you can just cherry-pick this commit:

nikomatsakis@0166ce0

The tests are all calls to this test_harness() function. You give it the input along with some spans and labels, specified as a string to search for (it takes the Nth match). Then you put in the expected output. You can see that the nested cases look a bit odd.

To run the tests, do make check-stage0-syntax (presuming you are using makefiles; I'm not sure of the x.py way to do this). The only annoying thing is that building libsyntax does take a while: on the other hand, you don't have to build the rest of the compiler if you make changes.

[estebank]

In particular, you can just cherry-pick this commit

Awesome!

Then you put in the expected output. You can see that the nested cases look a bit odd.

It actually looks exactly how I expected it to look, as in, failing in the exact ways I expected it to be failing :)

--> test.rs:3:3
  |
3 |      X0 Y0
  |  _______- starting here...
  |      |
  |      starting here...
4 | ||   X1 Y1
  | |________- ...ending here: `Y` is a good letter too
  |       |
  |       ...ending here: `X` is a good letter

I would like to arrive with you to what the appropriate output for this case would be, where the multispans start (or end) both on the same line. I'm thinking something along the lines of:

--> test.rs:3:3
  |
3 |      X0 Y0
  |  _______- starting here...
  | | ___|
  | ||   starting here...
4 | ||   X1 Y1
  | |+_______- ...ending here: `Y` is a good letter too
  |  |____|
  |       ...ending here: `X` is a good letter

or

--> test.rs:3:3
  |
3 |      X0 Y0
  |  ____-__- starting here...
  | ||   |
  | ||   starting here...
4 | ||   X1 Y1
  | |⊥____-__- ...ending here: `Y` is a good letter too
  |       |
  |       ...ending here: `X` is a good letter

Both cases seem a bit messy, to honest.

This might be not as accurate but more composable:

--> test.rs:3:3
  |
3 |      X0 Y0
  | ++   -  - starting here...
  | ||   |
  | ||   starting here...
4 | ||   X1 Y1
  | ++    -  - ...ending here: `Y` is a good letter too
  |       |
  |       ...ending here: `X` is a good letter

Which for the PR's example would look like:

  --> file2.rs:13:9
   |
13 |      foo(1 + bar(x,
   | +        ^ starting here...
14 | |            y),
   | +             ^ ...ending here: trait `{integer}: std::ops::Add<()>` not satisfied
   |

[nikomatsakis]

@estebank

Both cases seem a bit messy, to honest.

Yes, but this is an extreme case. I mostly want us to do "something sensible". I wonder if we can provide a bit of extra info, though, to help people disambiguate, like a number. Something like this (riffing on my preferred variant):

--> test.rs:3:3
  |
3 |      X0 Y0
  |  _______- starting here... [1]
  | | ___|
  | ||   starting here... [2]
4 | ||   X1 Y1
  | ||_______- ...ending here [2]: `Y` is a good letter too
  |  |____|
  |       ...ending here [1]: `X` is a good letter

Maybe we only show these if things overlap?

[nikomatsakis]

Oh, and I removed the + in favor of just drawing a |, which I think reads a bit better.

[nikomatsakis]

I wouldn't worry about the numbers.

[nikomatsakis]

Left one suggestion. One other thing I'd like: can you give a test with two disjoint ranges (touching distinct lines)?

I confess I didn't read the actual code in detail, but your comments gave me confidence that I could read it if ever I had to. =) The tests seem quite good though.

Basically r=me modulo the suggested refactoring and test (and feel free to tell me if you think my suggestion is not a good one).

[nikomatsakis]

Left one suggestion. One other thing I'd like: can you give a test with two disjoint ranges (touching distinct lines)?

I confess I didn't read the actual code in detail, but your comments gave me confidence that I could read it if ever I had to. =) The tests seem quite good though.

Basically r=me modulo the suggested refactoring and test (and feel free to tell me if you think my suggestion is not a good one).

[nikomatsakis]

Nit: this code might be cleaner if you made a struct for MultilineAnnotation, and then adjusted the enum to wrap the struct. Something like:

enum Annotation {
    ...
    Multiline(MultilineAnnotation),
    ...
}

struct MultilineAnnotation {
        depth: usize,
        line_start: usize,
        line_end: usize,
}

in that case, the type of multiline_annotations can be Vec<MultilineAnnotation>.

[nikomatsakis]

❤️ loving the comments! ❤️

[estebank]

Left one suggestion. One other thing I'd like: can you give a test with two disjoint ranges (touching distinct lines)?

Added (last two tests).

this code might be cleaner if you made a struct for MultilineAnnotation, and then adjusted the enum to wrap the struct. Something like:

There's some duplication of fields now for this to work, but I don't think it'll make the code any harder to follow.

feel free to tell me if you think my suggestion is not a good one

Other than the issue mentioned above, the suggestion makes sense.

[nikomatsakis]

@bors r+

Very nice.

[bors]

📌 Commit b7982bb has been approved by nikomatsakis

[bors]

⌛️ Testing commit b7982bb with merge b30022a...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-cargotest, auto-linux-64-cross-freebsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-rustbuild
Approved by: nikomatsakis
Pushing b30022a to master...