Re: Incomprehensible error message
On Tue, 2018-03-20 at 14:18 -0700, H. S. Teoh via Digitalmars-d-learn wrote: > […] > > Either way, it will require a lot of effort to pull off. > 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. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Incomprehensible error message
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 "" 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.
Re: Incomprehensible error message
On Tue, Mar 20, 2018 at 11:05:59PM +, 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.
Re: Incomprehensible error message
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).
Re: Incomprehensible error message
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.
Re: Incomprehensible error message
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
Re: Incomprehensible error message
On Mon, 2018-03-19 at 10:54 -0700, H. S. Teoh via Digitalmars-d-learn
wrote:
> […]
>
> One wild guess is if some of the symbols come from different modules,
> such that you might have modA.dvb_entry vs. modB.dvb_entry, for
> example,
> which would be a type mismatch. Or if one symbol was declared in D
> linkage but the other in C linkage, which is perhaps a more likely
> cause. But since the compiler doesn't tell us the FQN of the
> identifiers, it's anybody's guess whether this is actually the
> problem,
> or which are the offending identifiers.
>
Prompted by this and Adam's emails, which gave me the moral support to
getting stuck in to doing something rather than just moaning :-)
I think the problem is with the instance of dvb_entry *.
The call is actually in a loop:
for (auto entry = ptr.c_ptr().first_entry; entry != null; entry = entry.next) {
if (entry.channel is null) { continue; } // TODO Shouldn't need this,
but it seems needed, why?
frontendParameters.logfunc(LOG_INFO, "\nChannel: %s", entry.channel);
try {
auto scanHandler = ScanHandler_Ptr(frontendParameters.c_ptr(),
entry, dmx_fd.value(), , other_nit, timeout_multiplier);
I tried replacing the auto with dvb_entry* and we have the answer:
../../Repositories/Git/Masters/DVBTune/source/channels.d(157): Error: cannot
implicitly convert expression `(*this.ptr.c_ptr()).first_entry` of type
`libdvbv5_d.dvb_file.dvb_entry*` to `libdvbv5_d.dvb_scan.dvb_entry*`
This is most likely an unintended consequence of using DStep: the
dvb_entry type is being defined in two distinct modules. Now everything
is clear and I just need to find a solution to why two definitions.
The error message is still incomprehensible as is though.
--
Russel.
===
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
signature.asc
Description: This is a digitally signed message part
Re: Incomprehensible error message
On Mon, Mar 19, 2018 at 05:01:32PM +, 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!
Re: Incomprehensible error message
On Mon, Mar 19, 2018 at 04:33:28PM +, Russel Winder via Digitalmars-d-learn wrote: [...] > 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: [...] Here's my reformatting of the error, that hopefully might be of assistance: > source/channels.d(161): Error: constructor > libdvbv5.ScanHandler_Ptr.this ( > dvb_v5_fe_parms* frontendParameters, > dvb_entry* entry, > const(int) dmx_fd, > extern (C) int function(void* args, dvb_v5_fe_parms* parms) > check_frontend, > const(uint) other_nit, > const(uint) timeout_multiplier) > is not callable using argument types ( > dvb_v5_fe_parms*, > dvb_entry*, > const(int), > extern (C) int function(void* _arguments, dvb_v5_fe_parms* > frontendParameters), > const(uint), > const(uint)) [...] Or, boiled down to the bare basics with extraneous identifiers removed: > source/channels.d(161): Error: constructor > libdvbv5.ScanHandler_Ptr.this ( > dvb_v5_fe_parms*, > dvb_entry*, > const(int), > extern (C) int function(void*, dvb_v5_fe_parms*), > const(uint), > const(uint)) > is not callable using argument types ( > dvb_v5_fe_parms*, > dvb_entry*, > const(int), > extern (C) int function(void*, dvb_v5_fe_parms*), > const(uint), > const(uint)) [...] Which is rather odd, since the parameter types correspond to each other exactly. So why the compiler would reject the code, I honestly have no idea. One wild guess is if some of the symbols come from different modules, such that you might have modA.dvb_entry vs. modB.dvb_entry, for example, which would be a type mismatch. Or if one symbol was declared in D linkage but the other in C linkage, which is perhaps a more likely cause. But since the compiler doesn't tell us the FQN of the identifiers, it's anybody's guess whether this is actually the problem, or which are the offending identifiers. T -- Prosperity breeds contempt, and poverty breeds consent. -- Suck.com
Re: Incomprehensible error message
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.
Incomprehensible error message
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=. -g -gc -d-debug -I/home/users/russel/Built/include/d -of=Build/Release/dvb-tune source/main.d source/libdvbv5.d source/channels.d -L-ldvbv5 source/channels.d(161): Error: constructor libdvbv5.ScanHandler_Ptr.this (dvb_v5_fe_parms* frontendParameters, dvb_entry* entry, const(int) dmx_fd, extern (C) int function(void* args, dvb_v5_fe_parms* parms) check_frontend, const(uint) other_nit, const(uint) timeout_multiplier) is not callable using argument types (dvb_v5_fe_parms*, dvb_entry*, const(int), extern (C) int function(void* _arguments, dvb_v5_fe_parms* frontendParameters), const(uint), const(uint)) -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
