www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Error message improvement ideas

reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Dec 18 2015
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Dec 19 2015
parent Adam D. Ruppe <destructionator gmail.com> writes:
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.
Dec 19 2015
prev sibling next sibling parent JohnCK <j j.com> writes:
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.
Dec 19 2015
prev sibling next sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
It seems like a small effort with a big return. I definitely 
support this. Nice idea.
Dec 20 2015
prev sibling parent reply NX <nightmarex1337 hotmail.com> writes:
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...
Dec 20 2015
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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?
Dec 20 2015
parent reply Jacob Carlborg <doob me.com> writes:
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
Dec 20 2015
parent Adam D. Ruppe <destructionator gmail.com> writes:
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)
Dec 20 2015