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




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.


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


not

 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


 not

 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