Skip to content

Handle fully enclosed multiline spans gracefully in emitter #61017

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

Open
estebank opened this issue May 21, 2019 · 1 comment
Open

Handle fully enclosed multiline spans gracefully in emitter #61017

estebank opened this issue May 21, 2019 · 1 comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@estebank
Copy link
Contributor

estebank commented May 21, 2019

Currently the solution to overlapping multiline spans is correct, but doesn't handle spans that are completely enclosed by others in any way, simply using span ordering and growing towards the left as needed. The following is a representative example of the problem:

error[E0308]: if and else have incompatible types
    --> src/libsyntax/parse/parser.rs:2640:33
     |
2636 |                                 let (span, msg) = if self.token == token::Token::Eof && self.is_subparser {
     |    _______________________________________________-
2637 |   |                                 (self.sess.source_map().next_point(self.span),
     |  _|_________________________________-
2638 | | |                                  "expected expression, found end of macro arguments")
     | |_|_____________________________________________________________________________________- expected because of this
2639 |   |                             } else {
2640 | / |                                 (self.span, format!(
2641 | | |                                     "expected expression, found {}",
2642 | | |                                     self.this_token_descr(),
2643 | | |                                 ))
     | |_|__________________________________^ expected &str, found struct `std::string::String`
2644 |   |                             };
     |   |_____________________________- if and else have incompatible types
     |
     = note: expected type `(syntax_pos::span_encoding::Span, &str)`
                found type `(syntax_pos::span_encoding::Span, std::string::String)`

Ideally, the emitter should handle this case by identifying that there are overlapping spans that are fully enclosed and special case the output to make it easier to read:

error[E0308]: if and else have incompatible types
    --> src/libsyntax/parse/parser.rs:2640:33
     |
2636 |                                let (span, msg) = if self.token == token::Token::Eof && self.is_subparser {
     |  ________________________________________________-
2637 | | /                                (self.sess.source_map().next_point(self.span),
2638 | | |                                 "expected expression, found end of macro arguments")
     | | |____________________________________________________________________________________- expected because of this
2639 | |                              } else {
2640 | | /                                (self.span, format!(
2641 | | |                                    "expected expression, found {}",
2642 | | |                                    self.this_token_descr(),
2643 | | |                                ))
     | | |_________________________________^ expected &str, found struct `std::string::String`
2644 | |                              };
     | |______________________________- if and else have incompatible types
     |
     = note: expected type `(syntax_pos::span_encoding::Span, &str)`
                found type `(syntax_pos::span_encoding::Span, std::string::String)`
@estebank estebank added C-enhancement Category: An issue proposing an enhancement or a PR with one. A-diagnostics Area: Messages for errors, warnings, and lints labels May 21, 2019
@Centril Centril added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label May 21, 2019
@estebank estebank changed the title Handle fully enclosed multiline spans in emitter Handle fully enclosed multiline spans gracefully in emitter May 21, 2019
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Nov 27, 2022
Change multiline span ASCII art visual order

Tweak the ASCII art for nested multiline spans so that we minimize line overlaps.

Partially addresses rust-lang#61017.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Nov 27, 2022
Change multiline span ASCII art visual order

Tweak the ASCII art for nested multiline spans so that we minimize line overlaps.

Partially addresses rust-lang#61017.
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Nov 28, 2022
Change multiline span ASCII art visual order

Tweak the ASCII art for nested multiline spans so that we minimize line overlaps.

Partially addresses rust-lang#61017.
@estebank
Copy link
Contributor Author

The current output is now

  |
2 |         let _ = if true {
  |  _______________-
3 | |           (1,
  | |  _________-
4 | | |         2)
  | | |__________- expected because of this
5 | |       } else {
6 | | /         ("",
7 | | |         2)
  | | |__________^ expected integer, found `&str`
8 | |       };
  | |_______- `if` and `else` have incompatible types
  |
  = note: expected tuple `({integer}, {integer})`
             found tuple `(&str, {integer})`

The only thing left to do is make the first case properly do the / start span special case handling.

@estebank estebank added the P-low Low priority label Dec 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants