www.digitalmars.com         C & C++   DMDScript  

D - standartize errors/warnings

reply "Pavel Minayev" <evilone omen.ru> writes:
I've just thought of it... would be good if error and warning
numbers were the same across all the compilers, and to have
some language feature to turn them off. Remember that case
when you write a program for, say, VC++, disable some senseless
warnings using #pragma, and then compile it with BCC and get
all those things back - simply because warning IDs don't match.
Also, not all compilers support #pragma in the same manner...
so some standard construct for this would be really great.
For example, nowarning and noerror attributes:

    nowarning(123, 321)    // disable warnings 123 and 321
    {
        ...
    }

    noerror(456, 654)    // disable errors 456 and 654
    {
        ...
    }
Feb 25 2002
next sibling parent Russell Borogove <kaleja estarcion.com> writes:
Pavel Minayev wrote:
 I've just thought of it... would be good if error and warning
 numbers were the same across all the compilers, and to have
 some language feature to turn them off.

I'm pretty sure the error and warning IDs are the same across all currently available D compilers. :) -R
Feb 25 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a5dtef$1o6m$1 digitaldaemon.com...
 I've just thought of it... would be good if error and warning
 numbers were the same across all the compilers, and to have
 some language feature to turn them off. Remember that case
 when you write a program for, say, VC++, disable some senseless
 warnings using #pragma, and then compile it with BCC and get
 all those things back - simply because warning IDs don't match.
 Also, not all compilers support #pragma in the same manner...
 so some standard construct for this would be really great.

Unfortunately, doing this will dictate the parsing strategy/tool used. Different parser implementations will realize at different points that there's a syntax error, and so will necessarilly produce different messages. What is actually wrong is open to debate: a = b + c d + q; Is the error a missing semicolon? Or is it a missing operator? The quality of error messages is a quality of implementation issue, and implementations should be free to try and produce the most accurate message possible. Certainly, in the C/C++ compiler business, there has been steady improvement in the quality of the error messages over the years. Also, D will not have warnings. The language should be defined so it compiles or does not. Having various warning levels, and whether those warnings are real errors or not, what to do when some package you download gets warnings when compiling it, etc., are all problems with the language definition.
Feb 25 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a5e4e0$1ren$1 digitaldaemon.com...

 Also, D will not have warnings. The language should be defined so it
 compiles or does not. Having various warning levels, and whether those
 warnings are real errors or not, what to do when some package you download
 gets warnings when compiling it, etc., are all problems with the language
 definition.

Look at it from another point: warning is when the compiler sees something that looks like an error, but cannot be sure it actually is - just like that "missing return" thing.
Feb 25 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a5ean2$1ufd$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:a5e4e0$1ren$1 digitaldaemon.com...

 Also, D will not have warnings. The language should be defined so it
 compiles or does not. Having various warning levels, and whether those
 warnings are real errors or not, what to do when some package you


 gets warnings when compiling it, etc., are all problems with the


 definition.

that looks like an error, but cannot be sure it actually is - just like that "missing return" thing.

What needs to be done for each warning is look at why it's a warning and not an error. Then, adjust the language specification, or add something like your suggestion to throw an exception for missing returns.
Feb 25 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a5egdb$21nn$1 digitaldaemon.com...

 What needs to be done for each warning is look at why it's a warning and

 an error. Then, adjust the language specification, or add something like
 your suggestion to throw an exception for missing returns.

Okay, so what about "parameter not used in function" argument that Borland C++ really likes? It seems pretty much logical to me since C/C++ has a neat feature of unnamed function parameters - those aren't reported as unused for obvious reasons. However, D does not allow unnamed parameters in function definition, but only in declaration... why? API & callback functions are where this feature is mostly used: int WinMain(HINSTANCE hInst, HINSTANCE, LPSTR, int nCmdShow) { ... } int EnumWindowsProc(HWND hWnd, LPARAM) { ... }
Feb 25 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a5f5kb$2anr$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:a5egdb$21nn$1 digitaldaemon.com...

 What needs to be done for each warning is look at why it's a warning and

 an error. Then, adjust the language specification, or add something like
 your suggestion to throw an exception for missing returns.

Okay, so what about "parameter not used in function" argument that Borland C++ really likes? It seems pretty much logical to me since C/C++ has a neat feature of unnamed function parameters - those aren't reported as unused for obvious reasons. However, D does not allow unnamed parameters in function definition, but only in declaration... why?

I suppose that naming them is a documentation thing, even though they are not used.
Feb 26 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a5ffqd$2fli$1 digitaldaemon.com...

 I suppose that naming them is a documentation thing, even though they are
 not used.

There ain't much reason in naming them in callback function or WinMain. After all, if the argument is not used, it has no meaning - so it doesn't need a name (which usually ends up being "reserved" or "dummy" or something like that). Any additional info (like "must be 0") can be mentioned in accompanying comment.
Feb 26 2002
prev sibling parent reply Juarez Rudsatz <juarez correio.com> writes:
"Walter" <walter digitalmars.com> wrote in
news:a5e4e0$1ren$1 digitaldaemon.com: 

 
 Unfortunately, doing this will dictate the parsing strategy/tool used.
 Different parser implementations will realize at different points that
 there's a syntax error, and so will necessarilly produce different
 messages. What is actually wrong is open to debate:
 
     a = b + c
     d + q;
 
 Is the error a missing semicolon? Or is it a missing operator? The
 quality of error messages is a quality of implementation issue, and
 implementations should be free to try and produce the most accurate
 message possible. Certainly, in the C/C++ compiler business, there has
 been steady improvement in the quality of the error messages over the
 years. 
 

Error detection is directly linked with the compiler implementation. But the programmers errors have nothing, in most cases, with the compiler. They are linked with syntax or semantic. In the same way, the message showed for the programmer could depend of compiler implementation. But the error is the same in all compilers. The error is in the same point and different compilers could detect or choose different errors. But there are advantages in standartizing error messages. All compilers will need treat the same errors. Supose the following: compiler A : source.d Error 123 Line 456 column 78 : Missing parameter to function. compiler A : source.d Error 123 Line 456 column 78 : Missing parameter "Param" to function. The error messages will be more accurated depending the compiler implementation. But the error is the same and the error code is the same. This will help writing documentation for errors, integrating texteditors with the compilers and so on. Of course cannot we standartizing all errors possible. But we can allow ranges of errors : 0-10000 : language errors 20000-30000: environment errors 10000-20000: specific compiler errors comments ?
Feb 28 2002
next sibling parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Juarez Rudsatz" <juarez correio.com> wrote in message
news:Xns91C390C7D5CBEjuarez 63.105.9.61...
<SNIP>
 The error messages will be more accurated depending the compiler
 implementation. But the error is the same and the error code is the
 same.

 This will help writing documentation for errors, integrating texteditors
 with the compilers and so on.

 Of course cannot we standartizing all errors possible. But we can allow
 ranges of errors :

 0-10000 : language errors
 20000-30000: environment errors
 10000-20000: specific compiler errors

 comments ?

Fairly good idea, although I hate ranges, because you always end up with one range nearly filled while another uses only a few numbers....It would be well suited for this though, but how far can you extend the idea, because this on it's own will not really help that much. -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Feb 28 2002
prev sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Juarez Rudsatz" <juarez correio.com> wrote in message
news:Xns91C390C7D5CBEjuarez 63.105.9.61...

 Of course cannot we standartizing all errors possible. But we can allow
 ranges of errors :

 0-10000 : language errors
 20000-30000: environment errors
 10000-20000: specific compiler errors

 comments ?

Yes, THIS is a good idea. There are tons of error messages common to all compilers, why not standartize them? It wouldn't do any harm, at least.
Feb 28 2002