November 2014 - ghc-tickets

Re: [GHC] #6022: GHC infers over-general types
by GHC 27 Nov '14

27 Nov '14

#6022: GHC infers over-general types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8883 Test Case: | typecheck/should_fail/T6022 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T6022 Comment: And the test was actually there, just marked as broken! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6022#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6022: GHC infers over-general types
by GHC 27 Nov '14

27 Nov '14

#6022: GHC infers over-general types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8883 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"4721167a0118e4c8bc6c8266c3357a8a2ac4f4e2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4721167a0118e4c8bc6c8266c3357a8a2ac4f4e2" Trac #6022 is actually fine now }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6022#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9838: PatternSynonyms and ConstraintKinds should not be required at the use site.
by GHC 27 Nov '14

27 Nov '14

#9838: PatternSynonyms and ConstraintKinds should not be required at the use site. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | 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: -------------------------------------+------------------------------------- Currently both PatternSynonyms and ConstraintKinds have to be enabled at the usage site, not just at the construction site. This pretty much ensures that they'll never be used to 'clean up' or virtualize an existing API, because switching to pattern synonyms for constructors or switching a 'class alias' to a type synonym immediately break all users. For instance right now, as a user I universally write {{{ class (Foo a, Bar a) => Baz a instance (Foo a, Bar a) => Baz a }}} rather than {{{ type Baz a = (Foo a, Bar a) }}} because the former gives a better user experience and I can pay all the extensions needed for it at the definition site, rather than have all my users pay them at the use site. I'd like to propose that the language extensions for these two cases, `PatternSynonyms` and `ConstraintKinds` only be required at the definition site, rather than at the use site. The former is definitely needed at the definition site because of the new syntax, but unless you explicitly re-export a pattern, no syntax changes at the usage site. This would also be more consistent with existing policies for other extensions: We don't require users to turn on FunctionalDependencies to get the benefit of functional dependencies, or to turn on MultiParamTypeClasses to use an MPTC, merely to define them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9838> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched
by GHC 27 Nov '14

27 Nov '14

#5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched -------------------------------------+------------------------------------- Reporter: mjo | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.1 Resolution: | Keywords: warnings Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"a67ebbecfb10c91bb2793cb2f7d91f25aa23e493/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a67ebbecfb10c91bb2793cb2f7d91f25aa23e493" Resume reporting incomplete pattern matches for record updates They were being inadvertently suppressed, even if you said -fwarn- incomplete-record-updates See Trac #5728 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5728#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched
by GHC 27 Nov '14

27 Nov '14

#5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched -------------------------------------+------------------------------------- Reporter: mjo | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.1 Resolution: | Keywords: warnings Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Also you need `-fwarn-incomplete-record-updates` to see the warning; for some reason this flag is explicitly not in `-Wall` according to the user manual. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5728#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5780: -faggressive-primops change caused a failure in perf/compiler/parsing001
by GHC 27 Nov '14

27 Nov '14

#5780: -faggressive-primops change caused a failure in perf/compiler/parsing001 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.2.2 Resolution: | 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 (by simonpj): Yes I think it should stay open. I've forgotten the context to be honest. I'll add it to my list! (But I don't expect to pay attention to it for some time, so others feel free to grab it.) Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5780#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5763: Confusing error message
by GHC 27 Nov '14

27 Nov '14

#5763: Confusing error message -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.2.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: indexed-types/should_fail/T5763 => * resolution: => fixed Comment: Well we indeed no longer use insoluble constraints to rewrite others, so yes, I think we can close this. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5763#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched
by GHC 27 Nov '14

27 Nov '14

#5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched -------------------------------------+------------------------------------- Reporter: mjo | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.1 Resolution: | Keywords: warnings Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: george.karachalias@…, tom.schrijvers@… (added) Comment: Actually not. The warning was being suppressed by {{{ handleWarnings = if isGenerated origin then discardWarningsDs else id }}} in `matchWrapper`, which is really intended to suppress warnings in code generate by `deriving` etc. I've fixed this which makes the warning come back. It's really is part of the pattern-match-fixup problem. Fortunately, Geroge K and Tom S are working on this. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5728#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4243: Make a proper options parser for the RTS
by GHC 27 Nov '14

27 Nov '14

#4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime | Version: 6.13 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9839 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * related: => #9839 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4243#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9837: Introduce a logging API to GHC
by GHC 26 Nov '14

26 Nov '14

#9837: Introduce a logging API to GHC -------------------------------------+------------------------------------- Reporter: rodlogic | 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: -------------------------------------+------------------------------------- I don't have a lot of mileage with the code base, but I do see that there is no standard logging API that the various components can use (or there is and it just needs to be used??). At least, I would expect to see a standard API to generate log entries with the following minimal parts: * timestamp * Log level - for example, ERROR, WARN, INFO, DEBUG, TRACE (-v[1-3] could map to INFO, DEBUG and TRACE. Log levels are inclusive so INFO also means WARN and ERROR. * Component name - so we know what is the source of the log message. At least I would expect to see (Desugarer, Typechecker, Parser, etc) * the message It would also mean a single back-end to collect the log messages and dump them to a file, stdout/stderr, etc. There are many other features beyond this point (customize log messages, colors, filtering, etc), but in terms of the API that is used throughout the code base, it should be simple. Was this already discussed in the past? Is there already such an API in the codebase? Is there an existing library that we could use to achieve the same? Any other ideas? This ticket is mostly to spawn a discussion about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9837> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3