www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Incomprehensible error message

reply Russel Winder <russel winder.org.uk> writes:
Hi,

I have been staring at this message so long, I have clearly stopped
actually reading it, hence outside assistance needed.

Can someone please explain to me (probably in words of one syllable
since I am clearly being very unintelligent) how any code can deliver
an error message such as:


ldc2 -I=3D. -g -gc -d-debug -I/home/users/russel/Built/include/d -of=3DBuil=
d/Release/dvb-tune source/main.d source/libdvbv5.d source/channels.d -L-ldv=
bv5
source/channels.d(161): Error: constructor libdvbv5.ScanHandler_Ptr.this (d=
vb_v5_fe_parms* frontendParameters, dvb_entry* entry, const(int) dmx_fd, ex=
tern (C) int function(void* args, dvb_v5_fe_parms* parms) check_frontend, c=
onst(uint) other_nit, const(uint) timeout_multiplier) is not callable using=
 argument types (dvb_v5_fe_parms*, dvb_entry*, const(int), extern (C) int f=
unction(void* _arguments, dvb_v5_fe_parms* frontendParameters), const(uint)=
, const(uint))

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Mar 19 2018
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 19 March 2018 at 16:33:28 UTC, Russel Winder wrote:

 I have been staring at this message so long, I have clearly 
 stopped actually reading it, hence outside assistance needed.


So I would guess either there's two definitions of one of the 
types like maybe `dvb_v5_fe_parms` and the constructor uses one 
and your code uses another (may be the same struct defined in two 
different modules, where the definition imported one and you 
imported another - stupid compiler was (is?) liable to say "type 
A is not type A" when it should say "type foo.A is not bar.A"), 
or something like a stray const on the `this` pointer.


I almost remember that A != A bug was fixed but maybe not in 
function call things, or maybe not pushed to your ldc version yet.
Mar 19 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Mar 19, 2018 at 05:01:32PM +0000, Adam D. Ruppe via Digitalmars-d-learn
wrote:

 On Monday, 19 March 2018 at 16:33:28 UTC, Russel Winder wrote:

 I have been staring at this message so long, I have clearly stopped
 actually reading it, hence outside assistance needed.


 
 So I would guess either there's two definitions of one of the types
 like maybe `dvb_v5_fe_parms` and the constructor uses one and your
 code uses another (may be the same struct defined in two different
 modules, where the definition imported one and you imported another -
 stupid compiler was (is?) liable to say "type A is not type A" when it
 should say "type foo.A is not bar.A"), or something like a stray const
 on the `this` pointer.
 
 
 I almost remember that A != A bug was fixed but maybe not in function
 call things, or maybe not pushed to your ldc version yet.


Yeah, the compiler really ought to be outputting FQNs in error messages,
since otherwise you get baffling A != A messages.  Though outputting
FQNs everywhere has the tendency of bloating error messages to
unreadable lengths, esp. when templates are involved. :-(  (Though
fortunately, no templates are involved in this case.)

On a higher level, though, these type mismatch errors really ought to be
refactored to pinpoint the cause of the compiler's unhappiness more
narrowly, i.e., instead of saying:

	function F(a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v) is not
	callable with parameter types
	(a,b,c,d,e,f,g,h,j,i,k,l,m,n,o,p,q,r,s,t,u,v)

which requires the poor user to parse *two* entire incomprehensibly long
parameter/argument lists and diff them in his head, the compiler really
should say something more along the lines of:

	cannot pass argument j of type J to parameter 9 of type I and
	argument i of type I to parameter 10 of type J in function call
	to F(a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v)

The incomprehensibly long parameter list is unfortunately probably still
necessary to identify any overloads of F, but at least point out to the
user *which* parameters aren't matching instead of leaving him to figure
it out!


T

-- 
IBM = I'll Buy Microsoft!
Mar 19 2018
parent reply Jacob Carlborg <doob me.com> writes:
On 2018-03-19 19:03, H. S. Teoh wrote:


 Yeah, the compiler really ought to be outputting FQNs in error messages,
 since otherwise you get baffling A != A messages.  Though outputting
 FQNs everywhere has the tendency of bloating error messages to
 unreadable lengths, esp. when templates are involved. :-(  (Though
 fortunately, no templates are involved in this case.)


The compiler could output the FQN names only when the non qualified 
names are the same. Should hopefully reduce the bloated error messages.

-- 
/Jacob Carlborg
Mar 20 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 20, 2018 at 10:04:30PM +0100, Jacob Carlborg via
Digitalmars-d-learn wrote:

 On 2018-03-19 19:03, H. S. Teoh wrote:
 

 Yeah, the compiler really ought to be outputting FQNs in error
 messages, since otherwise you get baffling A != A messages.  Though
 outputting FQNs everywhere has the tendency of bloating error
 messages to unreadable lengths, esp. when templates are involved.
 :-(  (Though fortunately, no templates are involved in this case.)


 
 The compiler could output the FQN names only when the non qualified
 names are the same. Should hopefully reduce the bloated error
 messages.


[...]

Yeah, I thought about that too, but then it wouldn't be easy to
implement, since you wouldn't be able to easily predict whether or not
to use an FQN name when you've detected an error and just need to print
an error and bailout.  It needs to be automated in order to be
maintainable (nobody wants to go through thousands of compiler errors
and insert complex logic to decide which symbol(s) should be FQN).
Which means error messages would need to be constructed as an abstract
object that the error message printer can then inspect to determine
which symbol(s) should be FQNs.

Either way, it will require a lot of effort to pull off.


T

-- 
For every argument for something, there is always an equal and opposite
argument against it. Debates don't give answers, only wounded or inflated egos.
Mar 20 2018
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 20 March 2018 at 21:18:01 UTC, H. S. Teoh wrote:

  Which means error messages would need to be constructed as an 
 abstract object that the error message printer can then inspect 
 to determine which symbol(s) should be FQNs.


I've talked before about XML error messages. I'd actually like 
them to literally be xml, but even if they aren't the same 
principle works - pack the error messages with a lot of metadata 
when they are generated, then trim that at a higher level to make 
it more presentable (ideally, that higher level may be the ide, 
but for a console run the compiler might have to do it).
Mar 20 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 20, 2018 at 11:05:59PM +0000, Adam D. Ruppe via Digitalmars-d-learn
wrote:

 On Tuesday, 20 March 2018 at 21:18:01 UTC, H. S. Teoh wrote:

 Which means error messages would need to be constructed as an
 abstract object that the error message printer can then inspect to
 determine which symbol(s) should be FQNs.


 
 I've talked before about XML error messages. I'd actually like them to
 literally be xml, but even if they aren't the same principle works -
 pack the error messages with a lot of metadata when they are
 generated, then trim that at a higher level to make it more
 presentable (ideally, that higher level may be the ide, but for a
 console run the compiler might have to do it).


That's not a bad idea, and pretty close to what I have in mind.  The
tricky part is, who's going to do the work of going through *all* of
dmd's error messages and rewriting them with said metadata.  It would
seem to me that a solution that can be implemented gradually is more
likely to be adopted.  E.g. if we can somehow work with the existing
format of error messages and extract some useful info from them, perhaps
reformat substrings that match certain known patterns, then we can
gradually migrate all error messages to a particular format that will
eventually serve as the intermediate metadata encoding.

Any proposed solution that requires a one-off rewriting of every single
error message in dmd is unlikely to fly, IMO.


T

-- 
There are 10 kinds of people in the world: those who can count in binary, and
those who can't.
Mar 20 2018
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 20 March 2018 at 23:45:20 UTC, H. S. Teoh wrote:

  The tricky part is, who's going to do the work of going 
 through *all* of dmd's error messages and rewriting them with 
 said metadata.


We did it for the stupid syntax highlighting thing... and this 
has bigger win, though it is also more work than just adding `` 
around it.


  It would seem to me that a solution that can be implemented 
 gradually is more likely to be adopted.


The beauty of XML is that it is reasonably easy to do gradually 
since it is a marked up string rather than a whole new format. On 
the display side, it can even detect if(str[0] == '<') assume it 
is xml, otherwise assume it is plain text. User-side ides can do 
it as well as the compiler's top-level presentation layer. Or the 
existing error() function can add "<error>" and encode the stuff, 
and a new detailedError function does more detail.

xml is also extensible to add more info later when we decide. It 
really is quite elegant for marking up a text base with more 
metadata...


  E.g. if we can somehow work with the existing format of error 
 messages and extract some useful info from them, perhaps 
 reformat substrings that match certain known patterns, then we 
 can gradually migrate all error messages to a particular format 
 that will eventually serve as the intermediate metadata 
 encoding.


Well, a lot of info is lost by the toChars not putting out as 
much info as it could. So working with existing messages still 
needs changes on the generation side to improve it. But we can 
add info as we go.
Mar 20 2018
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2018-03-20 at 14:18 -0700, H. S. Teoh via Digitalmars-d-learn
wrote:

 [=E2=80=A6]
=20
 Either way, it will require a lot of effort to pull off.
=20


As Rust has shown appreciating that the quality of the error messages
define the quality of the compiler, the quality of the error message
from rustc are now very good indeed.

On the other hand Rust has a lot of paid staff.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Mar 21 2018