Highlight and simplify mismatched types #41205

estebank · 2017-04-10T21:51:38Z

Shorten mismatched types errors by replacing subtypes that are not
different with _, and highlighting only the subtypes that are
different.

Given a file

struct X<T1, T2> {
    x: T1,
    y: T2,
}

fn foo() -> X<X<String, String>, String> {
    X { x: X {x: "".to_string(), y: 2}, y: "".to_string()}
}

fn bar() -> Option<String> {
    "".to_string()
}

provide the following output

error[E0308]: mismatched types
  --> file.rs:6:5
   |
 6 |     X { x: X {x: "".to_string(), y: 2}, y: "".to_string()}
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `std::string::String`, found {integer}
   |
   = note: expected type `X<X<_, std::string::String>, _>`
                                 ^^^^^^^^^^^^^^^^^^^   // < highlighted
              found type `X<X<_, {integer}>, _>`
                                 ^^^^^^^^^             // < highlighted

error[E0308]: mismatched types
  --> file.rs:6:5
   |
10 |     "".to_string()
   |     ^^^^^^^^^^^^^^ expected struct `std::option::Option`, found `std::string::String`
   |
   = note: expected type `Option<std::string::String>`
                          ^^^^^^^                   ^  // < highlighted
              found type `std::string::String`

Fix #21025. Re: #40186. Follow up to #39906.

I'm looking to change how this output is accomplished so that it doesn't create list of strings to pass around, but rather add an elided Ty placeholder, and use the same string formatting for normal types. I'll be doing that soonish.

r? @nikomatsakis

estebank · 2017-04-10T22:07:37Z

Visual output:

arielb1 · 2017-04-11T11:02:51Z

@estebank
Shouldn't the "found type std::string::String" be highlighted as well?

estebank · 2017-04-11T11:39:15Z

It only highlights differing parts, while dimming the parts that are the same. In that case, only the std::option::Option<...> part is relevant to the error. May be we can incorporate the elision logic without any highlighting change for the "composition" case?

arielb1 · 2017-04-11T12:42:41Z

@estebank

I mean, I expected:


note: expected type `std::option::Option<std::string::String>`
                     ^^^^^^^^^^^^^^^^^^^^                   ^
      found type    `std::string::String`
                     ^^^^^^^^^^^^^^^^^^^

arielb1 · 2017-04-11T15:13:51Z

src/librustc/infer/error_reporting/mod.rs

+    /// The type error output will behave in the following way:
+    ///
+    /// ```text
+    /// Foo<Bar<Qux>


syntax error: mismatched parentheses

arielb1 · 2017-04-11T15:13:57Z

src/librustc/infer/error_reporting/mod.rs

+    /// populate `other_value` with `other_ty`.
+    ///
+    /// ```text
+    /// Foo<Bar<Qux>


syntax error: mismatched parentheses

arielb1 · 2017-04-11T15:15:54Z

src/librustc_errors/diagnostic.rs

@@ -35,6 +35,46 @@ pub struct SubDiagnostic {
    pub render_span: Option<RenderSpan>,
 }

+#[derive(PartialEq, Eq)]


Call this StyledString or something? There's already snippet::StyledString, so maybe have a Vec of that?

nikomatsakis

r=me modulo test failures; @arielb1's thoughts on underlining seem potentially fine, but I could go either way (and even if we did want to do it, I'd be fine w/ leaving it for a later PR).

nikomatsakis · 2017-04-11T15:19:12Z

src/librustc/infer/error_reporting/mod.rs

+                        let l2 = lifetime_display(lifetimes.1);
+                        if l1 == l2 {
+                            values.0.push_normal("'_");
+                            values.1.push_normal("'_");


Unlike _, this is not legal syntax for a user to type, but I guess that's ok. Not sure what else to use, in any case.

I agree with your reasoning. I followed this path given that the compiler already has diagnostics that show '_ in some cases.

nikomatsakis · 2017-04-11T15:20:07Z

src/test/ui/mismatched_types/abridged.stderr

+30 |     Foo { bar: 1 }
+   |     ^^^^^^^^^^^^^^ expected enum `std::option::Option`, found struct `Foo`
+   |
+   = note: expected type `std::option::Option<Foo>`


too bad we lose the highlighting here, but I don't really know how to fix that

Yeah... I've been thinking that we could expand ui errors to have a mode where ANSI escape codes are kept (.stderr_full? A comment flag in the .rs test file?).

nikomatsakis · 2017-04-11T15:22:56Z

I see @arielb1 also posted some other suggestions that seem potentially good; e.g. using StyledString or what have you. I don't have a strong opinion. This didn't seem like a lot of code and it read fairly easily (thanks @estebank for the comments, the code seemed pretty easy to understand this time) but DRYer is always better.

src/librustc/infer/error_reporting/mod.rs

Shorten mismatched types errors by replacing subtypes that are not different with `_`, and highlighting only the subtypes that are different. Given a file ```rust struct X<T1, T2> { x: T1, y: T2, } fn foo() -> X<X<String, String>, String> { X { x: X {x: "".to_string(), y: 2}, y: "".to_string()} } fn bar() -> Option<String> { "".to_string() } ``` provide the following output ```rust error[E0308]: mismatched types --> file.rs:6:5 | 6 | X { x: X {x: "".to_string(), y: 2}, y: "".to_string()} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `std::string::String`, found {integer} | = note: expected type `X<X<_, std::string::String>, _>` ^^^^^^^^^^^^^^^^^^^ // < highlighted found type `X<X<_, {integer}>, _>` ^^^^^^^^^ // < highlighted error[E0308]: mismatched types --> file.rs:6:5 | 10 | "".to_string() | ^^^^^^^^^^^^^^ expected struct `std::option::Option`, found `std::string::String` | = note: expected type `Option<std::string::String>` ^^^^^^^ ^ // < highlighted found type `std::string::String` ```

estebank · 2017-04-11T22:55:36Z

@nikomatsakis I believe I addressed all the points (except the highlighting case brought up by @arielb1), as well as fixed a small presentational bug that was left from when I was first preparing this code.

estebank · 2017-04-12T08:11:53Z

@bors r=nikomatsakis

bors · 2017-04-12T08:11:54Z

📌 Commit 2389830 has been approved by nikomatsakis

@nikomatsakis

…, r=nikomatsakis Highlight and simplify mismatched types Shorten mismatched types errors by replacing subtypes that are not different with `_`, and highlighting only the subtypes that are different. Given a file ```rust struct X<T1, T2> { x: T1, y: T2, } fn foo() -> X<X<String, String>, String> { X { x: X {x: "".to_string(), y: 2}, y: "".to_string()} } fn bar() -> Option<String> { "".to_string() } ``` provide the following output ```rust error[E0308]: mismatched types --> file.rs:6:5 | 6 | X { x: X {x: "".to_string(), y: 2}, y: "".to_string()} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `std::string::String`, found {integer} | = note: expected type `X<X<_, std::string::String>, _>` ^^^^^^^^^^^^^^^^^^^ // < highlighted found type `X<X<_, {integer}>, _>` ^^^^^^^^^ // < highlighted error[E0308]: mismatched types --> file.rs:6:5 | 10 | "".to_string() | ^^^^^^^^^^^^^^ expected struct `std::option::Option`, found `std::string::String` | = note: expected type `Option<std::string::String>` ^^^^^^^ ^ // < highlighted found type `std::string::String` ``` Fix rust-lang#21025. Re: rust-lang#40186. Follow up to rust-lang#39906. I'm looking to change how this output is accomplished so that it doesn't create list of strings to pass around, but rather add an elided `Ty` placeholder, and use the same string formatting for normal types. I'll be doing that soonish. r? @nikomatsakis

Rollup of 9 pull requests - Successful merges: #41063, #41087, #41141, #41166, #41183, #41205, #41206, #41232, #41243 - Failed merges:

rust-highfive assigned nikomatsakis Apr 10, 2017

estebank force-pushed the shorter-mismatched-types-2 branch from 8396d0c to a39b3ce Compare April 11, 2017 10:09

arielb1 reviewed Apr 11, 2017

View reviewed changes

nikomatsakis approved these changes Apr 11, 2017

View reviewed changes

arielb1 reviewed Apr 11, 2017

View reviewed changes

src/librustc/infer/error_reporting/mod.rs Outdated Show resolved Hide resolved

estebank force-pushed the shorter-mismatched-types-2 branch 3 times, most recently from a1a2ff5 to f875e08 Compare April 11, 2017 22:44

estebank force-pushed the shorter-mismatched-types-2 branch from f875e08 to 2389830 Compare April 11, 2017 22:45

TimNN mentioned this pull request Apr 12, 2017

Rollup of 9 pull requests #41246

Merged

bors added a commit that referenced this pull request Apr 12, 2017

Auto merge of #41246 - TimNN:rollup, r=TimNN

910c481

Rollup of 9 pull requests - Successful merges: #41063, #41087, #41141, #41166, #41183, #41205, #41206, #41232, #41243 - Failed merges:

bors merged commit 2389830 into rust-lang:master Apr 12, 2017

estebank mentioned this pull request Jun 2, 2017

Color differences between found and expected in errors #21334

Closed

estebank mentioned this pull request Jul 22, 2017

Could we smartly elide some info from types in error messages? #43354

Closed

estebank deleted the shorter-mismatched-types-2 branch November 9, 2023 05:26

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Highlight and simplify mismatched types #41205

Highlight and simplify mismatched types #41205

estebank commented Apr 10, 2017 •

edited

Loading

estebank commented Apr 10, 2017

arielb1 commented Apr 11, 2017

estebank commented Apr 11, 2017

arielb1 commented Apr 11, 2017

arielb1 Apr 11, 2017

estebank Apr 11, 2017

arielb1 Apr 11, 2017

estebank Apr 11, 2017

arielb1 Apr 11, 2017 •

edited

Loading

estebank Apr 11, 2017

nikomatsakis left a comment

nikomatsakis Apr 11, 2017

estebank Apr 11, 2017

nikomatsakis Apr 11, 2017

estebank Apr 11, 2017

nikomatsakis commented Apr 11, 2017

estebank commented Apr 11, 2017

estebank commented Apr 12, 2017

bors commented Apr 12, 2017

Highlight and simplify mismatched types #41205

Highlight and simplify mismatched types #41205

Conversation

estebank commented Apr 10, 2017 • edited Loading

estebank commented Apr 10, 2017

arielb1 commented Apr 11, 2017

estebank commented Apr 11, 2017

arielb1 commented Apr 11, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arielb1 Apr 11, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis commented Apr 11, 2017

estebank commented Apr 11, 2017

estebank commented Apr 12, 2017

bors commented Apr 12, 2017

estebank commented Apr 10, 2017 •

edited

Loading

arielb1 Apr 11, 2017 •

edited

Loading