- ghc-tickets - Haskell.org

Re: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs
by GHC 09 Mar '15

09 Mar '15

#2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: Type: bug | thoughtpolice Priority: low | Status: new Component: Compiler (NCG) | Milestone: 7.12.1 Resolution: | Version: 6.11 Operating System: Unknown/Multiple | Keywords: codegen Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * priority: normal => low Comment: As austin writes in Phab:D694, we are not going to able to change that in the near future anyways. Lowering severity. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2725#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs (was: Remove Hack in compiler/nativeGen/MachCodeGen.hs)
by GHC 09 Mar '15

09 Mar '15

#2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Compiler (NCG) | Milestone: 7.12.1 Resolution: | Version: 6.11 Operating System: Unknown/Multiple | Keywords: codegen Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I would not be surprised if it was better (equal or faster performance and smaller object file size) to use 32-bit offsets anyways, has anyone done a performance test? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2725#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4372: Extending quasiquotation support
by GHC 09 Mar '15

09 Mar '15

#4372: Extending quasiquotation support -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): songzh: `'[' quoterExp '|' strings '|]'` is not really possible since it looks too much like any list comprehension. If you wrote `[ x * y | x <- [1,2,3], y <- [4,5] ]` is that a list comprehension or the beginning of a quasiquote, that might terminate arbitrarily far away? With quasiquotes as they stand now you cannot write a list comprehension like `[x|x<-[1,2,3]]`; you must include a non-identifier character before the `|`. That's a mild imposition, but it is already something, and I don't see how the syntax can be pushed much farther. As for the ticket in general: Quasiquotes offer two conveniences over TH splices: overloading the same name to refer to expression, pattern, etc. splice generators; and raw string literals (terminated by `|]`). The overloading can be nice, but is never essential (the resolution is purely syntactic anyway) and often you only need the expression quoter. The raw string literal syntax is quite useful, but it's a problem that only needs to be solved once. Specifically, once you have a quasiquoter `q` that produces string literals, you can rewrite any {{{ [foo|bar|] }}} as {{{ $(foo [q|bar|]) -- this 'foo' is the old 'quoteExp foo'. -- at worst, you could call it 'fooE' or something. }}} which is already not that much longer; and any syntax for parameterized quasiquoters would have to be longer than `[foo arg|bar|]`, so there's very little room left for improvement over what we can build with the pieces we have today. So basically I agree with Gershom: the workaround he suggested is always possible, it's pretty lightweight, and it's hard to see how a new syntax for this would really be worth it, when it can't gain much (and has the opportunity cost of not being able to use the syntax for something else). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4372#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8780: abs for IEEE floating point is slightly wrong.
by GHC 09 Mar '15

09 Mar '15

#8780: abs for IEEE floating point is slightly wrong. ------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Evaluating abs(-0) gives the answer -0. This unexpected since it breaks invariants like 1/(abs x) >= 0. So abs(-0) should be 0. This is also the norm for other languages. Together with this change, signum should also be changed so signum(-0) is -0. This maintains the invariant abs x * signum x == x. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8780> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10147: Clang CPP adds extra newline character
by GHC 08 Mar '15

08 Mar '15

#10147: Clang CPP adds extra newline character -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: cpp | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Running the following command (taken from the settings file) {{{ cat ImportsSemi.hs | gcc -E -undef -traditional -Wunicode -Wno-invalid-pp- token -Wno-unicode - > out.hs }}} on any file results in a file which has an extra newline character appended to the end. This result is different from when `gcc` is used as the preprocessor, in this case no extra newline is appended. I appreciate that this isn't important to most users but it is important for ghc-exactprint. With the extra newline character the EOF marker is moved one line further down. When we come to output the AST, we also get an extra newline at the bottom of the file which breaks roundtripping. {{{ > gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.0.0 Thread model: posix }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #1831: reify never provides the declaration of variables
by GHC 08 Mar '15

08 Mar '15

#1831: reify never provides the declaration of variables -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by tomberek): * cc: tomberek@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1831#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10142: Documentation for Ix is contradictory around minimal definition
by GHC 08 Mar '15

08 Mar '15

#10142: Documentation for Ix is contradictory around minimal definition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.8.4 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The Haddock documentation for `Ix` [http://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Ix.html here] says that the minimal definition requires `range`, `index`, and `inRange`. But then it says that the minimal definition requires `range` and `inRange`. It seems that Haddock is inferring a `MINIMAL` definition where none is in the code. Perhaps a `MINIMAL` should be added. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10142> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable`
by GHC 08 Mar '15

08 Mar '15

#9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- comment:ticket:9111:16 explains that import-cycles containing `Data.Typeable.Internal` (which provides the `Typeable` class `AutoDeriveTypeable` needs to be loaded for being able to operate) inside `base` make it difficult to use `AutoDeriveTypeable`, as well as making it more difficult to de-cycle the `base` import-dependency graph (see also attachment:typeable_deps.pngtypeable_deps.png) This ticket is about trying to find a way to restructure `base` in order to allow to define the `Typeable` instances directly at the type's defining site (and thus allow the use of `AutoDeriveTypeable`) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 08 Mar '15

08 Mar '15

#7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:16 ekmett]: > Otherwise I'm going to have to start putting CPP around the set of directives for the module. Why CPP? Afaik, `{-# LANGUAGE ConstrainedClassMethods #-}` is supported since GHC 7.0.1 ... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7854#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 07 Mar '15

07 Mar '15

#7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by ekmett): FWIW- This started breaking some pre-existing code: https://hackage.haskell.org/package/semigroupoids-1.2.6/docs/src/Data- Functor-Alt.html#some Would having `FlexibleContexts` imply `ConstrainedClassMethods` as well also be too much to ask? Otherwise I'm going to have to start putting CPP around the set of directives for the module. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7854#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0