Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement MultiSpan error reporting #30411

Merged
merged 1 commit into from
Jan 29, 2016
Merged

Conversation

mitaa
Copy link
Contributor

@mitaa mitaa commented Dec 16, 2015

This allows to render multiple spans on one line, or to splice multiple replacements into a code suggestion.

fixes #28124

@rust-highfive
Copy link
Collaborator

r? @sfackler

(rust_highfive has picked a reviewer for you, use r? to override)

@bors
Copy link
Contributor

bors commented Dec 16, 2015

☔ The latest upstream changes (presumably #30410) made this pull request unmergeable. Please resolve the merge conflicts.

@mitaa
Copy link
Contributor Author

mitaa commented Dec 16, 2015

(rebased)

for sp in msp.spans.as_slice().iter() {
let hi = cm.lookup_char_pos(sp.hi);
if hi.line < (last_line.line_index + 1) {
continue
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit unfortunate.

@mitaa mitaa force-pushed the multispan branch 4 times, most recently from 3817189 to 06dda69 Compare December 17, 2015 14:33
@bors
Copy link
Contributor

bors commented Dec 18, 2015

☔ The latest upstream changes (presumably #30457) made this pull request unmergeable. Please resolve the merge conflicts.

@mitaa mitaa force-pushed the multispan branch 3 times, most recently from 8e858e8 to bce9176 Compare December 19, 2015 05:47
/// and point into the same FileMap.
#[derive(Clone)]
pub struct MultiSpan {
pub spans: SmallVector<Span>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using SmallVector here seemed nice at first because

Since this only matters once we actually want to report something this should probably be Vec<Span>?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I don't think perf in the error case is super-important, so just using Vec is probably better (and save all the changes to SmallVec, which I would otherwise say need some tests).

@mitaa
Copy link
Contributor Author

mitaa commented Dec 20, 2015

I've now implemented interleaved span/code-line rendering, making this possible:

<anon>:1:17: 10:20 warning: unused import, #[warn(unused_imports)] on by default
<anon>:1  use std::cell::{Cell, RefCell, UnsafeCell};
                          ^~~~  ^~~~~~~  ^~~~~~~~~~
<anon>:2  use std::sync::{atomic, mpsc};
                          ^~~~~~  ^~~~
          ...
<anon>:5  use std::cmp;
              ^~~~~~~~
          ...
<anon>:10 use std::iter::once;
              ^~~~~~~~~~~~~~~

But eliding lines like this would make it difficult to find the line in the source once the error messages have been restyled (#3533, #29989), because the line numbers (here line 5) would be missing.
(the lines are elided because a single error may only emit 6 code-lines)

Because of this spans that are automatically grouped would render like this:

<anon>:1:17: 5:13 warning: unused import, #[warn(unused_imports)] on by default
<anon>:1 use std::cell::{Cell, RefCell, UnsafeCell};
                         ^~~~  ^~~~~~~  ^~~~~~~~~~
<anon>:2 use std::sync::{atomic, mpsc};
                         ^~~~~~  ^~~~
<anon>:3 use std::convert::From;
<anon>:4 use std::ops::Deref;
<anon>:5 use std::cmp;
             ^~~~~~~~
<anon>:10:5: 10:20 warning: unused import, #[warn(unused_imports)] on by default
<anon>:10 use std::iter::once;
              ^~~~~~~~~~~~~~~

@bors
Copy link
Contributor

bors commented Dec 30, 2015

☔ The latest upstream changes (presumably #30542) made this pull request unmergeable. Please resolve the merge conflicts.

@mitaa mitaa force-pushed the multispan branch 2 times, most recently from 59ea72d to 83e50b5 Compare January 21, 2016 20:35
@mitaa
Copy link
Contributor Author

mitaa commented Jan 21, 2016

(rebased)

@mitaa
Copy link
Contributor Author

mitaa commented Jan 21, 2016

I've reverted the no-line-elision behaviour mentioned in my last comment because I've acted prematurely (sorry for all the noise) since the line numbers may stay after all, and I think that this nicely reduces clutter.

<anon>:1:17: 10:20 warning: unused import, #[warn(unused_imports)] on by default
<anon>:1  use std::cell::{Cell, RefCell, UnsafeCell};
                          ^~~~  ^~~~~~~  ^~~~~~~~~~
<anon>:2  use std::sync::{atomic, mpsc};
                          ^~~~~~  ^~~~
          ...
<anon>:5  use std::cmp;
              ^~~~~~~~
          ...
<anon>:10 use std::iter::once;
              ^~~~~~~~~~~~~~~

@mitaa
Copy link
Contributor Author

mitaa commented Jan 25, 2016

review ping @sfackler

@sfackler
Copy link
Member

r? @nrc I think you've been working with diagnostic output.

@rust-highfive rust-highfive assigned nrc and unassigned sfackler Jan 26, 2016
@bors
Copy link
Contributor

bors commented Jan 26, 2016

☔ The latest upstream changes (presumably #31214) made this pull request unmergeable. Please resolve the merge conflicts.

buf
}

pub fn custom_group_spans<F>(&self, mut spans: Vec<Span>, push: F) -> Vec<MultiSpan>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you add a comment please?

@nrc
Copy link
Member

nrc commented Jan 27, 2016

I think the overall approach here is good, but have a few questions about the details.

@mitaa mitaa force-pushed the multispan branch 6 times, most recently from 2e396a8 to 4a7f008 Compare January 27, 2016 20:15
@mitaa
Copy link
Contributor Author

mitaa commented Jan 27, 2016

(updated)

@nrc
Copy link
Member

nrc commented Jan 28, 2016

Regarding span splicing, is this (mitaa/rust@cd8d888) roughly what you had in mind?

Apologies, I may have spoken too soon. These (group_*) are purely functions for turning many spans into a single MulitSpan? In which case, I think keeping them with the other Span functions in codemap.rs is fine (we might want to break out all the spans stuff into its own module since that file is getting pretty big, but that can wait till later).

splice_lines I think is now in the right place.

@mitaa
Copy link
Contributor Author

mitaa commented Jan 28, 2016

If you're not using that facility, then I'd leave it as just one suggestion for now and change it later, if needed

Ok, I've limited it to a single span + suggestion, but left the backend support (-> splice_lines - or should that also be removed?)

@nrc
Copy link
Member

nrc commented Jan 28, 2016

@mitaa looks good, thanks for making the changes! Could you squash the commits please? Then r+

This allows to render multiple spans on one line,
or to splice multiple replacements into a code suggestion.
@mitaa
Copy link
Contributor Author

mitaa commented Jan 28, 2016

(squashed)

Thanks @nrc!

@nrc
Copy link
Member

nrc commented Jan 28, 2016

@bors: r+

@bors
Copy link
Contributor

bors commented Jan 28, 2016

📌 Commit 727f959 has been approved by nrc

bors added a commit that referenced this pull request Jan 28, 2016
This allows to render multiple spans on one line, or to splice multiple replacements into a code suggestion.

fixes #28124
@bors
Copy link
Contributor

bors commented Jan 28, 2016

⌛ Testing commit 727f959 with merge 142214d...

@alexcrichton
Copy link
Member

This passed all tests but buildbot lost a slave so homu didn't merge, gonna merge manually as I'm restarting buildbot anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Multi-span reporting feature
6 participants