Thread overview
Error message improvement ideas
Dec 18, 2015
Adam D. Ruppe
Dec 19, 2015
Jacob Carlborg
Dec 20, 2015
Adam D. Ruppe
Dec 20, 2015
JohnCK
Dec 20, 2015
Sebastiaan Koppe
Dec 20, 2015
NX
Dec 20, 2015
Adam D. Ruppe
Dec 20, 2015
Jacob Carlborg
Dec 20, 2015
Adam D. Ruppe
December 18, 2015
I really want the compiler to be more specific about what worked and what didn't in error messages. Check this out.

---
void foo(int a, string b) {}
void foo(string b) {}

void main() {
	foo(10.2, "foo");
}
---

k.d(5): Error: None of the overloads of 'foo' are callable using argument types (double, string), candidates are:
k.d(1):        k.foo(int a, string b)
k.d(2):        k.foo(string b)


A relevant piece is (double, string), what I passed to it, but it is kinda mixed into the rest of the line. Moreover, what one didn't match?

We already highlight the word "Error:". I propose we also highlight stuff in the details lines, like this (pretending the color tags actually came through)

k.d(1):        k.foo(<red>int</red> a, <green>string</green> b)
k.d(2):        k.foo(<red>string</red> b)


The first arg I passed never fit the first arg of the options, they get red color. My string did pass one though, so it gets green to highlight a partial match.



Doing this on template constraints too (along with formatting them with some whitespace) would be huge toward making those std.algorithm errors be readable as well.



Moreover, I wouldn't mind if the compiler had an error output format that could spit out xml or something for computer consumption, with the same level of detail (if not more). If I were overhauling it all, I'd make all error messages inside the compiler be marked up to the max, then the top layer prints them appropriately for the device it is talking to (so disabling color on pipes, pretty printing for users, etc)


But the specifics aren't as important as having the compiler just somehow make it obvious at a glance what worked and what didn't. It could also do:

k.d(1):        k.foo(int a, string b)
                     ^^^    ++++++
k.d(2):        k.foo(string b)
                     ^^^^^^

or whatever instead of (or addition to, let's not forget a lot of people can't see color and the contrast on terminals may be quite poor) color.
December 19, 2015
On 2015-12-18 19:55, Adam D. Ruppe wrote:

> Moreover, I wouldn't mind if the compiler had an error output format
> that could spit out xml or something for computer consumption, with the
> same level of detail (if not more). If I were overhauling it all, I'd
> make all error messages inside the compiler be marked up to the max,
> then the top layer prints them appropriately for the device it is
> talking to (so disabling color on pipes, pretty printing for users, etc)

Seems like a really nice idea. Although, the (XML) output should contain the semantic meaning not how it should be displayed. That is, it should contain something like <no-match>int</no-match> rather than <red>int</red>.

-- 
/Jacob Carlborg
December 20, 2015
On Saturday, 19 December 2015 at 10:34:40 UTC, Jacob Carlborg wrote:
> Although, the (XML) output should contain the semantic meaning not how it should be displayed. That is, it should contain something like <no-match>int</no-match> rather than <red>int</red>.

Right.


So I took a stab at playing with this in dmd... and it actually isn't too hard, but it does need some refactoring of string code. I really do think it would be a big improvement.
December 20, 2015
On Friday, 18 December 2015 at 18:55:29 UTC, Adam D. Ruppe wrote:
> ...It could also do:
>
> k.d(1):        k.foo(int a, string b)
>                      ^^^    ++++++
> k.d(2):        k.foo(string b)
>                      ^^^^^^

I prefer this way than using colors.

And by the way, this thread should have more attention.

JohnCK.
December 20, 2015
It seems like a small effort with a big return. I definitely support this. Nice idea.
December 20, 2015
On Friday, 18 December 2015 at 18:55:29 UTC, Adam D. Ruppe wrote:
> [...]
The biggest problem is overly templated functions. We should seriously find a way to make them error friendly. Maybe:
auto find(Range : [InputRange], V)(Range haystack, V needle)
Rather than:
auto find(Range, V)(Range haystack, V needle) if(isInputRange!Range)
But I'm sure core d devs will strike with a "we can't change semantics, it would break existing code" argument...
December 20, 2015
On Sunday, 20 December 2015 at 11:59:05 UTC, NX wrote:
> We should seriously find a way to make them error friendly.

I think this change I'm looking at here would make a huge difference because then you'd be able to see how close you got to matching the various overloads. (in my other post, I showed traditional overloading but I can apply the same technique to failing/passing expressions in template constraints too).

I also want to add some whitespace to the no template matches error, as well as the ddoc generator.

> But I'm sure core d devs will strike with a "we can't change semantics, it would break existing code" argument...

The beauty of error message improvement is it doesn't break any code... and since it isn't on the main compilation path, the error generation code can afford to be less than perfectly efficient. Who cares if the error took an extra half second to generate when it cuts off five minutes of dev time and doesn't affect the build time when it isn't triggered?
December 20, 2015
On 2015-12-20 14:34, Adam D. Ruppe wrote:

> The beauty of error message improvement is it doesn't break any code...

Well..., TextMate parses the error messages, extracts the file and line info and turns them to links back to the editor. I'm pretty sure of editors do the same. Of course, it would be better if the output was in a machine readable format. But all editors would need to be updated. The terminal I use does the same as well, not sure if that would break if colors were added.

-- 
/Jacob Carlborg
December 20, 2015
On Sunday, 20 December 2015 at 13:55:53 UTC, Jacob Carlborg wrote:
> Well..., TextMate parses the error messages, extracts the file and line info and turns them to links back to the editor.

Yeah, but that's just looking at the first part of the error which is basically standard. The parts after the line number aren't automatically parsed by any editor I know of.

(the xml idea would be opt in btw, of course, but would be easier for IDEs to read)