summaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
...
* Refactor iface file generation:Ömer Sinan Ağacan2019-09-3017-386/+812
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit refactors interface file generation to allow information from the later passed (NCG, STG) to be stored in interface files. We achieve this by splitting interface file generation into two parts: * Partial interfaces, built based on the result of the core pipeline * A fully instantiated interface, which also contains the final fingerprints and can optionally contain information produced by the backend. This change is required by !1304 and !1530. -dynamic-too handling is refactored too: previously when generating code we'd branch on -dynamic-too *before* code generation, but now we do it after. (Original code written by @AndreasK in !1530) Performance ~~~~~~~~~~~ Before this patch interface files where created and immediately flushed to disk which made space leaks impossible. With this change we instead use NFData to force all iface related data structures to avoid space leaks. In the process of refactoring it was discovered that the code in the ToIface Module allocated a lot of thunks which were immediately forced when writing/forcing the interface file. So we made this module more strict to avoid creating many of those thunks. Bottom line is that allocations go down by about ~0.1% compared to master. Residency is not meaningfully different after this patch. Runtime was not benchmarked. Co-Authored-By: Andreas Klebinger <klebinger.andreas@gmx.at> Co-Authored-By: Ömer Sinan Ağacan <omer@well-typed.com>
* `exprOkForSpeculation` for Note [IO hack in the demand analyser]Sebastian Graf2019-09-281-11/+11
| | | | | | | | | | | | | | | | | | In #14998 I realised that the notion of speculative execution *exactly matches* eager evaluation of expressions in a case alternative where the scrutinee is an IO action. Normally we have to `deferIO` any result from that single case alternative to prevent this speculative execution, so we had a special case in place in the demand analyser that would check if the scrutinee was a prim-op, in which case we assumed that it would be ok to do the eager evaluation. Now we just check if the scrutinee is `exprOkForSpeculation`, corresponding to the notion that we want to push evaluation of the scrutinee *after* eagerly evaluating stuff from the case alternative. This fixes #14988, because it resolves the last open Item 4 there.
* PmCheck: No ConLike instantiation in pmcheckSebastian Graf2019-09-282-302/+211
| | | | | | | | | | | | | | | | | | | | | | | `pmcheck` used to call `refineToAltCon` which would refine the knowledge we had about a variable by equating it to a `ConLike` application. Since we weren't particularly smart about this in the Check module, we simply freshened the constructors existential and term binders utimately through a call to `mkOneConFull`. But that instantiation is unnecessary for when we match against a concrete pattern! The pattern will already have fresh binders and field types. So we don't call `refineToAltCon` from `Check` anymore. Subsequently, we can simplify a couple of call sites and functions in `PmOracle`. Also implementing `computeCovered` becomes viable and we don't have to live with the hack that was `addVarPatVecCt` anymore. A side-effect of not indirectly calling `mkOneConFull` anymore is that we don't generate the proper strict argument field constraints anymore. Instead we now desugar ConPatOuts as if they had bangs on their strict fields. This implies that `PmVar` now carries a `HsImplBang` that we need to respect by a (somewhat ephemeral) non-void check. We fix #17234 in doing so.
* PmCheck: Look at precendence to give type signatures to some wildcardsSebastian Graf2019-09-271-16/+35
| | | | | | | | | Basically do what we currently only do for -XEmptyCase in other cases where adding the type signature won't distract from pattern matches in other positions. We use the precedence to guide us, equating "need to parenthesise" with "too much noise".
* Just get RTS libs from its package confJohn Ericson2019-09-271-19/+0
| | | | | `rts.conf` already contains this exact information in its `extra-libraries` stanza.
* Allow users to disable Unicode with an env varRon Mordechai2019-09-271-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unicode renders funny on my terminal and I like to avoid it where possible. Most applications which print out non-ascii characters allow users to disable such prints with an environment variable (e.g. Homebrew). This diff disables Unicode usage when the environment variable `GHC_NO_UNICODE` is set. To test, set the env var and compile a bad program. Note that GHC does not print Unicode bullets but instead prints out asterisks: ``` $ GHC_NO_UNICODE= _build/stage1/bin/ghc ../Temp.hs [1 of 1] Compiling Temp ( ../Temp.hs, ../Temp.o ) ../Temp.hs:4:23: error: * Couldn't match type `Bool' with `a -> Bool' Expected type: Bool -> a -> Bool Actual type: Bool -> Bool * In the first argument of `foldl', namely `(&& (flip $ elem u))' In the expression: foldl (&& (flip $ elem u)) True v In an equation for `isPermut': isPermut u v = foldl (&& (flip $ elem u)) True v * Relevant bindings include v :: [a] (bound at ../Temp.hs:4:12) u :: [a] (bound at ../Temp.hs:4:10) isPermut :: [a] -> [a] -> Bool (bound at ../Temp.hs:4:1) | 4 | isPermut u v = foldl (&& (flip $ elem u)) True v | ^^^^^^^^^^^^^^^^^^ ``` (Broken code taken from Stack Overflow)
* Make -fbyte-code prevent unboxed tuples/sums from implying object code (#16876)Ryan Scott2019-09-262-6/+13
| | | | | | | | | | | | | | | | | | | | This resolves #16876 by making the explicit use of `-fbyte-code` prevent code that enables `UnboxedTuples` or `UnboxedSums` from automatically compiling to object code. This allows for a nice middle ground where most code that enables `UnboxedTuples`/-`Sums` will still benefit from automatically enabling `-fobject-code`, but allows power users who wish to avoid this behavior in certain corner cases (such as `lens`, whose use case is documented in #16876) to do so. Along the way, I did a little cleanup of the relevant code and documentation: * `enableCodeGenForUnboxedTuples` was only checking for the presence of `UnboxedTuples`, but `UnboxedSums` has the same complications. I fixed this and renamed the function to `enableCodeGenForUnboxedTuplesOrSums`. * I amended the users' guide with a discussion of these issues.
* Standalone kind signatures (#16794)wip/top-level-kind-signaturesVladislav Zavialov2019-09-2529-379/+1359
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implements GHC Proposal #54: .../ghc-proposals/blob/master/proposals/0054-kind-signatures.rst With this patch, a type constructor can now be given an explicit standalone kind signature: {-# LANGUAGE StandaloneKindSignatures #-} type Functor :: (Type -> Type) -> Constraint class Functor f where fmap :: (a -> b) -> f a -> f b This is a replacement for CUSKs (complete user-specified kind signatures), which are now scheduled for deprecation. User-facing changes ------------------- * A new extension flag has been added, -XStandaloneKindSignatures, which implies -XNoCUSKs. * There is a new syntactic construct, a standalone kind signature: type <name> :: <kind> Declarations of data types, classes, data families, type families, and type synonyms may be accompanied by a standalone kind signature. * A standalone kind signature enables polymorphic recursion in types, just like a function type signature enables polymorphic recursion in terms. This obviates the need for CUSKs. * TemplateHaskell AST has been extended with 'KiSigD' to represent standalone kind signatures. * GHCi :info command now prints the kind signature of type constructors: ghci> :info Functor type Functor :: (Type -> Type) -> Constraint ... Limitations ----------- * 'forall'-bound type variables of a standalone kind signature do not scope over the declaration body, even if the -XScopedTypeVariables is enabled. See #16635 and #16734. * Wildcards are not allowed in standalone kind signatures, as partial signatures do not allow for polymorphic recursion. * Associated types may not be given an explicit standalone kind signature. Instead, they are assumed to have a CUSK if the parent class has a standalone kind signature and regardless of the -XCUSKs flag. * Standalone kind signatures do not support multiple names at the moment: type T1, T2 :: Type -> Type -- rejected type T1 = Maybe type T2 = Either String See #16754. * Creative use of equality constraints in standalone kind signatures may lead to GHC panics: type C :: forall (a :: Type) -> a ~ Int => Constraint class C a where f :: C a => a -> Int See #16758. Implementation notes -------------------- * The heart of this patch is the 'kcDeclHeader' function, which is used to kind-check a declaration header against its standalone kind signature. It does so in two rounds: 1. check user-written binders 2. instantiate invisible binders a la 'checkExpectedKind' * 'kcTyClGroup' now partitions declarations into declarations with a standalone kind signature or a CUSK (kinded_decls) and declarations without either (kindless_decls): * 'kinded_decls' are kind-checked with 'checkInitialKinds' * 'kindless_decls' are kind-checked with 'getInitialKinds' * DerivInfo has been extended with a new field: di_scoped_tvs :: ![(Name,TyVar)] These variables must be added to the context in case the deriving clause references tcTyConScopedTyVars. See #16731.
* base: Move Ix typeclass to GHC.IxBen Gamari2019-09-251-8/+8
| | | | | The `Ix` class seems rather orthogonal to its original home in `GHC.Arr`.
* PmCheck: Only ever check constantly many models against a single patternSebastian Graf2019-09-2510-261/+201
| | | | | | | | | | | | | | | | | | | | | | | | | Introduces a new flag `-fmax-pmcheck-deltas` to achieve that. Deprecates the old `-fmax-pmcheck-iter` mechanism in favor of this new flag. From the user's guide: Pattern match checking can be exponential in some cases. This limit makes sure we scale polynomially in the number of patterns, by forgetting refined information gained from a partially successful match. For example, when matching `x` against `Just 4`, we split each incoming matching model into two sub-models: One where `x` is not `Nothing` and one where `x` is `Just y` but `y` is not `4`. When the number of incoming models exceeds the limit, we continue checking the next clause with the original, unrefined model. This also retires the incredibly hard to understand "maximum number of refinements" mechanism, because the current mechanism is more general and should catch the same exponential cases like PrelRules at the same time. ------------------------- Metric Decrease: T11822 -------------------------
* Add -Wderiving-defaults (#15839)Kari Pahula2019-09-252-1/+5
| | | | | | Enabling both DeriveAnyClass and GeneralizedNewtypeDeriving can cause a warning when no explicit deriving strategy is in use. This change adds an enable/suppress flag for it.
* Fix some duplication in the parserSebastian Graf2019-09-241-20/+4
| | | | | | | | | | | | | | | | | | | | | | D3673 experienced reduce/reduce conflicts when trying to use opt_instance for associated data families. That was probably because the author tried to use it for Haskell98-syntax without also applying it to GADT-syntax, which actually leads to a reduce/reduce conflict. Consider the following state: ``` data . T = T data . T where T :: T ``` The parser must decide at this point whether or not to reduce an empty `opt_instance`. But doing so would also commit to either Haskell98 or GADT syntax! Good thing we also accept an optional "instance" for GADT syntax, so the `opt_instance` is there in both productions and there's no reduce/reduce conflict anymore. Also no need to inline `opt_instance`, how it used to be.
* Some leftovers from !1732. Comments only [skip ci]Sebastian Graf2019-09-242-3/+4
|
* Add -fkeep-going to make compiler continue despite errors (#15424)Kari Pahula2019-09-232-3/+38
| | | | | Add a new optional failure handling for upsweep which continues the compilation on other modules if any of them has errors.
* Get rid of PmFakewip/pmcheck-nofakeSebastian Graf2019-09-211-229/+48
| | | | | | | | | | | | | | | | | | | The pattern match oracle can now cope with the abundance of information that ViewPatterns, NPlusKPats, overloaded lists, etc. provide. No need to have PmFake anymore! Also got rid of a spurious call to `allCompleteMatches`, which we used to call *for every constructor* match. Naturally this blows up quadratically for programs like `ManyAlternatives`. ------------------------- Metric Decrease: ManyAlternatives Metric Increase: T11822 -------------------------
* PredType for type constraints in the pattern match checker instead of EvVarSebastian Graf2019-09-215-99/+124
| | | | | | | | | | | | | | | | Using EvVars for capturing type constraints implied side-effects in DsM when we just wanted to *construct* type constraints. But giving names to type constraints is only necessary when passing Givens to the type checker, of which the majority of the pattern match checker should be unaware. Thus, we simply generate `newtype TyCt = TyCt PredType`, which are nicely stateless. But at the same time this means we have to allocate EvVars when we want to query the type oracle! So we keep the type oracle state as `newtype TyState = TySt (Bag EvVar)`, which nicely makes a distinction between new, unchecked `TyCt`s and the inert set in `TyState`.
* Fix bogus type of case expressionwip/T17056Simon Peyton Jones2019-09-2010-176/+348
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Issue #17056 revealed that we were sometimes building a case expression whose type field (in the Case constructor) was bogus. Consider a phantom type synonym type S a = Int and we want to form the case expression case x of K (a::*) -> (e :: S a) We must not make the type field of the Case constructor be (S a) because 'a' isn't in scope. We must instead expand the synonym. Changes in this patch: * Expand synonyms in the new function CoreUtils.mkSingleAltCase. * Use mkSingleAltCase in MkCore.wrapFloat, which was the proximate source of the bug (when called by exprIsConApp_maybe) * Use mkSingleAltCase elsewhere * Documentation CoreSyn new invariant (6) in Note [Case expression invariants] CoreSyn Note [Why does Case have a 'Type' field?] CoreUtils Note [Care with the type of a case expression] * I improved Core Lint's error reporting, which was pretty confusing in this case, because it didn't mention that the offending type was the return type of a case expression. * A little bit of cosmetic refactoring in CoreUtils
* Fix PmOracle.addVarCoreCt in-scope setSimon Peyton Jones2019-09-202-4/+10
| | | | | | | | PmOracle.addVarCoreCt was giving a bogus (empty) in-scope set to exprIsConApp_maybe, which resulted in a substitution-invariant failure (see MR !1647 discussion). This patch fixes it, by taking the free vars of the expression.
* Remove pointless partiality in `Parser.ajs`John Ericson2019-09-201-15/+16
|
* Module hierarchy: Hs (#13009)Sylvain Henry2019-09-20114-327/+331
| | | | | | | Add GHC.Hs module hierarchy replacing hsSyn. Metric Increase: haddock.compiler
* ErrUtils: split withTiming into withTiming and withTimingSilentAlp Mestanogullari2019-09-197-36/+89
| | | | | | | | | | | | | | | | | | | 'withTiming' becomes a function that, when passed '-vN' (N >= 2) or '-ddump-timings', will print timing (and possibly allocations) related information. When additionally built with '-eventlog' and executed with '+RTS -l', 'withTiming' will also emit both 'traceMarker' and 'traceEvent' events to the eventlog. 'withTimingSilent' on the other hand will never print any timing information, under any circumstance, and will only emit 'traceEvent' events to the eventlog. As pointed out in !1672, 'traceMarker' is better suited for things that we might want to visualize in tools like eventlog2html, while 'traceEvent' is better suited for internal events that occur a lot more often and that we don't necessarily want to visualize. This addresses #17138 by using 'withTimingSilent' for all the codegen bits that are expressed as a bunch of small computations over streams of codegen ASTs.
* Extract PmTypes module from PmExpr and PmOracleSebastian Graf2019-09-198-270/+264
| | | | | | | | | | | Apparently ghc-lib-parser's API blew up because the newly induced cyclic dependency between TcRnTypes and PmOracle pulled in the other half of GHC into the relevant strongly-connected component. This patch arranges it so that PmTypes exposes mostly data type definitions and type class instances to be used within PmOracle, without importing the any of the possibly offending modules DsMonad, TcSimplify and FamInst.
* CoreUtils: Use mightBeUnliftedType in exprIsTopLevelBindableBen Gamari2019-09-192-2/+6
| | | | Also add reference from isUnliftedType to mightBeUnliftedType.
* Use level numbers for generalisationRichard Eisenberg2019-09-1910-241/+196
| | | | | | | | This fixes #15809, and is covered in Note [Use level numbers for quantification] in TcMType. This patch removes the "global tyvars" from the environment, a nice little win.
* Refactor kindGeneralize and friendsRichard Eisenberg2019-09-198-219/+272
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit should have no change in behavior.(*) The observation was that Note [Recipe for checking a signature] says that every metavariable in a type-checked type must either (A) be generalized (B) be promoted (C) be zapped. Yet the code paths for doing these were all somewhat separate. This led to some steps being skipped. This commit shores this all up. The key innovation is TcHsType.kindGeneralizeSome, with appropriate commentary. This commit also sets the stage for #15809, by turning the WARNing about bad level-numbers in generalisation into an ASSERTion. The actual fix for #15809 will be in a separate commit. Other changes: * zonkPromoteType is now replaced by kindGeneralizeNone. This might have a small performance degradation, because zonkPromoteType zonked and promoted all at once. The new code path promotes first, and then zonks. * A call to kindGeneralizeNone was added in tcHsPartialSigType. I think this was a lurking bug, because it did not follow Note [Recipe for checking a signature]. I did not try to come up with an example showing the bug. This is the (*) above. Because of this change, there is an error message regression in partial-sigs/should_fail/T14040a. This problem isn't really a direct result of this refactoring, but is a symptom of something deeper. See #16775, which addresses the deeper problem. * I added a short-cut to quantifyTyVars, in case there's nothing to quantify. * There was a horribly-outdated Note that wasn't referred to. Gone now. * While poking around with T14040a, I discovered a small mistake in the Coercion.simplifyArgsWorker. Easy to fix, happily. * See new Note [Free vars in coercion hole] in TcMType. Previously, we were doing the wrong thing when looking at a coercion hole in the gather-candidates algorithm. Fixed now, with lengthy explanation. Metric Decrease: T14683
* Simplify: Lazy pattern matchBen Gamari2019-09-191-1/+5
|
* Add a missing update of sc_hole_ty (#16312)Simon Peyton Jones2019-09-191-1/+5
| | | | | | | | | | | In simplCast I totally failed to keep the sc_hole_ty field of ApplyToTy (see Note [The hole type in ApplyToTy]) up to date. When a cast goes by, of course the hole type changes. Amazingly this has not bitten us before, but #16312 finally triggered it. Fortunately the fix is simple. Fixes #16312.
* Improve error message for out-of-scope variables + VTASimon Peyton Jones2019-09-171-2/+46
| | | | | | | | | | As #13834 and #17150 report, we get a TERRIBLE error message when you have an out of scope variable applied in a visible type application: (outOfScope @Int True) This very simple patch improves matters. See TcExpr Note [VTA for out-of-scope functions]
* Comments onlySimon Peyton Jones2019-09-171-2/+2
|
* Fix #13571 by adding an extension flag checkRichard Eisenberg2019-09-171-0/+10
| | | | Test case: indexed-types/should_fail/T13571
* Encode shape information in `PmOracle`Sebastian Graf2019-09-1621-2503/+3008
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we had an elaborate mechanism for selecting the warnings to generate in the presence of different `COMPLETE` matching groups that, albeit finely-tuned, produced wrong results from an end user's perspective in some cases (#13363). The underlying issue is that at the point where the `ConVar` case has to commit to a particular `COMPLETE` group, there's not enough information to do so and the status quo was to just enumerate all possible complete sets nondeterministically. The `getResult` function would then pick the outcome according to metrics defined in accordance to the user's guide. But crucially, it lacked knowledge about the order in which affected clauses appear, leading to the surprising behavior in #13363. In !1010 we taught the term oracle to reason about literal values a variable can certainly not take on. This MR extends that idea to `ConLike`s and thereby fixes #13363: Instead of committing to a particular `COMPLETE` group in the `ConVar` case, we now split off the matching constructor incrementally and record the newly covered case as a refutable shape in the oracle. Whenever the set of refutable shapes covers any `COMPLETE` set, the oracle recognises vacuosity of the uncovered set. This patch goes a step further: Since at this point the information in value abstractions is merely a cut down representation of what the oracle knows, value abstractions degenerate to a single `Id`, the semantics of which is determined by the oracle state `Delta`. Value vectors become lists of `[Id]` given meaning to by a single `Delta`, value set abstractions (of which the uncovered set is an instance) correspond to a union of `Delta`s which instantiate the same `[Id]` (akin to models of formula). Fixes #11528 #13021, #13363, #13965, #14059, #14253, #14851, #15753, #17096, #17149 ------------------------- Metric Decrease: ManyAlternatives T11195 -------------------------
* Rename GHC.StgToCmm.Con -> GHC.StgToCmm.DataConBen Gamari2019-09-155-6/+6
| | | | | | | | | Incredibly, Windows disallows the manipulation of any file matching Con(\..*)?. The `GHC.StgToCmm.Con` was introduced in the renamings in 447864a9, breaking the Windows build. Work around this by renaming it to `GHC.StgToCmm.DataCon` Fixes #17187.
* Remove empty NCG.hJohn Ericson2019-09-1315-27/+0
|
* Compiler should always get fingerprinting impl from baseJohn Ericson2019-09-132-20/+1
| | | | | 07ee15915d5a0d6d1aeee137541eec6e9c153e65 started the transition, but the job was never finished.
* Address review comments [skip CI]Zubin Duggal2019-09-131-8/+26
|
* Explain how to update HieAst [skip ci]Zubin Duggal2019-09-131-0/+112
|
* Fix scoping of implicit parametersSimon Peyton Jones2019-09-131-3/+7
| | | | | | | | There was an outright bug in TcInteract.solveOneFromTheOther which meant that we did not always pick the innermost implicit parameter binding, causing #17104. The fix is easy, just a rearrangement of conditional tests
* Remove unused `#include`s from parser/cutils.cJohn Ericson2019-09-121-6/+0
| | | | | Looks like these have been unused since 7c665f9ce0980ee7c81a44c8f861686395637453.
* Do not throw away backpack instantiations for module lookup cacheJohn Ericson2019-09-121-1/+1
| | | | | | | | | | | | | | | Currently, there is only one home package so this probably doesn't matter. But if we support multiple home packages, they could differ only in arguments (same indef component being applied). It looks like it used to be this way before 4e8a0607140b23561248a41aeaf837224aa6315b, but that commit doesn't seem to comment on this change in the particular. (It's main purpose is creating the InstalledUnitId and recategorizing the UnitId expressions accordingly.) Trying this as a separate commit for testing purposes. I leave it to others to decide whether this is a good change on its own.
* Refactor bad coercion checking in a few placesÖmer Sinan Ağacan2019-09-114-34/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We do bad coercion checking in a few places in the compiler, but they all checked it differently: - CoreToStg.coreToStgArgs: Disallowed lifted-to-unlifted, disallowed changing prim reps even when the sizes are the same. - StgCmmExpr.cgCase: Checked primRepSlot equality. This disallowed Int to Int64 coercions on 64-bit systems (and Int to Int32 on 32-bit) even though those are fine. - CoreLint: Only place where we do this right. Full rules are explained in Note [Bad unsafe coercion]. This patch implements the check explained in Note [Bad unsafe coercion] in CoreLint and uses it in CoreToStg.coreToStgArgs and StgCmmExpr.cgCase. This fixes #16952 and unblocks !1381 (which fixes #16893). This is the most conservative and correct change I came up with that fixes #16952. One remaining problem with coercion checking is that it's currently done in seemingly random places. What's special about CoreToStg.coreToStgArgs and StgCmmExpr.cgCase? My guess is that adding assertions to those places caught bugs before so we left assertions in those places. I think we should remove these assertions and do coercion checking in CoreLint and StgLint only (#17041).
* SetLevels: Fix potential panic in lvlBindBen Gamari2019-09-112-4/+14
| | | | | | 3b31a94d introduced a use of isUnliftedType which can panic in the case of levity-polymorphic types. Fix this by introducing mightBeUnliftedType which returns whether the type is *guaranteed* to be lifted.
* Remove dead `ncgDebugIsOn` and `NCG_DEBUG`John Ericson2019-09-111-8/+1
| | | | Haven't been used since 16206a6603e87e15d61c57456267c5f7ba68050e.
* Remove COMPILING_GHCJohn Ericson2019-09-111-3/+0
| | | | | It is no longer used. I guess we are sharing fewer headers with the RTS than the comment claims. That's a relief!
* linker: Move -optl flags to end of linker invocation.Niklas Hambüchen2019-09-111-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, giving `-optl` linker flags to `ghc` on the command line placed them in the wrong place in the `ld` command line: They were given before all the Haskell libararies, when they should appear after. Background: Most linkers like `ld.bfd` and `ld.gold`, but not the newer LLVM `lld`, work in a way where the order of `-l` flags given matters; earlier `-lmylib1` flags are supposed to create "holes" for linker symbols that are to be filled with later `lmylib2` flags that "fill the holes" for these symbols. As discovered in https://github.com/haskell/cabal/pull/5451#issuecomment-518001240, the `-optl` flags appeared before e.g. the -lHStext-1.2.3.1 -lHSbinary-0.8.6.0 -lHScontainers-0.6.0.1 flags that GHC added at the very end. Haskell libraries typically depend on C libraries, so `-lHS*` flags will create holes for the C libraries to fill in, but that only works when those libraries' `-l` flags are given **after** the `-lHS*` flags; until now they were given before, which was wrong. This meant that Cabal's `--ld-options` flag and `ld-options` `.cabal` file field were pretty ineffective, unless you used the `--ld-option=--start-group` hack as (https://github.com/haskell/cabal/pull/5451#issuecomment-406761676) that convinces the classical linkers to not be dependent on the order of linker flags given. This commit fixes the problem by simply flipping the order, putting `-optl` flags at the end, after Haskell libraries. The code change is effectively only `args1 ++ args` -> `args ++ args1` but the commit also renames the variables for improved clarity. Simple way to test it: ghc --make Main.hs -fforce-recomp -v -optl-s on a `Main.hs` like: import qualified Data.Set as Set main = print $ Set.fromList "hello"
* Module hierarchy: StgToCmm (#13009)Sylvain Henry2019-09-1065-372/+271
| | | | | | Add StgToCmm module hierarchy. Platform modules that are used in several other places (NCG, LLVM codegen, Cmm transformations) are put into GHC.Platform.
* Replace queryCygwinTerminal with Win32's isMinTTYHandleRyan Scott2019-09-091-61/+11
| | | | | | | | | | | | `SysTools.Terminal.queryCygwinTerminal` now exists in the `Win32` library under the name `isMinTTYHandle` since `Win32-2.5.0.0`. (GHC 8.4.4 ships with `Win32-2.6.1.0`, so this is well within GHC's support window.) We can therefore get replace `queryCygwinTerminal` with `isMinTTYHandle` and delete quite a bit of code from `SysTools.Terminal` in the process. Along the way I needed to replace some uses of `#if defined x` with `#if defined(x)` to please the CI linters.
* Update FastString docstringsDaniel Gröber2019-09-091-8/+10
| | | | | | 1) FastStrings are always UTF-8 encoded now. 2) Clarify what is meant by "hashed" 3) Add mention of lazy z-enc
* Use lazyness for FastString's z-encoding memoizationDaniel Gröber2019-09-091-41/+37
| | | | | | | | | | | | | | | | | | | Having an IORef in FastString to memoize the z-encoded version is unecessary because there is this amazing thing Haskell can do natively, it's called "lazyness" :) We simply remove the UNPACK and strictness annotations from the constructor field corresponding to the z-encoding, making it lazy, and store the (pure) z-encoded string there. The only complication here is 'hasZEncoding' which allows cheking if a z-encoding was computed for a given string. Since this is only used for compiler performance statistics though it's not actually necessary to have the current per-string granularity. Instead I add a global IORef counter to the FastStringTable and use unsafePerformIO to increment the counter whenever a lazy z-encoding is forced.
* Fix GHC version guard for Int32Rep/Word32RepMoritz Kiefer2019-09-081-0/+4
| | | | | Those constructors have been added after GHC 8.8. The version guards in `binary` are correct, see https://github.com/kolmodin/binary/pull/167/files.
* Add a new flag -dno-typeable-binds for debuggingÖmer Sinan Ağacan2019-09-082-4/+9
| | | | | See the user manual entry -- this helps when debugging as generated Core gets smaller without these bindings.
View Lorry Controller Status