Highlight and simplify mismatched types by estebank · Pull Request #41205 · rust-lang/rust

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

structX<T1,T2>{x:T1,y:T2,}fnfoo() -> X<X<String,String>,String>{X{x:X{x:"".to_string(),y:2},y:"".to_string()}}fnbar() -> 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

syntax error: mismatched parentheses

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

syntax error: mismatched parentheses

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

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

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

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.

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` ``` Fixrust-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 a39b3ceCompare 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

Comment threadsrc/librustc/infer/error_reporting/mod.rs Outdated

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

estebank force-pushed the shorter-mismatched-types-2 branch from f875e08 to 2389830Compare 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:masterApr 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

Uh oh!

Uh oh!

Conversation

estebank commented Apr 10, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

estebank commented Apr 10, 2017

Uh oh!

arielb1 commented Apr 11, 2017

Uh oh!

estebank commented Apr 11, 2017

Uh oh!

arielb1 commented Apr 11, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arielb1Apr 11, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nikomatsakis left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nikomatsakis commented Apr 11, 2017

Uh oh!

Uh oh!

estebank commented Apr 11, 2017

Uh oh!

estebank commented Apr 12, 2017

Uh oh!

bors commented Apr 12, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

estebank commented Apr 10, 2017•
edited
Loading

arielb1Apr 11, 2017•
edited
Loading