summaryrefslogtreecommitdiff
path: root/compiler/main
Commit message (Collapse)AuthorAgeFilesLines
...
* Do not imply NoStarIsType by TypeOperators/TypeInTypeVladislav Zavialov2018-07-161-9/+6
| | | | | | | | | | | | | | | | | | | | | | Implementation of the "Embrace TypeInType" proposal was done according to the spec, which specified that TypeOperators must imply NoStarIsType. This implication was meant to prevent breakage and to be removed in 2 releases. However, compiling head.hackage has shown that this implication only magnified the breakage, so there is no reason to have it in the first place. To remain in compliance with the three-release policy, we add a workaround to define the (*) type operator even when -XStarIsType is on. Test Plan: ./validate Reviewers: bgamari, RyanGlScott, goldfire, phadej, hvr Reviewed By: bgamari, RyanGlScott Subscribers: harpocrates, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4865
* driver: skip -Bsymbolic on unregisterised targets (Trac #15338)Sergei Trofimovich2018-07-161-2/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trac #15338 is yet another example where -Bsymbolic breaks semantics of a C program: global variable duplication happens and unsafePerformIO creates two stdout copies. When -Bsymbolic is not used both C compiler and linker agree on how global variables are handled. In case of sh4 it consists on a few assertions: 1. global variable is exported from shared library 2. code is referred to this variable via GOT-like mechanism to allow interposition 3. global variable is present .bss section on an executable (as an R_*_COPY relocation: symbol contents is copied at executable startup time) 4. and symbol in executable interposes symbol in shared library. This way both code in shared library and code in executable refer to a copy of global variable in .bss section of an executable. Unfortunately -Bsymbolic option breaks assumption [2.] and generates direct references to the symbol. This causes mismatch between values seen from executable and values seen from shared library code. This change disables '-Bsymbolic' for unregisterised targets. Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Test Plan: test 'ghc-pkg --version | cat' to emit data Reviewers: simonmar, bgamari, jrtc27 Reviewed By: jrtc27 Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15338 Differential Revision: https://phabricator.haskell.org/D4959
* Fix space leaksSimon Marlow2018-07-162-5/+5
| | | | | | | | | | | | | | | | | | | | | Summary: All these were detected by -fghci-leak-check when GHC was compiled *without* optimisation (e.g. using the "quick" build flavour). Unfortunately I don't know of a good way to keep this working. I'd like to just disable the -fghci-leak-check flag when the compiler is built without optimisation, but it doesn't look like we have an easy way to do that. And even if we could, it would be fragile anyway, Test Plan: `cd testsuite/tests/ghci; make` Reviewers: bgamari, hvr, erikd, tdammers Subscribers: tdammers, rwbarton, thomie, carter GHC Trac Issues: #15246 Differential Revision: https://phabricator.haskell.org/D4872
* Run the renamed source plugin after each HsGroupMatthew Pickering2018-07-122-19/+25
| | | | | | | | | | | | | | | | | | This allows modification of each `HsGroup` after it has been renamed. The old behaviour of keeping the renamed source until later can be recovered if desired by using the `keepRenamedSource` plugin but it shouldn't really be necessary as it can be inspected in the `TcGblEnv`. Reviewers: nboldi, bgamari, alpmestan Reviewed By: nboldi, alpmestan Subscribers: alpmestan, rwbarton, thomie, carter GHC Trac Issues: #15315 Differential Revision: https://phabricator.haskell.org/D4947
* Add flag to show docs of valid hole fitsMatthías Páll Gissurarson2018-07-121-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One issue with valid hole fits is that the function names can often be opaque for the uninitiated, such as `($)`. This diff adds a new flag, `-fshow-docs-of-hole-fits` that adds the documentation of the identifier in question to the message, using the same mechanism as the `:doc` command. As an example, with this flag enabled, the valid hole fits for `_ :: [Int] -> Int` will include: ``` Valid hole fits include head :: forall a. [a] -> a {-^ Extract the first element of a list, which must be non-empty.-} with head @Int (imported from ‘Prelude’ (and originally defined in ‘GHC.List’)) ``` And one of the refinement hole fits, `($) _`, will read: ``` Valid refinement hole fits include ... ($) (_ :: [Int] -> Int) where ($) :: forall a b. (a -> b) -> a -> b {-^ Application operator. This operator is redundant, since ordinary application @(f x)@ means the same as @(f '$' x)@. However, '$' has low, right-associative binding precedence, so it sometimes allows parentheses to be omitted; for example: > f $ g $ h x = f (g (h x)) It is also useful in higher-order situations, such as @'map' ('$' 0) xs@, or @'Data.List.zipWith' ('$') fs xs@. Note that @($)@ is levity-polymorphic in its result type, so that foo $ True where foo :: Bool -> Int# is well-typed-} with ($) @'GHC.Types.LiftedRep @[Int] @Int (imported from ‘Prelude’ (and originally defined in ‘GHC.Base’)) ``` Another example of where documentation can come in very handy, is when working with the `lens` library. When you compile ``` {-# OPTIONS_GHC -fno-show-provenance-of-hole-fits -fshow-docs-of-hole-fits #-} module LensDemo where import Control.Lens import Control.Monad.State newtype Test = Test { _value :: Int } deriving (Show) value :: Lens' Test Int value f (Test i) = Test <$> f i updTest :: Test -> Test updTest t = t &~ do _ value (1 :: Int) ``` You get: ``` Valid hole fits include (#=) :: forall s (m :: * -> *) a b. MonadState s m => ALens s s a b -> b -> m () {-^ A version of ('Control.Lens.Setter..=') that works on 'ALens'.-} with (#=) @Test @(StateT Test Identity) @Int @Int (<#=) :: forall s (m :: * -> *) a b. MonadState s m => ALens s s a b -> b -> m b {-^ A version of ('Control.Lens.Setter.<.=') that works on 'ALens'.-} with (<#=) @Test @(StateT Test Identity) @Int @Int (<*=) :: forall s (m :: * -> *) a. (MonadState s m, Num a) => LensLike' ((,) a) s a -> a -> m a {-^ Multiply the target of a numerically valued 'Lens' into your 'Monad''s state and return the result. When you do not need the result of the multiplication, ('Control.Lens.Setter.*=') is more flexible. @ ('<*=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a ('<*=') :: ('MonadState' s m, 'Num' a) => 'Control.Lens.Iso.Iso'' s a -> a -> m a @-} with (<*=) @Test @(StateT Test Identity) @Int (<+=) :: forall s (m :: * -> *) a. (MonadState s m, Num a) => LensLike' ((,) a) s a -> a -> m a {-^ Add to the target of a numerically valued 'Lens' into your 'Monad''s state and return the result. When you do not need the result of the addition, ('Control.Lens.Setter.+=') is more flexible. @ ('<+=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a ('<+=') :: ('MonadState' s m, 'Num' a) => 'Control.Lens.Iso.Iso'' s a -> a -> m a @-} with (<+=) @Test @(StateT Test Identity) @Int (<-=) :: forall s (m :: * -> *) a. (MonadState s m, Num a) => LensLike' ((,) a) s a -> a -> m a {-^ Subtract from the target of a numerically valued 'Lens' into your 'Monad''s state and return the result. When you do not need the result of the subtraction, ('Control.Lens.Setter.-=') is more flexible. @ ('<-=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a ('<-=') :: ('MonadState' s m, 'Num' a) => 'Control.Lens.Iso.Iso'' s a -> a -> m a @-} with (<-=) @Test @(StateT Test Identity) @Int (<<*=) :: forall s (m :: * -> *) a. (MonadState s m, Num a) => LensLike' ((,) a) s a -> a -> m a {-^ Modify the target of a 'Lens' into your 'Monad''s state by multipling a value and return the /old/ value that was replaced. When you do not need the result of the operation, ('Control.Lens.Setter.*=') is more flexible. @ ('<<*=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a ('<<*=') :: ('MonadState' s m, 'Num' a) => 'Iso'' s a -> a -> m a @-} with (<<*=) @Test @(StateT Test Identity) @Int (Some hole fits suppressed; use -fmax-valid-hole-fits=N or -fno-max-valid-hole-fits) ``` Which allows you to see at a glance what opaque operators like `(<<*=)` and `(<#=)` do. Reviewers: bgamari, sjakobi Reviewed By: sjakobi Subscribers: sjakobi, alexbiehl, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4848
* Mark AutoDeriveTypeable as deprecatedKrzysztof Gogolewski2018-07-061-1/+4
| | | | | | | | | | | | | | Test Plan: validate Reviewers: bgamari, alpmestan Reviewed By: alpmestan Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15342 Differential Revision: https://phabricator.haskell.org/D4933
* Typofixes in comments and whitespace only [ci skip]Gabor Greif2018-06-261-2/+2
|
* Remove -Wamp flagroland2018-06-221-3/+0
| | | | | | | | | | | | | | Test Plan: "ghc -Wamp XXX.hs" should give "unrecognised warning flag" Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11477 Differential Revision: https://phabricator.haskell.org/D4785
* Fix gcc.exe: error: CreateProcess: No such file or directoryMoritz Angermann2018-06-204-2/+44
| | | | | | | | | | | | | | | | | | | | | | | | | When GHC links binaries on windows, we pass a -L and -l flag to gcc for each dependency in the transitive dependency closure. As this will usually overflow the command argument limit on windows, we use response files to pass all arguments to gcc. gcc however internally passes only the -l flags via a response file to the collect2 command, but puts the -L flags on the command line. As such if we pass enough -L flags to gcc--even via a response file--we will eventually overflow the command line argument length limit due to gcc passing them to collect2 without resorting to a response file. To prevent this from happening we move all lirbaries into a shared temporary folder, and only need to pass a single -L flag to gcc. Ideally however this was fixed in gcc. Reviewers: bgamari, Phyx Reviewed By: bgamari Subscribers: erikd, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4762
* A few more typofixes in docs/comments [ci skip]Gabor Greif2018-06-201-1/+1
|
* Typofixes in docs and comments [ci skip]Gabor Greif2018-06-182-2/+2
|
* Add -Werror=compatVladislav Zavialov2018-06-171-4/+12
| | | | | | | | | | | | | | | | | | Add a flag `-Werror=compat` to GHC which has the effect of `-Werror=x -Werror=y ...`, where `x, y, ...` are warnings from the `-Wcompat` option group. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15278 Differential Revision: https://phabricator.haskell.org/D4860
* Improve error message when importing an unusable packageSean D Gillespie2018-06-173-32/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a module cannot be found because it is ignored or from an unusable package, report this to the user and the reason it is unusable. Currently, GHC displays the standard "Cannot find module error". For example: ``` <no location info>: error: Could not find module ‘Control.Monad.Random’ Perhaps you meant Control.Monad.Reader (from mtl-2.2.2) Control.Monad.Cont (from mtl-2.2.2) Control.Monad.Error (from mtl-2.2.2) ``` GHC does, however, indicate unusable/ignored packages with the -v flag: ``` package MonadRandom-0.5.1-1421RgpXdhC8e8UI7D3emA is unusable due to missing dependencies: fail-4.9.0.0-BAHmj60kS5K7NVhhKpm9J5 ``` With this change, I took that message and added it to the output of the "Cannot find module" message. Reviewers: bgamari, dfeuer Reviewed By: bgamari Subscribers: Phyx, dfeuer, rwbarton, thomie, carter GHC Trac Issues: #4806 Differential Revision: https://phabricator.haskell.org/D4783
* Warn about implicit kind variables with -WcompatVladislav Zavialov2018-06-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | | According to an accepted proposal https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002 4-no-kind-vars.rst With -Wcompat, warn if a kind variable is brought into scope implicitly in a type with an explicit forall. This applies to type signatures and to other contexts that allow a forall with the forall-or-nothing rule in effect (for example, class instances). Test Plan: Validate Reviewers: goldfire, hvr, bgamari, RyanGlScott Reviewed By: goldfire Subscribers: RyanGlScott, rwbarton, thomie, carter GHC Trac Issues: #15264 Differential Revision: https://phabricator.haskell.org/D4834
* Enhanced constant foldingSylvain Henry2018-06-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now GHC only supported basic constant folding (lit op lit, expr op 0, etc.). This patch uses laws of +/-/* (associativity, commutativity, distributivity) to support some constant folding into nested expressions. Examples of new transformations: - simple nesting: (10 + x) + 10 becomes 20 + x - deep nesting: 5 + x + (y + (z + (t + 5))) becomes 10 + (x + (y + (z + t))) - distribution: (5 + x) * 6 becomes 30 + 6*x - simple factorization: 5 + x + (x + (x + (x + 5))) becomes 10 + (4 *x) - siblings: (5 + 4*x) - (3*x + 2) becomes 3 + x Test Plan: validate Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie GHC Trac Issues: #9136 Differential Revision: https://phabricator.haskell.org/D2858 (cherry picked from commit fea04defa64871caab6339ff3fc5511a272f37c7)
* Built-in Natural literals in CoreSylvain Henry2018-06-151-46/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for built-in Natural literals in Core. - Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber constructor with a LitNumType field - Support built-in Natural literals - Add desugar warning for negative literals - Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency reasons This patch introduces only a few rules for Natural literals (compared to Integer's rules). Factorization of the built-in rules for numeric literals will be done in another patch as this one is already big to review. Test Plan: validate test build with integer-simple Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar Reviewed By: bgamari Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton, thomie GHC Trac Issues: #14170, #14465 Differential Revision: https://phabricator.haskell.org/D4212
* Embrace -XTypeInType, add -XStarIsTypeVladislav Zavialov2018-06-143-2/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Implement the "Embrace Type :: Type" GHC proposal, .../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst GHC 8.0 included a major change to GHC's type system: the Type :: Type axiom. Though casual users were protected from this by hiding its features behind the -XTypeInType extension, all programs written in GHC 8+ have the axiom behind the scenes. In order to preserve backward compatibility, various legacy features were left unchanged. For example, with -XDataKinds but not -XTypeInType, GADTs could not be used in types. Now these restrictions are lifted and -XTypeInType becomes a redundant flag that will be eventually deprecated. * Incorporate the features currently in -XTypeInType into the -XPolyKinds and -XDataKinds extensions. * Introduce a new extension -XStarIsType to control how to parse * in code and whether to print it in error messages. Test Plan: Validate Reviewers: goldfire, hvr, bgamari, alanz, simonpj Reviewed By: goldfire, simonpj Subscribers: rwbarton, thomie, mpickering, carter GHC Trac Issues: #15195 Differential Revision: https://phabricator.haskell.org/D4748
* Run typeCheckResultAction and renamedResultAction in TcM rather than HscMatthew Pickering2018-06-072-37/+10
| | | | | | | | | | | | | | | | | The primary motivation for this is that this allows users to access the warnings and error machinery present in TcM. However, it also allows users to use TcM actions which means they can typecheck GhcPs which could be significantly easier than constructing GhcTc. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15229 Differential Revision: https://phabricator.haskell.org/D4792
* Introduce DerivingViaRyan Scott2018-06-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the `DerivingVia` proposal put forth in https://github.com/ghc-proposals/ghc-proposals/pull/120. This introduces the `DerivingVia` deriving strategy. This is a generalization of `GeneralizedNewtypeDeriving` that permits the user to specify the type to `coerce` from. The major change in this patch is the introduction of the `ViaStrategy` constructor to `DerivStrategy`, which takes a type as a field. As a result, `DerivStrategy` is no longer a simple enumeration type, but rather something that must be renamed and typechecked. The process by which this is done is explained more thoroughly in section 3 of this paper ( https://www.kosmikus.org/DerivingVia/deriving-via-paper.pdf ), although I have inlined the relevant parts into Notes where possible. There are some knock-on changes as well. I took the opportunity to do some refactoring of code in `TcDeriv`, especially the `mkNewTypeEqn` function, since it was bundling all of the logic for (1) deriving instances for newtypes and (2) `GeneralizedNewtypeDeriving` into one huge broth. `DerivingVia` reuses much of part (2), so that was factored out as much as possible. Bumps the Haddock submodule. Test Plan: ./validate Reviewers: simonpj, bgamari, goldfire, alanz Subscribers: alanz, goldfire, rwbarton, thomie, mpickering, carter GHC Trac Issues: #15178 Differential Revision: https://phabricator.haskell.org/D4684
* Serialize docstrings to ifaces, display them with new GHCi :doc commandSimon Jakobi2018-06-043-5/+104
| | | | | | | | | | | | | | | | | | | | | | | | If `-haddock` is set, we now extract docstrings from the renamed ast and serialize them in the .hi-files. This includes some of the changes from D4749 with the notable exceptions of the docstring lexing and renaming. A currently limited and experimental GHCi :doc command can be used to display docstrings for declarations. The formatting of pretty-printed docstrings is changed slightly, causing some changes in testsuite/tests/haddock. Test Plan: ./validate Reviewers: alexbiehl, hvr, gershomb, harpocrates, bgamari Reviewed By: alexbiehl Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4758
* Implement QuantifiedConstraintsSimon Peyton Jones2018-06-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have wanted quantified constraints for ages and, as I hoped, they proved remarkably simple to implement. All the machinery was already in place. The main ticket is Trac #2893, but also relevant are #5927 #8516 #9123 (especially! higher kinded roles) #14070 #14317 The wiki page is https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints which in turn contains a link to the GHC Proposal where the change is specified. Here is the relevant Note: Note [Quantified constraints] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The -XQuantifiedConstraints extension allows type-class contexts like this: data Rose f x = Rose x (f (Rose f x)) instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2 Note the (forall b. Eq b => Eq (f b)) in the instance contexts. This quantified constraint is needed to solve the [W] (Eq (f (Rose f x))) constraint which arises form the (==) definition. Here are the moving parts * Language extension {-# LANGUAGE QuantifiedConstraints #-} and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension * A new form of evidence, EvDFun, that is used to discharge such wanted constraints * checkValidType gets some changes to accept forall-constraints only in the right places. * Type.PredTree gets a new constructor ForAllPred, and and classifyPredType analyses a PredType to decompose the new forall-constraints * Define a type TcRnTypes.QCInst, which holds a given quantified constraint in the inert set * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst], which holds all the Given forall-constraints. In effect, such Given constraints are like local instance decls. * When trying to solve a class constraint, via TcInteract.matchInstEnv, use the InstEnv from inert_insts so that we include the local Given forall-constraints in the lookup. (See TcSMonad.getInstEnvs.) * topReactionsStage calls doTopReactOther for CIrredCan and CTyEqCan, so they can try to react with any given quantified constraints (TcInteract.matchLocalInst) * TcCanonical.canForAll deals with solving a forall-constraint. See Note [Solving a Wanted forall-constraint] Note [Solving a Wanted forall-constraint] * We augment the kick-out code to kick out an inert forall constraint if it can be rewritten by a new type equality; see TcSMonad.kick_out_rewritable Some other related refactoring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Move SCC on evidence bindings to post-desugaring, which fixed #14735, and is generally nicer anyway because we can use existing CoreSyn free-var functions. (Quantified constraints made the free-vars of an ev-term a bit more complicated.) * In LookupInstResult, replace GenInst with OneInst and NotSure, using the latter for multiple matches and/or one or more unifiers
* Allow aligning of cmm procs at specific boundryklebinger.andreas@gmx.at2018-06-031-0/+7
| | | | | | | | | | | | | | | | | | | | Allows to align CmmProcs at the given boundries. It makes performance usually worse but can be helpful to limit the effect of a unrelated function B becoming faster/slower after changing function A. Test Plan: ci, using it. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15148 Differential Revision: https://phabricator.haskell.org/D4706
* Turn "inaccessible code" error into a warningTobias Dammers2018-06-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With GADTs, it is possible to write programs such that the type constraints make some code branches inaccessible. Take, for example, the following program :: {-# LANGUAGE GADTs #-} data Foo a where Foo1 :: Foo Char Foo2 :: Foo Int data TyEquality a b where Refl :: TyEquality a a checkTEQ :: Foo t -> Foo u -> Maybe (TyEquality t u) checkTEQ x y = error "unimportant" step2 :: Bool step2 = case checkTEQ Foo1 Foo2 of Just Refl -> True -- Inaccessible code Nothing -> False Clearly, the `Just Refl` case cannot ever be reached, because the `Foo1` and `Foo2` constructors say `t ~ Char` and `u ~ Int`, while the `Refl` constructor essentially mandates `t ~ u`, and thus `Char ~ Int`. Previously, GHC would reject such programs entirely; however, in practice this is too harsh. Accepting such code does little harm, since attempting to use the "impossible" code will still produce errors down the chain, while rejecting it means we cannot legally write or generate such code at all. Hence, we turn the error into a warning, and provide `-Winaccessible-code` to control GHC's behavior upon encountering this situation. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11066 Differential Revision: https://phabricator.haskell.org/D4744
* Extended the plugin system to run plugins on more representationsBoldizsar Nemeth2018-06-022-44/+129
| | | | | | | | | | | | | | | | | | | | Extend GHC plugins to access parsed, type checked representation, interfaces that are loaded. And splices that are evaluated. The goal is to enable development tools to access the GHC representation in the pre-existing build environment. See the full proposal here: https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal Reviewers: goldfire, bgamari, ezyang, angerman, mpickering Reviewed By: mpickering Subscribers: ezyang, angerman, mpickering, ulysses4ever, rwbarton, thomie, carter GHC Trac Issues: #14709 Differential Revision: https://phabricator.haskell.org/D4342
* vectorise: Put it out of its miseryBen Gamari2018-06-024-236/+9
| | | | | | | | | | | | | | | | | | | | | Poor DPH and its vectoriser have long been languishing; sadly it seems there is little chance that the effort will be rekindled. Every few years we discuss what to do with this mass of code and at least once we have agreed that it should be archived on a branch and removed from `master`. Here we do just that, eliminating heaps of dead code in the process. Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and `primitive` submodules. Test Plan: Validate Reviewers: simonpj, simonmar, hvr, goldfire, alanz Reviewed By: simonmar Subscribers: goldfire, rwbarton, thomie, mpickering, carter Differential Revision: https://phabricator.haskell.org/D4761
* dead strip dylibs on macOSMoritz Angermann2018-05-302-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When linking dynamic libraries or executables, we compute the full transitive closure over the dependencies, and instruct the linker to link all dependencies. With deep dependency trees the number of transitive dependencies can grow quickly. macOS since the Sierra release has an upper limit on the load command sizes the linker parses when loading dynamic lirbaries. As such it is mandatory to keep the number of load commands (and their size) small on recent macOS releases. An approach that would just link direct dependencies as specified by the -package-id flag is insufficient, because GHC can inline across packages and the library or executable being linked could refer to symbols deep in the dependency tree. If we just recursively linked librarys and re-exported their symbols, this increases the number of symbols in libraries with many dependencies and ultimately puts excessive strain on the linker to the point where linking takes a lot longer than even the compilation of the modules. We can however build a list of symbols from the obejcts we want to link, and try to compute the libraries we need to link that contain those symbols from the transitive dependency closure. Luckily, we don't need to write this ourselves, but can use the ld64 `-dead_strip_dylibs` linker flag on macOS to achive the same result. This will link only the libraries that are actually referenced, which is usually a small subset of the full transitive dependency closure. As such we should stay within the load command size limit for almost all but pathological cases. Reviewers: bgamari Reviewed By: bgamari Subscribers: lelf, rwbarton, thomie, carter GHC Trac Issues: #14444 Differential Revision: https://phabricator.haskell.org/D4714
* Implement "An API for deciding whether plugins should cause recompilation"Matthew Pickering2018-05-303-15/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the API proposed as pull request #108 for plugin authors to influence the recompilation checker. It adds a new field to a plugin which computes a `FingerPrint`. This is recorded in interface files and if it changes then we recompile the module. There are also helper functions such as `purePlugin` and `impurePlugin` for constructing plugins which have simple recompilation semantics but in general, an author can compute a hash as they wish. Fixes #12567 and #7414 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002 2-plugin-recompilation.rst Reviewers: bgamari, ggreif Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #7414, #12567 Differential Revision: https://phabricator.haskell.org/D4366
* Improved Valid Hole FitsMatthías Páll Gissurarson2018-05-301-32/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've changed the name from `Valid substitutions` to `Valid hole fits`, since "substitution" already has a well defined meaning within the theory. As part of this change, the flags and output is reanamed, with substitution turning into hole-fit in most cases. "hole fit" was already used internally in the code, it's clear and shouldn't cause any confusion. In this update, I've also reworked how we manage side-effects in the hole we are considering. This allows us to consider local bindings such as where clauses and arguments to functions, suggesting e.g. `a` for `head (x:xs) where head :: [a] -> a`. It also allows us to find suggestions such as `maximum` for holes of type `Ord a => a -> [a]`, and `max` when looking for a match for the hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`. We also show much improved output for refinement hole fits, and fixes #14990. We now show the correct type of the function, but we also now show what the arguments to the function should be e.g. `foldl1 (_ :: Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`. I've moved the bulk of the code from `TcErrors.hs` to a new file, `TcHoleErrors.hs`, since it was getting too big to not live on it's own. This addresses the considerations raised in #14969, and takes proper care to set the `tcLevel` of the variables to the right level before passing it to the simplifier. We now also zonk the suggestions properly, which improves the output of the refinement hole fits considerably. This also filters out suggestions from the `GHC.Err` module, since even though `error` and `undefined` are indeed valid hole fits, they are "trivial", and almost never useful to the user. We now find the hole fits using the proper manner, namely by solving nested implications. This entails that the givens are passed along using the implications the hole was nested in, which in turn should mean that there will be fewer weird bugs in the typed holes. I've also added a new sorting method (as suggested by SPJ) and sort by the size of the types needed to turn the hole fits into the type of the hole. This gives a reasonable approximation to relevance, and is much faster than the subsumption check. I've also added a flag to toggle whether to use this new sorting algorithm (as is done by default) or the subsumption algorithm. This fixes #14969 I've also added documentation for these new flags and update the documentation according to the new output. Reviewers: bgamari, goldfire Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14969, #14990, #10946 Differential Revision: https://phabricator.haskell.org/D4444
* Extract hard-coded LLVM opt flags into a fileKavon Farvardin2018-05-304-20/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | To resolve ticket #11295, I think it makes sense to stop hard-coding the pass sequences used by GHC when compiling with LLVM into the compiler itself. This patchset introduces a companion to the existing `llvm-targets` file called `llvm-passes`. The passes file is a simple association list that holds the default LLVM `opt` pass sequence used by GHC. This allows end users to easily save their favorite optimization flags when compiling with LLVM. The main benefit for ticket #11295 is that when adding a custom pass sequence, it tends to be an extremely long string that would be unsightly in the code. This is essentially part 1 of 2 for ticket #11295. Test Plan: ./validate Reviewers: bgamari, angerman Reviewed By: angerman Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4695
* Minor refactoringGabor Greif2018-05-291-1/+1
|
* Typofixes [ci skip]Gabor Greif2018-05-291-1/+1
|
* isDllName: use Opt_ExternalDynamicRefs, not WayDynSimon Marlow2018-05-251-1/+1
| | | | This should have been part of D4477, but got missed.
* Add -fghci-leak-check to check for space leaksSimon Marlow2018-05-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: (re-applying this patch now that D4659 is committed) Space leaks in GHCi emerge from time to time and tend to come back again after they get fixed. This is an attempt to limit regressions by * adding a reliable detection for some classes of space leaks in GHCi * turning on leak checking for all GHCi tests in the test suite, so that we'll notice if the leak appears again. The idea for detecting space leaks is quite simple: * find some data that we expect to be GC'd later, make a weak pointer to it * when we expect the data to be dead, do a `performGC` and then check the status of the weak pointer. It would be nice to apply this trick to lots of things in GHC, e.g. ensuring that HsSyn is not retained after the desugarer, or ensuring that CoreSyn from the previous simplifier pass is not retained. Test Plan: validate Reviewers: bgamari, simonpj, erikd, niteria Subscribers: thomie, carter GHC Trac Issues: #15111
* Fix GHCi space leaks (#15111)Simon Marlow2018-05-171-1/+2
| | | | | | | | | | | | | | | | | Summary: There were a number of leaks causing previously loaded modules to be retained after a new `:load`. This fixes enough leaks to get the tests to pass from D4658. Test Plan: See new tests in D4658 Reviewers: niteria, bgamari, simonpj, erikd Subscribers: thomie, carter GHC Trac Issues: #15111 Differential Revision: https://phabricator.haskell.org/D4659
* An overhaul of the SRT representationSimon Marlow2018-05-161-13/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - Previously we would hvae a single big table of pointers per module, with a set of bitmaps to reference entries within it. The new representation is identical to a static constructor, which is much simpler for the GC to traverse, and we get to remove the complicated bitmap-traversal code from the GC. - Rewrite all the code to generate SRTs in CmmBuildInfoTables, and document it much better (see Note [SRTs]). This has been something I've wanted to do since we moved to the new code generator, I finally had the opportunity to finish it while on a transatlantic flight recently :) There are a series of 4 diffs: 1. D4632 (this one), which does the bulk of the changes 2. D4633 which adds support for smaller `CmmLabelDiffOff` constants 3. D4634 which takes advantage of D4632 and D4633 to save a word in info tables that have an SRT on x86_64. This is where most of the binary size improvement comes from. 4. D4637 which makes a further optimisation to merge some SRTs with static FUN closures. This adds some complexity and the benefits are fairly modest, so it's not clear yet whether we should do this. Results (after (3), on x86_64) - GHC itself (staticaly linked) is 5.2% smaller - -1.7% binary sizes in nofib, -2.9% module sizes. Full nofib results: P176 - I measured the overhead of traversing all the static objects in a major GC in GHC itself by doing `replicateM_ 1000 performGC` as the first thing in `Main.main`. The new version was 5-10% faster, but the results did vary quite a bit. - I'm not sure if there's a compile-time difference, the results are too unreliable. Test Plan: validate Reviewers: bgamari, michalt, niteria, simonpj, erikd, osa1 Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D4632
* Less Tc inside simplCore (Phase 1 for #14391)Artem Pelenitsyn2018-05-152-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simplifier depends on typechecker in two points: `thNameToGhcName` (`lookupThName_maybe`, in particular) and `lookupGlobal`. We want to cut the ties in two steps. 1. (Presented in this commit), reimplement both functions in a way that doesn't use typechecker. 2. (Should follow), do code moving: a) `lookupGlobal` should go in some typechecker-free place; b) `thNameToGhcName` should leave simplifier, because it is not used there at all (probably, it should be placed somewhere where `GhcPlugins` can see it -- this is suggested by Joachim on Trac). Details ======= We redesigned lookup interface a bit so that it exposes some `IO`-equivalents of `Tc`-features in use. First, `CoreMonad.hs` still calls `lookupGlobal` which is no longer bound to the typechecker monad, but still resides in `TcEnv.hs` — it should be moved out of Tc-land at some point (“Phase 2”) in the future in order to achieve its part of the #14391's goal. Second, `lookupThName_maybe` is eliminated from `CoreMonad.hs` completely; this already achieves its part of the goal of #14391. Its client, though, `thNameToGhcName`, is better to be moved in the future also, for it is not used in the `CoreMonad.hs` (or anywhere else) anyway. Joachim suggested “any module reexported by GhcPlugins (or maybe even that module itself)”. As a side goal, we removed `initTcForLookup` which was instrumental for the past version of `lookupGlobal`. This, in turn, called for pushing some more parts of the lookup interface from the `Tc`-monad to `IO`, most notably, adding `IO`-version of `lookupOrig` and pushing `dataConInfoPtrToName` to `IO`. The `lookupOrig` part, in turn, triggered a slight redesign of name cache updating interface: we now have both, `updNameCacheIO` and `updNameCacheTc`, both accepting `mod` and `occ` to force them inside, instead of more error-prone outside before. But all these hardly have to do anything with #14391, mere refactoring. Reviewers: simonpj, nomeata, bgamari, hvr Reviewed By: simonpj, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14391 Differential Revision: https://phabricator.haskell.org/D4503
* Add support for opting out of package environmentsHerbert Valerio Riedel2018-05-131-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | This implements the first part proposed in #13753: Define a special magic "null" environment, which instructs GHC to ignore any package environment files. To this end, I propose to use the name `-` (i.e. a single dash), as that is more portable than using the empty string for environment variables. In other words, a - `-package-env -` CLI flag, or a - `GHC_ENVIRONMENT=-` env var (unless a `-package-env` flag is present) would inhibit GHC from looking up and interpreting any package environment files from the filesystem; this is the equivalent of `-ignore-dot-ghci` for package environment files. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13753 Differential Revision: https://phabricator.haskell.org/D4690
* GHCi: Include a note in the hint to expose a hidden packageChaitanya Koparkar2018-05-131-1/+2
| | | | | | | | | | | | | | Test Plan: validate Reviewers: bgamari, RyanGlScott, osa1 Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15055 Differential Revision: https://phabricator.haskell.org/D4669
* Simplify -ddump-json implementationMatthew Pickering2018-05-133-73/+25
| | | | | | | | | | | | | | | | | | | This patch takes the much simpler route of whenever the compiler tries to output something. We just dump a JSON document there and then. I think this should be sufficient to work with and anything more refined quickly got complicated as it was necessary to demarcate message scopes and so on. Reviewers: bgamari, dfeuer Reviewed By: bgamari Subscribers: Phyx, dfeuer, rwbarton, thomie, carter GHC Trac Issues: #14078 Differential Revision: https://phabricator.haskell.org/D4532
* Emit info-level log message when package envs are loadedHerbert Valerio Riedel2018-05-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | A common complaint with the new package environment files feature is that it's not obvious when package environments have been picked up. This patch applies the same strategy that was already used for `.ghci` files (which exhibit similar potential for confusion, c.f. #11389) to package environment files. For instance, this new notification looks like below for a GHCi invocation which loads both, a GHCi configuration as well as a package environment: GHCi, version 8.5.20180512: http://www.haskell.org/ghc/ :? for help Loaded package environment from /tmp/parsec-3.1.13.0/.ghc.environment.x86_64-linux-8.5.20180512 Loaded GHCi configuration from /home/hvr/.ghci Prelude> Addresses #15145 Reviewed By: bgamari, angerman GHC Trac Issues: #15145 Differential Revision: https://phabricator.haskell.org/D4689
* Expand $tooldir in ghc --info outputAlp Mestanogullari2018-05-122-6/+13
| | | | | | | | | | | | | | | | | | | | | Summary: This requires adding an `sToolDir :: Maybe FilePath` field to Settings, since compilerInfo is pure and therefore needs to have all the information available in the DynFlags. This should fix #15101 and #15107. Test Plan: ./validate --fast Reviewers: Phyx, bgamari Reviewed By: Phyx Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15101, #15107 Differential Revision: https://phabricator.haskell.org/D4686
* Revert "Add -fghci-leak-check to check for space leaks"Simon Marlow2018-05-101-2/+0
| | | | This reverts commit 5fe6aaa3756cda654374ebfd883fa8f064ff64a4.
* Add -fghci-leak-check to check for space leaksSimon Marlow2018-05-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Space leaks in GHCi emerge from time to time and tend to come back again after they get fixed. This is an attempt to limit regressions by * adding a reliable detection for some classes of space leaks in GHCi * turning on leak checking for all GHCi tests in the test suite, so that we'll notice if the leak appears again. The idea for detecting space leaks is quite simple: * find some data that we expect to be GC'd later, make a weak pointer to it * when we expect the data to be dead, do a `performGC` and then check the status of the weak pointer. It would be nice to apply this trick to lots of things in GHC, e.g. ensuring that HsSyn is not retained after the desugarer, or ensuring that CoreSyn from the previous simplifier pass is not retained. Test Plan: validate Reviewers: bgamari, simonpj, erikd, niteria Subscribers: thomie, carter GHC Trac Issues: #15111 Differential Revision: https://phabricator.haskell.org/D4658
* Do not supply `-mcpu` if `-optlc` provides `-mcpu` already.Moritz Angermann2018-05-051-2/+3
| | | | | | | | | | Reviewers: bgamari Subscribers: thomie, carter GHC Trac Issues: #14982 Differential Revision: https://phabricator.haskell.org/D4548
* GHCi: Improve the error message for hidden packagesChaitanya Koparkar2018-05-031-3/+7
| | | | | | | | | | | | | | Test Plan: make test TEST=T15055 Reviewers: bgamari, RyanGlScott, osa1, Iceland_jack Reviewed By: osa1 Subscribers: ulysses4ever, thomie, carter GHC Trac Issues: #15055 Differential Revision: https://phabricator.haskell.org/D4621
* TTG : complete for balance of hsSyn ASTAlan Zimmerman2018-04-274-9/+14
| | | | | | | | | | | | | | | | | | Summary: - remove PostRn/PostTc fields - remove the HsVect In/Out distinction for Type, Class and Instance - remove PlaceHolder in favour of NoExt - Simplify OutputableX constraint Updates haddock submodule Test Plan: ./validate Reviewers: goldfire, bgamari Subscribers: goldfire, thomie, mpickering, carter Differential Revision: https://phabricator.haskell.org/D4625
* Introduce a $tooldir variable for nicer toolchain detection on WindowsAlp Mestanogullari2018-04-172-16/+72
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch affects several files that affect how we detect mingw and perl on Windows. The initial motivation is: https://github.com/snowleopard/hadrian/issues/564 where, with Hadrian building relocatable (non-inplace) GHCs, the current detection mechanism falls short by e.g only trying $topdir/../mingw. But in Hadrian, for reasons given in that issue, we would need to store e.g mingw under $topdir/../../mingw except for binary distributions, where we want to follow the existing structure, in which case $topdir/../mingw is correct. So we need to support both, which is what this patch hopefully implements. Test Plan: ./validate Reviewers: Phyx, hvr, bgamari, erikd Reviewed By: Phyx Subscribers: snowleopard, thomie, carter Differential Revision: https://phabricator.haskell.org/D4598
* Revert "Enhanced constant folding"Ben Gamari2018-04-161-3/+0
| | | | | | | I need to upgrade GHC on the CI builders before landing this due to a bug in 8.2.1 triggered by this patch. This reverts commit fea04defa64871caab6339ff3fc5511a272f37c7.
* Enhanced constant foldingSylvain Henry2018-04-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now GHC only supported basic constant folding (lit op lit, expr op 0, etc.). This patch uses laws of +/-/* (associativity, commutativity, distributivity) to support some constant folding into nested expressions. Examples of new transformations: - simple nesting: (10 + x) + 10 becomes 20 + x - deep nesting: 5 + x + (y + (z + (t + 5))) becomes 10 + (x + (y + (z + t))) - distribution: (5 + x) * 6 becomes 30 + 6*x - simple factorization: 5 + x + (x + (x + (x + 5))) becomes 10 + (4 *x) - siblings: (5 + 4*x) - (3*x + 2) becomes 3 + x Test Plan: validate Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie GHC Trac Issues: #9136 Differential Revision: https://phabricator.haskell.org/D2858
* Make shortcutting at the asm stage toggleable and default for O2.Andreas Klebinger2018-04-131-0/+4
| | | | | | | | | | | | | | | | | | | Shortcutting during the asm stage of codegen is often redundant as most cases get caught during the Cmm passes. For example during compilation of all of nofib only 508 jumps are eleminated. For this reason I moved the pass from -O1 to -O2. I also made it toggleable with -fasm-shortcutting. Test Plan: ci Reviewers: bgamari Reviewed By: bgamari Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D4555
View Lorry Controller Status