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