Reorder span_suggestions to appear below main labels #40851

[gaurikholkar-zz]

In #40851, owing to the the fact that suggestions have been moved inline, no doubt is a good idea. But in the case where the span of the suggestion and the span of the main comment coincide, it currently causes the suggestion to appear before the main comment, which seems suboptimal. We should reorder suggestions so they appear below other labels.

Here is the example,

fn main() {
    let v = vec![String::from("oh no")];
    
    let e = v[0];
}

error[E0507]: cannot move out of indexed content
 --> ex1.rs:4:13
  |
4 |     let e = v[0];
  |             ^^^^
  |             |
  |             help: consider using a reference instead `&v[0]`
  |             cannot move out of indexed content

error: aborting due to previous error

In the move_error.rs

let initializer =
                    e.init.as_ref().expect("should have an initializer to get an error");
                if let Ok(snippet) = bccx.tcx.sess.codemap().span_to_snippet(initializer.span) {
                    err.span_suggestion(initializer.span,
                                        "consider using a reference instead",format!("&{}", snippet));
                }
            }

cc @nikomatsakis @estebank

[nikomatsakis]

cc @oli-obk

[nikomatsakis]

This seems like it could make a good mentorship issue. @estebank or @oli-obk, do you want to write up instructions?

[oli-obk]

This is somewhat related to #41695

Here we are already duplicating the error in the main message and again in the note. (See https://github.com/rust-lang/rust/blob/master/src/librustc_borrowck/borrowck/gather_loans/move_error.rs#L138-L144 for the creation of the error and note)

In this case I'd just remove the duplication of the message and only show the suggestion inline. But I don't know the rules around this duplication stuff, although I personally dislike it if the message is duplicated.

Back to the topic:

I think the issue is that https://github.com/rust-lang/rust/blob/master/src/librustc_errors/emitter.rs#L322-L344 sorts the labels according to their start/end column position.

So if we have three labels AA, AB, BB where AA and AB have the same span, we might get AA, AB, BB after sorting, then reverse it to BB, AB, AA, but we wanted to get BB, AA, AB (everything with the same span should keep its original order)

Right now emitter does: sort notes, reverse notes.
So we probably need to: reverse notes, sort notes, reverse notes.

[nikomatsakis]

@oli-obk yes, I agree that this is strongly related to #41695, though I guess that we can have the problem even if the messages aren't the same. It seems like suggestions ought to come last -- I wonder if the general rule should be that you add labels in order of precedence anyhow (i.e., given two labels with same span, we'd prefer the one added first?).

[oli-obk]

This can be tagged E-mentor and E-easy. Instructions are given in my previous comment. Feel free to ask me any questions about this here or on irc.

[imanti]

I'd like to take this one if it's not yet assigned.

[oli-obk]

@imanti go ahead! It's all yours

[imanti]

@oli-obk the problem with the first example is how the list of annotations is being sorted: since both annotation have the exact same values in all fields except the message string, it will always find the suggestion to be bigger. As you pointed out, in these lines https://github.com/rust-lang/rust/blob/master/src/librustc_errors/emitter.rs#L322-L344 the list is being sorted and then reversed. So no matter how's the order of the list before those two lines, it'll always end up with the suggestion first.

Consider this snippet (it has the real values for the annotations):

fn main() {

#[derive(Clone, Debug, PartialOrd, Ord, PartialEq, Eq)]
pub struct Annotation {
    pub start_col: u32,
    pub end_col: u32,
    pub is_primary: bool,
    pub label: Option<String>,
}

let mut a : Vec<Annotation> = Vec::new();
a.push(Annotation {start_col: 12, end_col: 16, is_primary: true, 
                   label: Some(String::from("help: consider using a reference instead `&v[0]`"))});
a.push(Annotation {start_col: 12, end_col: 16, is_primary: true, 
                   label: Some(String::from("cannot move out of indexed content"))});

println!("{:?}", a);
a.sort();
println!("{:?}", a);
}

I'm not an expert at all in rust code, but I can't think in a way of generically order these messages without knowing which one is a suggestion and which one not. So let me know your ideas.

[oli-obk]

The sorting could be done with sort_by_key to not sort by the message string, which is a useless criterion for sorting anyway

[imanti]

nice!! I'll try it tonigth at home and let you know.

[imanti]

@oli-obk sorting by key works as expected:

error[E0507]: cannot move out of indexed content
 --> test_case.rc:4:13
  |
4 |     let e = v[0];
  |             ^^^^
  |             |
  |             cannot move out of indexed content
  |             help: consider using a reference instead `&v[0]`

error: aborting due to previous error

I created branch here with the changes (just two lines).
Do you think it is worth finding other examples where span ordering is wrong before doing the pull request?

[oli-obk]

We'll find those examples when the tests fail 😉 could you run the ui tests and fix them with the command line the test failure gives you? Then we can see the changes in the PR.

[gaurikholkar-zz]

Is someone still working on this?

[gaurikholkar-zz]

@oli-obk I was trying to build , running ./x.py build --stage 1.
Gives me this error

[oli-obk]

hmm... I haven't seen that one, But I've noticed that x.py often breaks if the submodules are messed up. You can try running git submodule update --init --recursive.

If it still doesn't work, try starting out from a clean checkout of the rust repository

[gaurikholkar-zz]

error[E0507]: cannot move out of indexed content
 --> e1.rs:3:9
  |
3 | let e = v[0];
  |         ^^^^
  |         |
  |         cannot move out of indexed content
  |         help: consider using a reference instead `&v[0]`

error: aborting due to previous error

Suggestions on the output?
Should I open a PR with the changed ui and compile-fail tests?

[gaurikholkar-zz]

Here are the test fixes

[oli-obk]

Should I open a PR with the changed ui and compile-fail tests?

Yes. Please do so. The tests look much more readable after the changes

[evolarium]

@oli-obk I had a look at this earlier and was wondering if there was any reason to not do a reverse sort instead of the reverse, sort, reverse steps. Like so:

annotations.sort_by(|a,b| b.start_col.cmp(&a.start_col));

[oli-obk]

That's a great idea. It just never crossed my mind.

[estebank]

This was fixed in #43251.