August 2018 - ghc-tickets

Re: [GHC] #314: #line pragmas not respected inside nested comments
by GHC 21 Aug '18

21 Aug '18

#314: #line pragmas not respected inside nested comments -------------------------------------+------------------------------------- Reporter: nobody | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 6.4 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: read032 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4934 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: None => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/314#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15279: CPP #includes may result in nonsensical SrcSpans
by GHC 21 Aug '18

21 Aug '18

#15279: CPP #includes may result in nonsensical SrcSpans -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code in `compiler/prelude/PrimOp.hs` {{{#!hs primOpInfo :: PrimOp -> PrimOpInfo #include "primop-primop-info.hs-incl" primOpInfo _ = error "primOpInfo: unknown primop" -- line 175 in PrimOp.hs }}} The MatchGroup for primOpInfo includes the `SrcSpan` `compiler/stage2/build/primop-primop-info.hs-incl:(1,1)-(175,49)` Here is line 175 in `primop-primop-info.hs-incl` {{{#!hs primOpInfo IndexSmallArrayOp = mkGenPrimOp (fsLit "indexSmallArray#") [alphaTyVar] [mkSmallArrayPrimTy alphaTy, intPrimTy] ((mkTupleTy Unboxed [alphaTy])) }}} The `SrcSpan`s end is somewhere in the middle of that line. I guess this occurs because `combineSrcSpans` doesn't take the file into account. I can think of multiple ways to fix this: 1. Make `combineSrcSpans` output an `UnhelpfulSrcSpan` if the files don't match(quick and easy) 2. Extend SrcSpan to properly support things spanning multiple files 3. Don't fix: People who use CPP get what they deserve. Option 3 is not unreasonable as options 1 and 2 will incur some performance penalty. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15527: TypeApplications error message doesn't parenthesize infix name
by GHC 21 Aug '18

21 Aug '18

#15527: TypeApplications error message doesn't parenthesize infix name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you compile the following program: {{{#!hs module Bug where f :: (Int -> Int) -> (Int -> Int) -> (Int -> Int) f = (.) @Int }}} You'll get this error: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:4:6: error: Pattern syntax in expression context: .@Int Did you mean to enable TypeApplications? | 4 | f = (.) @Int | ^^^^^^^^ }}} I was taken aback by this strange `.@` thing before I realized what was actually going on: the error message simply forgot to parenthesize `.`. This is `ppr_expr`'s fault, since it calls `ppr` on an `RdrName` instead of `pprPrefixOcc`. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15527> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15475: Plugin recompilation check still panics
by GHC 21 Aug '18

21 Aug '18

#15475: Plugin recompilation check still panics -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- I get a panic as follows when trying to use a plugin with the latest commit on the 8.6 branch. {{{ <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.6.1.20180803 for x86_64-unknown-linux): mkPluginUsage: file not found LiftPlugin /nix/store/q8rg4mca5zqv98arpxd7164pqa72hf1n-ncurses-6.1/lib /libHSlift-plugin-0.1.0.0-LpWZumtLigSEjndVxGCyUH-ghc8.6.1.20180803.so Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsUsage.hs:215:15 in ghc:DsUsage Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} My example is nixified and not very minimal but I can provide it tomorrow if that would help. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15051: -split-objs generates excessively many files on Windows
by GHC 21 Aug '18

21 Aug '18

#15051: -split-objs generates excessively many files on Windows --------------------------------------+--------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- A BuildFlavour = perf build generated ~18k .S files for ghc- prim:GHC.Types, which caused it to basically get stuck compiling all those assembly files. Removing -split-objs (via SplitObjs = NO) significantly sped up compilation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

Re: [GHC] #314: #line pragmas not respected inside nested comments
by GHC 21 Aug '18

21 Aug '18

#314: #line pragmas not respected inside nested comments -------------------------------------+------------------------------------- Reporter: nobody | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 6.4 (Parser) | Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: read032 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4934 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"02518f9d99c2d038384263f9e039efcb09bc96ff/ghc" 02518f9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="02518f9d99c2d038384263f9e039efcb09bc96ff" Fix #line pragmas in nested comments When parsing a nested comment or nested doc comment in the lexer, if we see a line starting with '#' we attempt to parse a #line pragma. This fixes how ghc handles output of the C preproccesor (-cpp flag) when the original source has C comments or pragmas inside haskell comments. Updates haddock submodule. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #314 Differential Revision: https://phabricator.haskell.org/D4934 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/314#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections
by GHC 21 Aug '18

21 Aug '18

#7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections
by GHC 21 Aug '18

21 Aug '18

#7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I've been thinking about the `StableName#` representation some, and I really don't like the redundancy between stable name objects and stable name table entries. I can think of two approaches to fixing this: get rid of the stable name table or get rid of stable name objects. === Get rid of the stable name table This is my preferred approach, if it's workable, because it seems almost absurdly simple. Suppose we have one counter to generate IDs (the results of `hashStableName#`) and one hash table per generation mapping heap pointers to stable name objects. A stable name object would look like {{{ StableNameObject: Header ID -- for hashStableName# Underlying object, treated as a weak reference }}} `makeStableName#` would check the hash table for the appropriate generation to see if there's already a stable name object (SNO). If not, it gets a fresh `ID` and builds the SNO. Garbage collecting the hash tables, roughly speaking: Perform a normal collection, leaving the underlying object pointers pointing to from-space. Traverse all the hash table entries in the table for the generation currently being collected. For each SNO pointer in the table, check the SNO for liveness. If it's alive, get the to-space address of its underlying object, edit the SNO accordingly, and insert it into the hash table for the next generation. If the underlying object is dead, null out that field. Is this too simple, or just simple enough? I don't really understand the idea of per-capability lists--how do you know which one a particular target should be inserted into? But presumably if we did that, we'd partition the ID space by high bit to give each capability its own counter. === Get rid of stable name objects 1. Change the stable name table to a representation that can grow without moving. Guess: an array of arrays, where each array is either empty or twice the size of the one to its left. 2. Add a heap object-style header to each stable name table entry. So each entry will look like {{{ SNTableEntry: Header Index (for hashStableName#) Underlying object }}} Now a `StableName#` becomes a pointer directly into the stable name table. The garbage collector can recognize the closure type and handle it specially. Note that stable name table entries pointing to old objects will always be put in the old-generation stable name table. I don't know enough about the garbage collector to say exactly how that should work. The free list can probably just run through the headers. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15516: ghci: dynamic linking fails on osx
by GHC 21 Aug '18

21 Aug '18

#15516: ghci: dynamic linking fails on osx -------------------------------------+------------------------------------- Reporter: kfiz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib, 5): Symbol not found: _DataziCsvUtils_rowBy_closure Referenced from: /var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib Expected in: flat namespace in /var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15516> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15533: Access the number of bits in the target machine's Int type at compile time
by GHC 21 Aug '18

21 Aug '18

#15533: Access the number of bits in the target machine's Int type at compile time -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- I'm not sure of the current progress on GHC cross-compiling user programs, but I think a small addition might need to be made somewhere in the modules included with `ghc`. If I'm reading the documentation correctly, [https://hackage.haskell.org/package/base-4.11.1.0/docs/GHC- ByteOrder.html#v:targetByteOrder GHC.ByteOrder.targetByteOrder] will let us know the endianness of the target machine even if the compiling machine has a different endianness. I assume that this allows Template Haskell to, at compile time, generate proper code specifically for the target based on that fact. I can't find any way of finding out the bit size of an `Int` (specifically the exact value of `(finiteBitSize (undefined :: Int)`) on the target platform, and it would be nice if that were added in a way that's convenient to access in general and by Template Haskell at compile time, similar to `GHC.ByteOrder.targetByteOrder`. ---- I've looked into it a little bit and found that [https://github.com/ghc/ghc/blob/master/compiler/utils/Platform.hs#L33 the GHC API will tell you the word size of the target in bytes with platformWordSize] (also on [https://hackage.haskell.org/package/ghc-8.4.3/docs/Platform.html#v:platform… Hackage]): {{{#!hs lineno=25 id=b marks=31-33 -- | Contains enough information for the native code generator to emit -- code for this platform. data Platform = Platform { platformArch :: Arch, platformOS :: OS, -- Word size in bytes (i.e. normally 4 or 8, -- for 32bit and 64bit platforms respectively) platformWordSize :: {-# UNPACK #-} !Int, platformUnregisterised :: Bool, platformHasGnuNonexecStack :: Bool, platformHasIdentDirective :: Bool, platformHasSubsectionsViaSymbols :: Bool, platformIsCrossCompiling :: Bool } deriving (Read, Show, Eq) }}} The problem is that this doesn't account for possible tag bits reducing the size ''in bits'' of `Int` to something less than the given `platformWordSize`. Recently, [https://ghc.haskell.org/trac/ghc/ticket/15486 support for WORD_SIZE_IN_BITS < 32 was dropped], so tag bits aren't a problem on 32-bit platforms anymore, but they might be on 64-bit platforms. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15533> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2