Re: [GHC] #3261: Some warnings disappear with -Werror
#3261: Some warnings disappear with -Werror
-+--
Reporter: igloo |Owner: simonpj
Type: bug | Status: new
Priority: normal|Milestone: 6.12.1
Component: Compiler | Version: 6.11
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase: tcfail204 | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by simonpj):
Fixed by
{{{
Thu May 28 17:49:00 BST 2009 simo...@microsoft.com
* Fix Trac #3261: make default types play nice with -Werror
The trial-and-error for type defaults was not playing nicely with
-Werror. The fix is simple.
M ./compiler/typecheck/TcSimplify.lhs -6 +7
}}}
That now shows up a warning as an error, so you need this too:
{{{
Thu May 28 17:45:25 BST 2009 simo...@microsoft.com
* Remove type-ambiguous (fromIntegral 0)::Int, replacing it with just 0
This unnecessary ambiguity has been there for ages, and is now rejected
by -Werror, after fixing #3261
M ./compiler/ghci/ByteCodeAsm.lhs -1 +1
}}}
And there's a similar case in `Float.lhs`, still to fix.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3261#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3257: System.Exit.exitWith exits current thread, not program
#3257: System.Exit.exitWith exits current thread, not program
--+-
Reporter: Bart Massey|Owner: simonmar
Type: bug| Status: closed
Priority: normal |Milestone: 6.12.1
Component: libraries (other) | Version: 6.10.1
Severity: minor | Resolution: fixed
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
--+-
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
* milestone: = 6.12.1
Comment:
Fixed:
{{{
Thu May 28 05:37:38 PDT 2009 Simon Marlow marlo...@gmail.com
* Fix #3257: document that exitWith in a forkIO'd thread does not exit
the process
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3257#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3261: Some warnings disappear with -Werror
#3261: Some warnings disappear with -Werror -+-- Reporter: igloo |Owner: simonpj Type: bug | Status: closed Priority: normal|Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Testcase: tcfail204 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonpj): * status: new = closed * resolution: = fixed Comment: OK library patches pushed, so I'm closing this. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3261#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3262: Identifiers beginning with _ should not be considered for shadowing
#3262: Identifiers beginning with _ should not be considered for shadowing
-+--
Reporter: batterseapower|Owner:
Type: proposal | Status: closed
Priority: normal|Milestone:
Component: Compiler | Version: 6.10.2
Severity: trivial | Resolution: fixed
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Changes (by simonpj):
* status: new = closed
* difficulty: = Unknown
* resolution: = fixed
Comment:
Good idea. Done
{{{
Thu May 28 16:23:59 BST 2009 simo...@microsoft.com
* Fix Trac #3262: suppress name-shadow warning for _names
Adopt Max's suggestion for name shadowing, by suppressing shadowing
warnings for variables starting with _. A tiny bit of refactoring
along the way.
M ./compiler/basicTypes/NameSet.lhs -1 +1
M ./compiler/basicTypes/OccName.lhs -8 +7
M ./compiler/rename/RnEnv.lhs -1 +3
M ./compiler/typecheck/TcInstDcls.lhs -1 +1
M ./docs/users_guide/using.xml +5
}}}
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3262#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3259: A module-local combinator using Control.Parallel.par behaves differently than when it's imported
#3259: A module-local combinator using Control.Parallel.par behaves differently
than when it's imported
-+--
Reporter: blamario |Owner:
Type: bug | Status: closed
Priority: normal|Milestone:
Component: Compiler | Version: 6.11
Severity: normal| Resolution: fixed
Keywords:| Difficulty: Unknown
Testcase:| Os: Linux
Architecture: x86 |
-+--
Changes (by simonpj):
* status: new = closed
* resolution: = fixed
Comment:
OK so after talking to Simon I indeed moved the exposure of `lazy` into
`CorePrep`. That certainly fixes the bug.
{{{
Fri May 29 00:20:20 PDT 2009 simo...@microsoft.com
* Fix Trac #3259: expose 'lazy' only after generating interface files
Ignore-this: 3c762bda546981c4b4f01d28b8586ff8
This patch fixes an insidious and long-standing bug in the way that
parallelism is handled in GHC. See Note [lazyId magic] in MkId.
...snip...
The downside is that a little less optimisation may happen on programs
that use 'lazy'. And you'll only see this in the results -ddump-prep
not in -ddump-simpl. So KEEP AN EYE OUT (Simon and Satnam especially).
Still, it should work properly now. Certainly fixes #3259.
M ./compiler/basicTypes/MkId.lhs -18 +23
M ./compiler/coreSyn/CorePrep.lhs -2 +10
M ./compiler/stranal/WorkWrap.lhs -10 +3
}}}
I have not added a test case, because I can't see a simple way to test it.
But please do see if things improve.
Do watch out for loss of optimisation as a result. Simon and I do not
think it'll be important, but we've been wrong before.
For example, in your program you have way too many `lazy` calls:
{{{
parallelize a b = lazy a `par` (lazy b `pseq` (a, b))
}}}
Here the `lazy` calls are completely unnecessary, and indeed they (now)
make the code a bit less efficient. Instead you can say
{{{
parallelize a b = a `par` (b `pseq` (a, b))
}}}
Thank you for identifying such an insidious bug.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3259#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3177: support quasiquoting for types
#3177: support quasiquoting for types -+-- Reporter: claus |Owner: Type: feature request | Status: closed Priority: normal|Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Testcase: th/T3177, T3177a | Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonpj): * testcase: = th/T3177, T3177a * status: new = closed * resolution: = fixed Comment: OK, I've added a couple of tests and am closing. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3177#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3156: Error on +RTS kHugeNumber
#3156: Error on +RTS kHugeNumber
-+--
Reporter: zachk |Owner: simonmar
Type: bug | Status: closed
Priority: normal|Milestone: 6.12.1
Component: Runtime System| Version: 6.10.2
Severity: minor | Resolution: fixed
Keywords: 6.10.1||6.10.2 Stack | Difficulty: Unknown
Testcase:| Os: Linux
Architecture: x86 |
-+--
Changes (by simonmar):
* status: new = closed
* component: Compiler = Runtime System
* resolution: = fixed
Comment:
Fixed. There were a series of tweaks necessary to get this fully cleaned
up:
{{{
Thu May 28 06:33:57 PDT 2009 Simon Marlow marlo...@gmail.com
* Fix #3156: ensure preconditions of splitLargeBlock()
Thu May 28 06:34:40 PDT 2009 Simon Marlow marlo...@gmail.com
* Round stack size to a whole number of megablocks
Fri May 29 02:07:58 PDT 2009 Simon Marlow marlo...@gmail.com
* Fix bug in previous change: allocate the correct size
Fri May 29 02:08:27 PDT 2009 Simon Marlow marlo...@gmail.com
* don't shrink the stack smaller than the value set by +RTS -ksize
}}}
These fix a panic in the RTS when using a large `+RTS -ksize`. I'm not
sure we should merge, since there's a good workaround: don't use `+RTS
-ksize` at all (the RTS will grow the stack as necessary).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3156#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3263: Warnings for monadic values not used
#3263: Warnings for monadic values not used
--+-
Reporter: NeilMitchell | Owner:
Type: feature request | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.10.2
Severity: normal| Resolution:
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
--+-
Comment (by NeilMitchell):
We don't need to worry about non-returning functions. Remember {{{do ... ;
exitWith ...}}} won't be an error, only if they put a statement after it -
which is probably an error since you know it won't execute.
I don't suggest giving specific errors in specific circumstances, it's not
something GHC does in general. For this I would recommend programmers use
HLint, and I'll make {{{_ - mapM}}} be a suggestion there.
My guess would be hardcode () and any Monad, as a first step that is very
nearly perfect and fairly simple.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3263#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3264: Real World Haskell book example issue
#3264: Real World Haskell book example issue -+-- Reporter: oddy |Owner: Type: run-time performance bug | Status: closed Priority: normal|Milestone: Component: GHCi | Version: 6.10.1 Severity: normal| Resolution: duplicate Keywords: panic!| Difficulty: Unknown Testcase:| Os: Windows Architecture: x86 | -+-- Changes (by simonmar): * status: new = closed * difficulty: = Unknown * resolution: = duplicate Comment: duplicate of #2973. Thanks for the report! (and the screenshot!) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3264#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3098: loadObj: failed
#3098: loadObj: failed -+-- Reporter: rheineke |Owner: Type: bug | Status: closed Priority: low |Milestone: 6.12.1 Component: GHCi | Version: 6.10.1 Severity: normal| Resolution: duplicate Keywords: undefined impossible | Difficulty: Unknown Testcase:| Os: MacOS X Architecture: x86 | -+-- Changes (by simonmar): * status: new = closed * component: Compiler = GHCi * resolution: = duplicate Comment: closing as duplicate of #2973, it's been a couple of months since we asked for feedback. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3098#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3218: Proposal: System.Posix.fdReadBuf/fdWriteBuf
#3218: Proposal: System.Posix.fdReadBuf/fdWriteBuf
-+--
Reporter: simonmar |Owner: simonmar
Type: proposal | Status: closed
Priority: normal|Milestone: Not GHC
Component: libraries/unix| Version: 6.10.2
Severity: normal| Resolution: fixed
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
Comment:
pushed.
{{{
Fri May 29 13:19:41 BST 2009 Simon Marlow marlo...@gmail.com
* add fdReadBuf, fdWriteBuf
Fri May 29 13:56:09 BST 2009 Simon Marlow marlo...@gmail.com
* add test for fdReadBuf/fdWriteBuf
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3218#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #3265: Type operators can be defined without the TypeOperators extension flag
#3265: Type operators can be defined without the TypeOperators extension flag
-+--
Reporter: nibro | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 6.10.2| Severity: normal
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
The following code is accepted without any extension flags given:
{{{
data a :*: b = Foo a b
type a :+: b = Either a b
}}}
However, to use the defined types we need the TypeOperators flag, without
it the following code will not be accepted:
{{{
f :: Int :*: Int - Int
f (Foo x y) = x+y
}}}
It seems clear to me that GHC should not accept the former either without
the TypeOperators extension enabled.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3265
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
