Reduce visual clutter of multiline start when possible

[estebank]

When a span starts on a line with nothing but whitespace to the left,
and there are no other annotations in that line, simplify the visual
representation of the span.

Go from:

error[E0072]: recursive type `A` has infinite size
--> file2.rs:1:1
|
1 | struct A{
| _^ starting here...
2 | | a:A,3 | | }
| |_^ ...ending here:recursive type has infinite size
|

To:

error[E0072]: recursive type `A` has infinite size
--> file2.rs:1:1
|
1 | / struct A{2 | | a:A,3 | | }
| |_^ recursive type has infinite size

Re: #38246.

r? @nikomatsakis CC @jonathandturner

[estebank]

instead of

[nikomatsakis]

Seems better. I would still like to make progress on only highlighting the struct name etc, though I know that's a deeper edit.

[nikomatsakis]

I wonder if the ...ending here: feels confusing without the starting here...?

[estebank]

I would still like to make progress on only highlighting the struct name etc, though I know that's a deeper edit.

#41214 is an attempt at doing the smallest patch possible that would accomplish that.

I wonder if the ...ending here: feels confusing without the starting here...?

Would it make sense to remove the starting here.../...ending here completely, @nikomatsakis? I sometimes feel like they might be overpowering the actual messages...

[sophiajt]

@nikomatsakis - seconded on "can we underline just the name". I feel like often, but not always, that's what we want to do.

[nikomatsakis]

Would it make sense to remove the starting here.../...ending here completely, @nikomatsakis? I sometimes feel like they might be overpowering the actual messages...

I've wondered the same. I think quite likely yes.

[Mark-Simulacrum]

Looks like tests need to be fixed here.

[nikomatsakis]

@estebank I like it. One thing I've also wondered: would it be hard to put the label text at the top rather than the bottom? I usually find that a bit more intuitive.

[estebank]

@nikomatsakis it wouldn't be hard to do it, but I've been thinking about doing the following

2 | fn foo(){{
| ____^ -
| | ___________|
| ||
3 | ||
4 | || }}
| ||__- ^
| |_____|

instead of

2 | fn foo(){{
| ___^_______-
| |___|
| ||
3 | ||
4 | || }}
| || - ^
| ||__|_|
| |__|

which wouldn't work with labels (regardless of on top or the bottom). (Then again, it doesn't work with them in the bottom with that change either.)

I'll add the change to do move the labels on the top to this PR.

[estebank]

Also just realized, while moving the labels to the beginning, this PR's change is unworkable, as the you need the line for the label after the first line of the span to be able to show the text. Keeping it in the end, either always or only when the multiline span is the only thing being shown, would be necessary to decrease the vertical space waste.

[nikomatsakis]

@estebank

Also just realized, while moving the labels to the beginning, this PR's change is unworkable, as the you need the line for the label after the first line of the span to be able to show the text.

Oh, hmm, good point! You could preserve the total number of lines like so:

error[E0072]: recursive type `A` has infinite size
--> file2.rs:1:1
|
1 | struct A {
| _^ starting here...
2 | | a: A,
3 | \ }
|

But I imagine that part of the point here is also just not to interject stuff into the middle.

[nikomatsakis]

@estebank ok well let's leave labels at the end for now. PR seems good to me. Did you plan to make more changes?

[estebank]

@nikomatsakis I just need to clean up the last commit. Shall we merge this with the removal of the starting here.../...ending here text once I've fixed the PR?

[nikomatsakis]

Shall we merge this with the removal of the starting here.../...ending here text once I've fixed the PR?

👍 from me

[nikomatsakis]

@estebank

Shall we merge this with the removal of the starting here.../...ending here text once I've fixed the PR?

👍

[estebank]

@nikomatsakis, I'll r=you once I've fixed the current output discrepancy:

[00:58:15] expected output:[00:58:15] ------
[00:58:15] error: foo
[00:58:15] --> test.rs:3:3[00:58:15] |
[00:58:15]3 | X0Y0[00:58:15] | ____^__-
[00:58:15] | | ___|
[00:58:15]4 | || Y1X1[00:58:15] | ||____-__^ `X` is a good letter
[00:58:15] | |_____|
[00:58:15] | `Y` is a good letter too
[00:58:15][00:58:15] ------
[00:58:15] actual output:[00:58:15] ------
[00:58:15] error: foo
[00:58:15] --> test.rs:3:3[00:58:15] |
[00:58:15]3 | X0Y0[00:58:15] | ____^__-
[00:58:15]4 | || Y1X1[00:58:15] | ||____-__^ `X` is a good letter
[00:58:15] | |_____|
[00:58:15] | `Y` is a good letter too

Is there a way to run only these tests using x.py? I guess "./build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "-j" "4" "--target" "x86_64-unknown-linux-gnu" "--release" "--locked" "--manifest-path" "/checkout/src/rustc/Cargo.toml" "--features" "syntax:0.0.0" "-p" "syntax_pos:0.0.0" "-p" "syntax_ext:0.0.0" "--" should work, right?

Also, I'll have to rebase to fix tests that have changed since I created this PR.

[nikomatsakis]

@estebank what test is it? A useful option is --on-fail, so something like this:

./x.py ... --on-fail bash

will put you into a shell with all the environment and stuff setup. It'll print the last command (which failed). So you can copy-and-paste that command and then re-run to your heart's content.

[estebank]

@nikomatsakis it's src/libsyntax/test_snippet.rs, but compile-fail-fulldeps/proc-macro fails on my environment, so I wasn't able to test locally. I had tried ./x.py test src/libsyntax --stage 1 -j4 but didn't seem to run any tests, but trying it again it actually worked, weird. Must have made a mistake. Thanks for the tip, that'll will come in handy.

[estebank]

@bors r=nikomatsakis

[bors]

📌 Commit cc07c35 has been approved by nikomatsakis

[bors]

⌛ Testing commit cc07c35 with merge 4ed9500...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 4ed9500 to master...