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.
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.
Tuncer, If warnings will be treated as errors it's fine to have "Error:" shown for them, I think. On Fri, Jan 23, 2015 at 1:14 PM, Tuncer Ayaz <tuncer.ayaz@gmail.com> 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.
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.
2015-01-23 12:55 GMT+01:00 Konstantine Rybnikov <k-bx@k-bx.com>:
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. :-)
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 <k-bx@k-bx.com>: | > 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
I'd like to try and do both, since this shouldn't be hard and doesn't look like top-priority. On Mon, Jan 26, 2015 at 2:24 PM, Simon Peyton Jones <simonpj@microsoft.com> wrote:
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 <k-bx@k-bx.com>: | > 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
-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 <k-bx@k-bx.com> 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
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 <gale@sefer.org> 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 <k-bx@k-bx.com> 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
On Tue, Jan 27, 2015 at 12:02 PM, Konstantine Rybnikov <k-bx@k-bx.com> 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
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 <allbery.b@gmail.com> wrote:
On Tue, Jan 27, 2015 at 12:02 PM, Konstantine Rybnikov <k-bx@k-bx.com> 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
There's a ticket for this now. https://ghc.haskell.org/trac/ghc/ticket/10021 Do add comments there, or they'll get lost. But I think you are misunderstanding the proposal (which admittedly is not stated clearly). It only affects the error messages produced by GHC itself. There is no proposal to change the behaviour of the 'error' function. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Yitzchak Gale | Sent: 27 January 2015 16:49 | To: Konstantine Rybnikov | Cc: ghc-devs@haskell.org | Subject: Re: Put "Error:" before error output | | -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 <k-bx@k-bx.com> | 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 | > | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs
participants (7)
-
Brandon Allbery -
Jan Stolarek -
Konstantine Rybnikov -
Simon Peyton Jones -
Sven Panne -
Tuncer Ayaz -
Yitzchak Gale