- ghc-tickets - Haskell.org

[GHC] #16061: Missing FreeBSD build for 8.6.2
by GHC 17 Dec '18

17 Dec '18

#16061: Missing FreeBSD build for 8.6.2 -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.2 Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: Documentation (amd64) | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://www.haskell.org/ghc/download_ghc_8_6_2.html#freebsd11_x86_64 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16061> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16060: Missing AArch64 builds for latest GHC 8.6.3
by GHC 17 Dec '18

17 Dec '18

#16060: Missing AArch64 builds for latest GHC 8.6.3 -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.3 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: Documentation | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here there is a link to AArch64, but there is no such a section: https://www.haskell.org/ghc/download_ghc_8_6_3.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16060> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15890: Provide a way for hadrian users to always pass some options to hadrian itself
by GHC 17 Dec '18

17 Dec '18

#15890: Provide a way for hadrian users to always pass some options to hadrian itself -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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: -------------------------------------+------------------------------------- And more generally, is there any chance that we could make something like our builder `Args`/predicate logic work for specifying arguments to hadrian itself? Regardless of the answer to that last question, it seems only natural to have a simple/trivial solution for the case where we are always passing the same options to hadrian, over and over again, while working on GHC. "Yes, hadrian, I still want to build with the `perf` flavour, still with `integer-simple`, and you should still put all the build artifacts under `./ghc-prof-build/` while using all of my 4 cores", is something that I often told hadrian myself, while investigating a particular problem a few weeks ago, for example. Ryan in particular has expressed interested in having a slightly cleaner solution than writing a tiny wrapper script that just does `hadrian/build.sh --flavour=perf -oghc-prof-build $@` or something along those lines. Especially given that our `Args` infrastructure seems perfect to specify that kind of thing. It does seem a little bit circular though, of course. An alternative would be look at a build.mk-ish file, without support for any Make construct, just the good old key=value syntax + comments, and reconstruct a `Flavour` and everything else out of it. This way, instead of "implicitly" passing the same arguments on the CLI, we would "implicitly" look them up from some file, without having to create a wrapper script. (This build.mk-ish file is something I discussed with hvr some time ago, which he would like so as to programmatically specify how he wants his GHCs. He can't reasonably programmatically edit the settings file.) Thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15890> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #16055: libffi build logic is quite spread out
by GHC 16 Dec '18

16 Dec '18

#16055: libffi build logic is quite spread out -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- The rules for building libffi are in `Rules.Libffi` and at a first glance they just use the normal `Make` builder in order to build the project. However, if one looks carefully, you actually need to run `make install` so the normal `Make` builder has an argument appended in `Settings.Builders.Make`. The problem here is that the two modules are completely unrelated to each other. In order to discover this I had to wonder why the build was failing to copy a file and then by chance guess that it wasn't running `make install`. I think grepped for `"install"` and managed to find this additional rule. Is there a way to move this logic into one place? I considered two possibilities but it didn't seem to be "how things are done". 1. Modify the `Make` builder to take an additional argument which indicates whether to add the `install` flag. 2. Move the override of `Make` for libffi into `Rules.Libffi` and then import it into `Settings.Builders.Make`. This seems better but you still not entirely obvious what is going on. Do the hadrian experts have any opinion on this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16055> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16056: Hadrian failure: Values have changed since being depended upon
by GHC 16 Dec '18

16 Dec '18

#16056: Hadrian failure: Values have changed since being depended upon -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Keywords: | Operating System: Windows Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The Hadrian build on Windows appears to fail with: {{{ /--------------------------------------------------------------------------\ | Successfully built program 'haddock' (Stage2). | | Executable: _build/stage2/bin/haddock.exe | | Program synopsis: A documentation-generation tool for Haskell libraries. | \--------------------------------------------------------------------------/ shakeArgsWith 0.002s 0% Function shake 0.035s 0% Database read 0.003s 0% With database 0.001s 0% Running rules 2815.075s 99% ========================= Pool finished (9025 threads, 8 max) 0.001s 0% Lint checking 0.641s 0% Total 2815.758s 100% Lint checking error - 520 values have changed since being depended upon: Key: _build/stage1/gmp/objs/zero_p.o Old: (Just File {mod=0x88773CC6,size=0x2EA,digest=0xACFF03E6},"") New: File {mod=0x8C6CE092,size=0x2EA,digest=0xACFF03E6} Key: _build/stage1/gmp/objs/zero.o Old: (Just File {mod=0x88DC1816,size=0x2F8,digest=0x586B32DC},"") New: File {mod=0x8CA46DC3,size=0x2F8,digest=0x586B32DC} Key: _build/stage1/gmp/objs/xor_n.o Old: (Just File {mod=0x88D86EC7,size=0x1DF,digest=0xFBB5353},"") New: File {mod=0x8CA1D672,size=0x1DF,digest=0xFBB5353} ... }}} All paths listed are in `_build/stage1/gmp` and all changed only in their mtime. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15562: `-XStrict -XNoStrict` is not neutral
by GHC 14 Dec '18

14 Dec '18

#15562: `-XStrict -XNoStrict` is not neutral -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new 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 assumed we already had a ticket about this, but it appears we have not. I'm not saying this is a necessarily a bug in the implementation; but we should make sure this is properly documented in the user's guide, and ideally justify why it's done this way rather than the alternatives: As described in StrictPragma, > `Strict` implies `StrictData` Currently however the inverse case does not hold, i.e. `NoStrict` does *not* imply `NoStrictData` This has the surprising property (assuming these were left-most flags on the CLI) that - `-XStrict -XNoStrict` == `-XStrictData` - `-XStrictData -XNoStrict` == `-XStrictData` However, if `-XNoStrict` was to naively imply `-XNoStrictData`, we'd have the properties - `-XStrict -XNoStrict` == *id* - `-XStrictData -XNoStrict` == *id* This might be a bit less confusing; another variant would be - `-XStrict -XNoStrict` == *id* - `-XStrictData -XNoStrict` == `-XStrictData` Btw, I'm not sure what the following means: - `-XStrict -XNoStrictData` == ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15562> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16049: Add a warning flag that warns when a datatype could be a newtype
by GHC 14 Dec '18

14 Dec '18

#16049: Add a warning flag that warns when a datatype could be a newtype -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Keywords: flags | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- More often than not, `newtype` is desirable over `data` if a type has a single field. I propose a warning flag `-Wdata-could-be-newtype` that would warn users if a data type they've defined has a single field (and thus could be a `newtype`). It would need to be explicitly enabled (and of course enabled by `-Weverything`). An example (relevant Trac ticket: #15995): {{{#!hs -- Control.Concurrent.QSem: data QSem = QSem !(MVar (Int, [MVar ()], [MVar ()])) }}} There's a bang pattern on its single field, but this could just be supplied at every pattern-matching site of `QSem`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16049> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15882: :load in ghci should expose the entire namespace of a module
by GHC 14 Dec '18

14 Dec '18

#15882: :load in ghci should expose the entire namespace of a module -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: GHCi | Version: 8.6.2 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: -------------------------------------+------------------------------------- When using "import" in ghci, only exported names are available. When using :load, the use case is typically for "toying around" or testing a module. In that case, the export list restrictions are much less useful. There is currently no way to just expose the same namespace context of the code in a module in ghci, and having :load do that sounds like it would be very useful. The ordinary "import" namespace semantics are after all available too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15882> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15973: Int used to represent target integer literals
by GHC 14 Dec '18

14 Dec '18

#15973: Int used to represent target integer literals -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are numerous places within GHC where we use `Int` to represent a constant literal for the target. For instance, `CmmUtils` has the following: {{{#!hs -- XXX: should really be Integer, since Int doesn't necessarily cover -- the full range of target Ints. mkIntCLit :: DynFlags -> Int -> CmmLit mkIntCLit dflags i = CmmInt (toInteger i) (wordWidth dflags) }}} This could go very wrong when cross-compiling from a 32-bit machine to a 64-bit target. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15973> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15929: Explore whether adding XRay attributes to LLVM IR is worthwhile
by GHC 14 Dec '18

14 Dec '18

#15929: Explore whether adding XRay attributes to LLVM IR is worthwhile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- LLVM has support for XRay which is a tracing framework developed by Google. It might be possible to add the relevant function attributes to the IR we generate to get access to detailed traces which can be analysed using existing tooling. https://llvm.org/docs/XRay.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15929> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4