Walter, could you change DMD so that error output goes to stderr?



Ben Hinkle wrote:
>>>one question, though. why doesn't the compiler stop compiling when it
>>>gives me warnings? shouldn't warnings just warn and still compile?
>>
>>The warnings cause the compiler to stop with a non-zero exit code for those
>>who do automated builds. If it didn't, they'd miss the warnings as the
>>scroll off the screen.
> 
> 
> That effectively makes all warnings into errors which is very different than just showing warnings and letting the user do what they want to. Capturing output so that it doesn't scroll off the screen is covered in programming 101 so I would assume people can deal with multiple comments. 
> 
> 

Ben Hinkle wrote:
>>>one question, though. why doesn't the compiler stop compiling when it
>>>gives me warnings? shouldn't warnings just warn and still compile?
>>
>>The warnings cause the compiler to stop with a non-zero exit code for those
>>who do automated builds. If it didn't, they'd miss the warnings as the
>>scroll off the screen.
> 
> 
> That effectively makes all warnings into errors which is very different than just showing warnings and letting the user do what they want to. Capturing output so that it doesn't scroll off the screen is covered in programming 101 so I would assume people can deal with multiple comments. 
> 
> 

How about aping the -Werror option of gcc ("make all warnings into errors") for use in automated builds?

Bastiaan.

"Andy Friesen" <andy@ikagames.com> wrote in message news:d0tvg3$1h4v$1@digitaldaemon.com...
> Walter wrote:
>> Cleaning out the attic of lots of minor bug fixes.
>>
>> http://www.digitalmars.com/d/changelog.html
>
>>  Added pragma(lib, "library name");
>
> Excellent.
>
> Making library distribution simple just got a whole lot simpler:

Indeed!  I always thought that there should be a command to link a library without having to use the command line.  Now we can put the pragma(lib) command in our import modules.  Then, just import and everything works.

And the abstract class keyword does EXACTLY what I've been wanting to do for a long time!  No more private ctors to make base classes un-instantiate-able!

This is quite a juicy release.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:d0vasn$3mj$1@digitaldaemon.com...
> And the abstract class keyword does EXACTLY what I've been wanting to do
for
> a long time!  No more private ctors to make base classes un-instantiate-able!

Abstract was supposed to do this from the beginning, I'd just neglected making it work right.

> This is quite a juicy release.

I guess it was more than I thought <g>. There are still more cobwebbed problems I need to clean off my desk, and I really want to get them done so we can do 1.0.

You're right. I introduced a botch in the name mangling system. I'll try and get that fixed today.

"Kris" <Kris_member@pathlink.com> wrote in message news:d0trn2$1c63$1@digitaldaemon.com...
> In article <d0tn63$18an$1@digitaldaemon.com>, Walter says...
> >
> >Cleaning out the attic of lots of minor bug fixes.
>
> Mango produced three or four of the following warning types, which appear
to be
> bogus: "warning - function mango.io.FileConduit.FileConduit.copy no return
at
> end of function"
>
> # FileConduit copy (FilePath source)
> # {
> #     auto FileConduit fc = new FileConduit (source);
> #     super.copy (fc);
> #     return this;
> # }

I'll try and fix that.

> Moving along, Mango conjures up a thicket of "implicit conversion of type
int to
> bit can cause loss of data". These are caused by a variation upon this
kind of
> statement:
>
> # bool x (int y, int z)
> # {
> #     return y > z;
> # }

This D may need to allow to pass without the warning.

> Then, there's a few similar warnings where the sign bit is lost through a legitimate conversion. There's also a few narrowing conversions when
interfacing
> with Win32 functions, and so on. The latter are occasionally related to
enum
> specifications, which could be changed.
>
> All in all the warnings found one bug, caused me to cleanup the 'sign' of
a few
> declarations (potentially better codegen), and pointed out that various
methods
> in std.date return a 64-bit long instead of something much smaller (how
many
> hours /are/ there in a day? :-)
>
> Definately worthwhile, IMO. I could understand if some complained about
"not
> seeing the forest for the trees", but that's life with a type-system of
this
> nature.
>
> I do wonder if there's any value in filtering the warnings somehow. For
example,
> the "int to bit" conversion for returns is one of those "idioms" that
Walter
> talks about; and Mango produces lots of 'em! But then we'd perhaps have to
get
> into warning levels? Oh well.
>
> Thanks, Walter. I think this was absolutely worthwhile.

You're welcome.

In article <d0vhko$a6j$2@digitaldaemon.com>, Walter says...
>
>You're right. I introduced a botch in the name mangling system. I'll try and get that fixed today.

Could you also fix the erroneous warning noted in post "Mango and -w" ?

"Kris" <Kris_member@pathlink.com> wrote in message news:d0trn2$1c63$1@digitaldaemon.com...
> Mango produced three or four of the following warning types, which appear
to be
> bogus: "warning - function mango.io.FileConduit.FileConduit.copy no return
at
> end of function"
>
> # FileConduit copy (FilePath source)
> # {
> #     auto FileConduit fc = new FileConduit (source);
> #     super.copy (fc);
> #     return this;
> # }

I tried to reproduce the problem with the following:

class A { A copy(); }

class B : A
{
    B copy ()
    {
        auto B fc = new B ();
        super.copy ();
        return this;
    }
}

but no dice. It works fine.

In article <d0vsg8$le1$1@digitaldaemon.com>, Walter says...
>
>
>"Kris" <Kris_member@pathlink.com> wrote in message news:d0trn2$1c63$1@digitaldaemon.com...
>> Mango produced three or four of the following warning types, which appear
>to be
>> bogus: "warning - function mango.io.FileConduit.FileConduit.copy no return
>at
>> end of function"
>>
>> # FileConduit copy (FilePath source)
>> # {
>> #     auto FileConduit fc = new FileConduit (source);
>> #     super.copy (fc);
>> #     return this;
>> # }
>
>I tried to reproduce the problem with the following:
>
>class A { A copy(); }
>
>class B : A
>{
>    B copy ()
>    {
>        auto B fc = new B ();
>        super.copy ();
>        return this;
>    }
>}
>
>but no dice. It works fine.
>
>


Hmmmm. I figured it was just the implicit try/catch (via the 'auto') that was causing the problem. Indeed, temporarily removing the 'auto' causes the warning to be inhibited. Don't know what to tell you about this one.


I was going to post other samples from Mango that produce the same error, but closer inspection revealed the warning was actually correct. Those examples are thread workers, with try/catch around the body which contains an embedded return ~ said workers don't have a return at the end, which they perhaps should ~ some more subtle bug-fixes to chalk-up for warnings?

Ben Hinkle wrote:
>>>one question, though. why doesn't the compiler stop compiling when it
>>>gives me warnings? shouldn't warnings just warn and still compile?
>>
>>The warnings cause the compiler to stop with a non-zero exit code for those
>>who do automated builds. If it didn't, they'd miss the warnings as the
>>scroll off the screen.
> 
> 
> That effectively makes all warnings into errors which is very different than just showing warnings and letting the user do what they want to. Capturing output so that it doesn't scroll off the screen is covered in programming 101 so I would assume people can deal with multiple comments. 

I agree. Also, if someone is "responsible" enough to want warnings, they should be responsible enough to start fixing the warnings at the bottom of the list until the top of at list are visible.

DMD should produce as many warnings as possible (when the switch is turned on). Let the user worry about capturing the information and applying the appropriate fixes. ;)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/