This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/16070] Bad error message


------- Additional Comments From igodard at pacbell dot net  2004-06-19 23:31 -------
A user's two bits: by definition (it's an error-reporting issue) the user has written something wrong. Out of the many available overloads (templates and regular), none matched. As the compiler cannot know what the user's inten was, nor hich of the oberloads was *supposed* tohave matched, it is unwise for the compiler to assume that come of the overloads cannot be the source of the problem. So, despite the fact that the compiler knows that the template *as written* didn't match, the compiler can't know that the template *as it should have been written* would not match. 

Consequently, it is the compiler's job to give the user as much information as it has available, to allow the user to select which overload he has to fix. The best message would be to list all candidate overloads and all candidate values, and for each overload to indicate why match failed. That directly clues the user as to what to do for a fix: locate the intended overload in the message list; read why no match was valid; make it valid.

Hence what the compiler should produce is something like:

Error: file crud line 234
Cannot identify unique overload in call. Arguments are:
    Foo(void (*)(int))
    Foo(void (*)(char))
note: some arguments are overloaded functions; at least one of the overloads must match in its argument position

overloads considered were:  
   file foo line 17: ..............; does not match because no possible argument satisfied the template at argument position 1
   file bar line 23: ..............; does not match because no possible argument satisfied the template at argument position 1
   file baz line 5: ..............; does not match because no argument 1 can be coerced to type int


(modify message to simplify for the common case where there are no overloads in the actuals so the actuals don't have to be unified).

*That* would be useful to the merely human programmer.

Ivan

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16070


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]