On Fri, Jan 23, 2015 at 12:55 PM, Konstantine Rybnikov wrote:

Tuncer,

If warnings will be treated as errors it's fine to have "Error:" shown for them, I think.

Yes, it will be printed the same way and have the same severity as any other error. I think I have misinterpreted your initial post, sorry about that. To correct myself, compilers do print "error:" prefixes, and for example your usual CC will print the following: filename:row:column: error: error-message filename:row:column: warning: warning-message So on second thought your suggestion makes sense :).

On Fri, Jan 23, 2015 at 1:14 PM, Tuncer Ayaz wrote:

...

On Fri, Jan 23, 2015 at 12:04 PM, Konstantine Rybnikov wrote:

...

Hi!

I'm bringing this up once again. Can we add "Error:" in the output of an error in a similar way ghc shows "Warning:" for warnings? Main reasoning is that, for example, on a build-server, where you have lots of cores to build your program, if you get an error, it gets lost somewhere in the middle of compiler's output in all other "Warning" messages you get, since error is not always shown last on multi-core build.

Isn't kind of a compiler convention that ""Warning:" is only prepended if an issue is treated as a warning. I mean, you can enable -Werror and treat all or specific warnings as errors as well.

There has been quite a long email trail about this. Would someone like to summarise in a Trac ticket feature request? Assuming there's a consensus, would anyone like to offer a patch? Should not hard. There will be an annoying cutover problem, because many regression tests will start failing. Anyone offering the patch would need to include all of those. Of course it'll affect other packages too -- hence the need for consensus. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Sven | Panne | Sent: 25 January 2015 11:28 | To: Konstantine Rybnikov | Cc: ghc-devs@haskell.org | Subject: Re: Put "Error:" before error output | | 2015-01-23 12:55 GMT+01:00 Konstantine Rybnikov : | > If warnings will be treated as errors it's fine to have "Error:" shown | for | > them, I think. | | +1 for this, it is how e.g. gcc behaves with -Werror, too. So unless | there is a compelling reason to do things differently (which I don't | see here), I would just follow conventional behavior instead of being | creative. :-) | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs

Yitzchak, Sorry, I didn't get what you mean. Do you mean `error` [0] function from Prelude? The discussion is currently not regarding runtime program behavior, nor it is about `error` function. It's rather regarding compiler output message on compilation failure, so it shouldn't get mixed with your program's runtime behavior in any way. See ticket #10021 [1] for examples of what I'm talking about (I'm adding "motivation" section right now). [0]: http://hackage.haskell.org/package/base-4.7.0.2/docs/Prelude.html#v:error [1]: https://ghc.haskell.org/trac/ghc/ticket/10021#modify On Tue, Jan 27, 2015 at 6:49 PM, Yitzchak Gale wrote:

-1

There are common idioms that rely on the current behavior, so I think this would break a lot code.

Examples:

In command line programs, it is very common to use "error" for printing the usage message.

Many programs use "error" as a general way to exit from pure code with a message.

I'm not commenting about whether or not those are good practice, just reporting that they are out there.

I would be in favor of this though if it is off by default and is turned on by an option or pragma. But not just -Werror, though, except for messages that would otherwise have been prefixed by "Warning", like the current behavior.

Thanks, Yitz

On Fri, Jan 23, 2015 at 1:04 PM, Konstantine Rybnikov wrote:

...

Hi!

I'm bringing this up once again. Can we add "Error:" in the output of an error in a similar way ghc shows "Warning:" for warnings? Main reasoning is that, for example, on a build-server, where you have lots of cores to build your program, if you get an error, it gets lost somewhere in the middle of compiler's output in all other "Warning" messages you get, since error is not always shown last on multi-core build.

Thanks.

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Yes, correct. But I think ghci's errors are already distinguishable from `error`, e.g. this: ``` Prelude> :set -Wall Prelude> :load test [1 of 1] Compiling Main ( test.hs, interpreted ) test.hs:1:1: Warning: Top-level binding with no type signature: main :: IO () Ok, modules loaded: Main. Prelude> let main = asdasdasd <interactive>:6:12: Not in scope: ‘asdasdasd’ *Main> :load test2 [1 of 1] Compiling Main ( test2.hs, interpreted ) test2.hs:1:8: Not in scope: ‘foo’ Failed, modules loaded: none. Prelude> error "foo" *** Exception: foo ``` will change to: ``` Prelude> :set -Wall Prelude> :load test [1 of 1] Compiling Main ( test.hs, interpreted ) test.hs:1:1: Warning: Top-level binding with no type signature: main :: IO () Ok, modules loaded: Main. Prelude> let main = asdasdasd <interactive>:6:12: Not in scope: ‘asdasdasd’ *Main> :load test2 [1 of 1] Compiling Main ( test2.hs, interpreted ) test2.hs:1:8: Error: Not in scope: ‘foo’ Failed, modules loaded: none. Prelude> error "foo" *** Exception: foo ``` Don't think this will cause any trouble (well, except for current tests that check for output, which was mentioned in ticket #10021, but I hope it's not that big of a problem). On Tue, Jan 27, 2015 at 7:05 PM, Brandon Allbery wrote:

On Tue, Jan 27, 2015 at 12:02 PM, Konstantine Rybnikov wrote:

...

Sorry, I didn't get what you mean. Do you mean `error` [0] function from Prelude? The discussion is currently not regarding runtime program behavior, nor it is about `error` function. It's rather regarding compiler output message on compilation failure, so it shouldn't get mixed with your program's runtime behavior in any way

...unless using runhaskell/runghc.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net