- ghc-tickets - Haskell.org

Re: [GHC] #6037: Compile-time crash with sources with non-representable unicode characters
by GHC 30 May '15

30 May '15

#6037: Compile-time crash with sources with non-representable unicode characters -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: T6037 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6037#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7695: Hang when locale-archive and gconv-modules are not there
by GHC 29 May '15

29 May '15

#7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977, #10298 | Blocking: | Differential Revisions: Phab:D898 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7695#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10399: ApiAnnotations tweaks
by GHC 29 May '15

29 May '15

#10399: ApiAnnotations tweaks -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- A collection of minor updates for the API Annotations. 1. The annotations for the RdrNames `(+)` and `(-)` are disconnected in the following {{{#!hs import GHC.TypeLits (KnownNat, type (+), type (-)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10399> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler
by GHC 29 May '15

29 May '15

#10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler -------------------------------------------+---------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+---------------------------- Ever since commit 5258566ee5c89aa757b0cf1433169346319c018f it seems that out-of-tree tests will not run on MinGW anymore. Note that I am using MinGW tools with a native Windows build of Python, which is the main cause of the problem. The apparent error is something along the lines of "cannot eval an empty string": {{{ Traceback (most recent call last): File "testsuite/driver/runtests.py", line 196, in <module> get_compiler_info() File "<string>", line 166, in get_compiler_info File "<string>", line 0 ^ SyntaxError: unexpected EOF while parsing }}} But this error is quite misleading. What really happened was that it tried to run GHC with the `--info` argument but failed silently and returned an empty string. If you apply D908, it becomes a lot more obvious: Python is failing to run `/c/programs/ghc/bin/ghc --info` because `/c/programs/ghc/bin/ghc` "does not exist" as Python does not understand MinGW-style paths. The funny thing is that it worked just fine before 525856, so you have to wonder why quoting the paths caused this. It turns out that MinGW does some magic behind the scenes, automagically converting MinGW-style paths into ordinary Python paths when a native Windows program is invoked. In particular, it means running this in MinGW shell {{{ python run-tests.py -e 'config.compiler=/c/programs/ghc/ghc' }}} will actually invoke Python with `config.compiler=C:/programs/ghc/ghc`. However, if it's explicitly quoted like this: {{{ python run-tests.py -e 'config.compiler="/c/programs/ghc/ghc"' }}} the magic doesn't work anymore. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10449> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #7695: Hang when locale-archive and gconv-modules are not there
by GHC 29 May '15

29 May '15

#7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977, #10298 | Blocking: | Differential Revisions: Phab:D898 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7695#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7695: Hang when locale-archive and gconv-modules are not there
by GHC 29 May '15

29 May '15

#7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977, #10298 | Blocking: | Differential Revisions: Phab:D898 -------------------------------------+------------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"e28462de700240288519a016d0fe44d4360d9ffd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e28462de700240288519a016d0fe44d4360d9ffd" base: fix #10298 & #7695 Summary: This applies a patch from Reid Barton and Sylvain Henry, which fix a disasterous infinite loop when iconv fails to load locale files, as specified in #10298. The fix is a bit of a hack but should be fine - for the actual reasoning behind it, see `Note [Disaster and iconv]` for more info. In addition to this fix, we also patch up the IO Encoding utilities to recognize several variations of the 'ASCII' encoding (including its aliases) directly so that GHC can do conversions without iconv. This allows a static binary to sit in an initramfs. Authored-by: Reid Barton <rwbarton(a)gmail.com> Authored-by: Sylvain Henry <hsyl20(a)gmail.com> Signed-off-by: Austin Seipp <austin(a)well-typed.com> Test Plan: Eyeballed it. Reviewers: rwbarton, hvr Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D898 GHC Trac Issues: #10298, #7695 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7695#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10419: Refactor LoadIface to distinguish getting a ModIface versus loading into EPT
by GHC 29 May '15

29 May '15

#10419: Refactor LoadIface to distinguish getting a ModIface versus loading into EPT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment, making a call to `loadSysInterface` (or the related interfaces) has two effects: 1. You get a `ModIface` 2. The declarations/instances/etc of the interface are type-checked and loaded into the EPT In fact, users of these functions rarely want both of these; they either only want the `ModIface`, or only want to load up the declarations. Here is a survey I did, where `I` indicates a `ModIface` was wanted, `D` indicates we wanted to load the declarations, and `ID` means both were wanted; {{{ RnSplice loadInterfaceForName: D rnBracket: deprecation checking of identifiers in brackets () RnEnv loadInterfaceForName I warnIfDeprecated: deprecation checking of GlobalRdrElt (mi_warn_fun) I lookupFixityRn: fixity lookup (mi_fix_fun) loadSrcInterface_maybe ID lookupQualifiedNameGHCi: implicit import RnNames loadSrcInterface ID rnImportDecl: source import! $$$$$ I printMinimalImports: minimal import calculation (mi_exports) DsMonad loadInterface I loadModule: load and return exported entities (like a source import but for Module) special case for Data.Array.Parallel DynamicLoading loadPluginInterface D forceLoadModuleInterfaces: what. Linker loadInterface I getLinkDeps: poke the dependencies (mi_boot, mi_deps) loadUserInterface I random ass thing to check if it's a sigof XXX (mi_sig_of) MkIface loadInterface I? needInterface: utility checkModUsage: given the usage information from the old hi, determine if recompilation is required (hashes only) FamInst loadSysInterface D getFamInsts: load instance into EPS and return it TcDeriv loadInterfaceForName I getDataConFixityFun: looks at mi_fix_fn TcRnDriver loadSysInterface I tcRnSignature: signature renaming hack D loadUnqualIfaces: for accurate available instance reporting loadModuleInterfaces D tcRnImports: load orphans loadModuleInterface getModuleInterface: load a 'Module' (GHCi) D hscCheckSafe' (HscMain, mi_trust, mi_trust_pkg, mi_deps) ID getPackageModuleInfo (contains interface) loadSrcInterface D runTcInteractive: mi_deps/dep_orphs, pull in orphans from interactive context ic_imports TcSplice loadInterfaceForModule I reifyModule: mi_usages only }}} It's well worth noting that for most `Name`s, it is NOT NECESSARY, since when we pull on it with `loadDecl`, the interface will get loaded in. Consequently, I think some of the cases where we're loading interfaces are unnecessary, e.g. the case in `rnBracket`. The primary cases are dealing with orphan imports; there are multiple sites which redo this logic, and it should all be centralized in one place. So here is the concrete proposal: * Add a new function for taking a `ModIface` and loading it into the EPT. * Change the rest of the existing `loadXXXInterface` functions to NOT load declarations. We'll actually typecheck the interface file when we pull on the `Name` in question during type checking. * Introduce a new function to `LoadIface` for loading orphans (i.e. what to do when a source level import occurs). Have `lookupQualifiedNameGHCi`, `rnImportDecl`, `tcRnImports` and `runTcInteractive` use this function. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10419> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7170: Foreign.Concurrent finalizer called twice in some cases
by GHC 29 May '15

29 May '15

#7170: Foreign.Concurrent finalizer called twice in some cases -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | ffi/should_run/7170 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by niteria): * owner: => niteria -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7170#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3699: Wildcards in type functions
by GHC 28 May '15

28 May '15

#3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: MartijnVanSteenbergen | Status: new Type: feature request | Milestone: 7.12.1 Priority: low | Version: 6.10.4 Component: Compiler (Type | Keywords: newcomer checker) | Architecture: Resolution: | Unknown/Multiple Operating System: Unknown/Multiple | Test Case: Type of failure: None/Unknown | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by dalaing): jstolarek - sorry I missed you comment - I've been stalled on this for a while as various other things have moved to the front of the queue, so I've unassigned myself for now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3699#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3699: Wildcards in type functions
by GHC 28 May '15

28 May '15

#3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: MartijnVanSteenbergen | Status: new Type: feature request | Milestone: 7.12.1 Priority: low | Version: 6.10.4 Component: Compiler (Type | Keywords: newcomer checker) | Architecture: Resolution: | Unknown/Multiple Operating System: Unknown/Multiple | Test Case: Type of failure: None/Unknown | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by dalaing): * owner: dalaing => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3699#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0