- ghc-tickets - Haskell.org

Re: [GHC] #5654: Profiling semantics bug
by GHC 18 Dec '16

18 Dec '16

#5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"90cfa84981ee1f9fb756a3af1bd707674c18c034/ghc" 90cfa849/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90cfa84981ee1f9fb756a3af1bd707674c18c034" Run some tests with -fexternal-interpreter -prof We don't have any other tests for this, except one Template Haskell test. This would have caught the bug I just fixed in D2868, at least when validating with profiling on. Test Plan: Ran tests Reviewers: niteria, austin, erikd, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2869 GHC Trac Issues: #5654 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3384: Add HsSyn prettyprinter tests
by GHC 18 Dec '16

18 Dec '16

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2752 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina <tamar@…>): In [changeset:"d88efb7048160c3031eadb4f3b729e9fe406414d/ghc" d88efb7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d88efb7048160c3031eadb4f3b729e9fe406414d" Fix Pretty printer tests on Windows Summary: D2752 added some tests which escapes string literals. This means newlines are converted before they get normalized by the IO functions. So on Windows \r\n would be in the output while \n was expected. Test Plan: make test -C testsuite/tests/printer Reviewers: austin, bgamari, alanz Reviewed By: alanz Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2873 GHC Trac Issues: #3384 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10723: Make declarations in signatures "weakly bound" until they are used
by GHC 17 Dec '16

17 Dec '16

#10723: Make declarations in signatures "weakly bound" until they are used -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: Component: Package | Version: 7.11 system | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Suppose you are the author of a library in a Backpack world, and you publish a signature package which defines the entire public facing interface of your library. The library `foo` which uses of your library decides to `include` the signature package for convenience, but actually only uses a small portion of the API. Later, you make a BC-breaking change in one part of the library and release a new signature package. The library `bar` which uses your library includes this NEW signature package, using a different portion of the API which was unaffected by the by the BC change. Now, a hapless user tries to use `foo` and `bar`, but Backpack complains that the requirements are not compatible. What's the problem here? The practice of writing reusable signature packages for people to use caused the requirements of `foo` and `bar` to become too large, since they included a lot of junk that these libraries didn't actually use. It would be far better if you could `include` a signature package, but only "require" the bits of it that you actually used! How can we achieve this? 1. We augment the `ModIface` of signature merges (#10690) to record whether or not a declaration was (transitively) used or not by some module. Used declarations must be filled, but unused ones are treated more flexibly: if they are merged with a different, incompatible but used requirement, they disappear, and we don't check if an implementing module actually implemented the declaration. (If two unused incompatible requirements are merged, we just erase the name.) 2. How do we compute the usage info? I think it will have to be done during shaping (which runs the renamer). We only need to annotate each declaration a signature with the transitive set of names from other signatures that it has used--this can be incrementally computed. (It's not necessary to annotate declarations in modules, since they are always assumed to use holes). Then whenever a declaration from a signature is used in a module, we mark its transitive set as used. This information can then be used later when constructing the merged `ModIface` which represents the "public requirement" of the package. So, for example, a package containing only signatures would contain all unused declarations (however, they may start being used by a package which includes them). Any unused declaration which isn't mixed with another incompatible declaration can be imported (causing it to be used), but we will complain if you try to use a name and we can't tell which declaration to use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 17 Dec '16

17 Dec '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"8f71d9581ee0a1826c0105e51a7048f0c7669492/ghc" 8f71d958/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8f71d9581ee0a1826c0105e51a7048f0c7669492" Enable split sections by default where possible On non-windows platforms with GNU ld, enable SplitSections in the GHC build by default. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: DemiMarie, thomie Differential Revision: https://phabricator.haskell.org/D1800 GHC Trac Issues: #11445 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9601: Make the rewrite rule system more powerful
by GHC 17 Dec '16

17 Dec '16

#9601: Make the rewrite rule system more powerful -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more | Type of failure: than a week) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It would be amazing if the current RULES system could be upgraded to include various predicates, or even into a full-on strategic programming system. This would allow far far more optimisations to be possible, rather than the current conservative system where you have to make sure that the optimisations ALWAYS apply. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9601> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11784: panic "hscCmmFile: no_mod" with `-v2 and above
by GHC 17 Dec '16

17 Dec '16

#11784: panic "hscCmmFile: no_mod" with `-v2 and above -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Initailly found this on powerpc when debugging #11773, but it also happens on x86_64. The command line: {{{ inplace/bin/ghc-stage1 -static -H64m -O0 -Wall -v2 -Iincludes \ -Iincludes/dist -Iincludes/dist-derivedconstants/header \ -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build \ -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts \ -irts/dist/build -irts/dist/build/autogen -Irts/dist/build \ -Irts/dist/build/autogen -O2 -Wnoncanonical-monad-instances -c\ rts/StgStartup.cmm -o rts/dist/build/StgStartup.o }}} panics with a message: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20160402 for powerpc-unknown-linux): hscCmmFile: no_mod }}} The only thing that was added to the command line that is different from the normal build command is the `-v2`. This is caused by the code (in compiler/main/HscMain.hs): {{{ no_mod = panic "hscCmmFile: no_mod" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11784> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11221: Remove -fwarn-context-quantification
by GHC 17 Dec '16

17 Dec '16

#11221: Remove -fwarn-context-quantification -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This option was deprecated and does nothing as of GHC 8.0. Remove `Opt_WarnContextQuantification` and its uses from `DynFlags`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12986: Ignore case when parsing language pragmas
by GHC 16 Dec '16

16 Dec '16

#12986: Ignore case when parsing language pragmas -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It's annoying to have to remember exactly how a language extension is supposed to be capitalized. It seems highly unlikely that we will ever have two different language extensions that differ only by case. Therefore, I think GHC should ignore case when matching `{-# LANGUAGE #-}` pragmas. Thus, we should accept not only `UndecidableSuperClasses` but also `UndecidableSuperclasses`, etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12986> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12899: ghc panics at random places with -jX
by GHC 16 Dec '16

16 Dec '16

#12899: ghc panics at random places with -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Affected versions: pretty much all the things from early ghc8 until most recent. Symptoms: Out of 106 clean builds 36 failed with random ghc panic. By random I mean no two are alike. There are 525 files in a project and compilation goes in parallel with -j8. Other than panic in 21 cases it generates type errors (types are perfectly fine and whatever is under "with actual type" is something that probably exists in the same file or at least in the project itself but totally unrelated to what type an expression actually is. And even in those cases where ghc fails at the same file it usually results in different panic messages. What was checked: Stale interface files: No, ghc is told to use a separate build directory build system removes it bad memory/random file system corruption: No, ghc 7.10 builds the same codebase just fine and it also fails on other machines strange packages in user package database: No, ghc is told to ignore those ghc was reinstalled several times with system package db wiped. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12899> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #5654: Profiling semantics bug
by GHC 16 Dec '16

16 Dec '16

#5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: simonmar => * status: closed => new * resolution: fixed => Comment: I uncovered a bug in the patch, triggered by using GHCi with profiling. Fix incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0