summaryrefslogtreecommitdiff
path: root/compiler/ghc.mk
Commit message (Collapse)AuthorAgeFilesLines
* Package keys (for linking/type equality) separated from package IDs.Edward Z. Yang2014-08-051-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch set makes us no longer assume that a package key is a human readable string, leaving Cabal free to "do whatever it wants" to allocate keys; we'll look up the PackageId in the database to display to the user. This also means we have a new level of qualifier decisions to make at the package level, and rewriting some Safe Haskell error reporting code to DTRT. Additionally, we adjust the build system to use a new ghc-cabal output Make variable PACKAGE_KEY to determine library names and other things, rather than concatenating PACKAGE/VERSION as before. Adds a new `-this-package-key` flag to subsume the old, erroneously named `-package-name` flag, and `-package-key` to select packages by package key. RFC: The md5 hashes are pretty tough on the eye, as far as the file system is concerned :( ToDo: safePkg01 test had its output updated, but the fix is not really right: the rest of the dependencies are truncated due to the fact the we're only grepping a single line, but ghc-pkg is wrapping its output. ToDo: In a later commit, update all submodules to stop using -package-name and use -this-package-key. For now, we don't do it to avoid submodule explosion. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, simonmar, hvr, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D80
* compiler/ghc.mk: restore GhcHcOpts variable handling (Trac #8787)Sergei Trofimovich2014-07-021-3/+3
| | | | | | | | | | | | | | | | | | | Summary: wiki and mk/config.mk.in suggests setting GhcHcOpts for compiler-wide haskell flags. But it does not work for a while now (broke around ca07d92837fc1e3ae9be67bb7d9e7f1b8035b00f) Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Test Plan: 'make' shows now ghc timing as it used to be Reviewers: simonmar, austin Reviewed By: austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D29
* Control CPP through settings file (#8683)Carter Tazio Schonwald2014-07-021-2/+0
| | | | | | | | | | | | | | | | Summary: Allow the CPP program and flag choices for GHC be configured via the the ghc settings file Test Plan: ran validate yesterday Reviewers: hvr, austin, mzero, simonmar Reviewed By: austin, mzero, simonmar Subscribers: mzero, simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D26
* Fix --enable-unregistered by passing NOSMP to .hc compiler (#8748)Sergei Trofimovich2014-02-171-0/+5
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Implement pattern synonymsDr. ERDI Gergo2014-01-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements Pattern Synonyms (enabled by -XPatternSynonyms), allowing y ou to assign names to a pattern and abstract over it. The rundown is this: * Named patterns are introduced by the new 'pattern' keyword, and can be either *unidirectional* or *bidirectional*. A unidirectional pattern is, in the simplest sense, simply an 'alias' for a pattern, where the LHS may mention variables to occur in the RHS. A bidirectional pattern synonym occurs when a pattern may also be used in expression context. * Unidirectional patterns are declared like thus: pattern P x <- x:_ The synonym 'P' may only occur in a pattern context: foo :: [Int] -> Maybe Int foo (P x) = Just x foo _ = Nothing * Bidirectional patterns are declared like thus: pattern P x y = [x, y] Here, P may not only occur as a pattern, but also as an expression when given values for 'x' and 'y', i.e. bar :: Int -> [Int] bar x = P x 10 * Patterns can't yet have their own type signatures; signatures are inferred. * Pattern synonyms may not be recursive, c.f. type synonyms. * Pattern synonyms are also exported/imported using the 'pattern' keyword in an import/export decl, i.e. module Foo (pattern Bar) where ... Note that pattern synonyms share the namespace of constructors, so this disambiguation is required as a there may also be a 'Bar' type in scope as well as the 'Bar' pattern. * The semantics of a pattern synonym differ slightly from a typical pattern: when using a synonym, the pattern itself is matched, followed by all the arguments. This means that the strictness differs slightly: pattern P x y <- [x, y] f (P True True) = True f _ = False g [True, True] = True g _ = False In the example, while `g (False:undefined)` evaluates to False, `f (False:undefined)` results in undefined as both `x` and `y` arguments are matched to `True`. For more information, see the wiki: https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation Reviewed-by: Simon Peyton Jones <simonpj@microsoft.com> Signed-off-by: Austin Seipp <austin@well-typed.com>
* ghc.mk: one module name per lineDr. ERDI Gergo2013-11-261-1/+164
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Make type-level evaluation work with :kind!Iavor S. Diatchki2013-11-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | The main change is to add a case to `reduceTyFamApp_maybe` to evaluate built-in type constructors (e.g., (+), (*), and friends). To avoid problems with recursive modules, I moved the definition of TcBuiltInSynFamily from `FamInst` to `FamInstEnv`. I am still not sure if this is the right place. There is also a wibble that it'd be nice to fix: when we evaluate a built-in type function, using`sfMatchFam`, we get a `TcCoercion`. However, `reduceTyFamApp_maybe` needs a `Corecion`. I couldn't find a nice way to convert between the two, so I resorted to a bit of hack (marked with `XXX`). The hack is that we happen to know that the built-in constructors for the type-nat functions always return coercions of shape `TcAxiomRuleCo`, with no assumptions, so it easy to convert `TcCoercion` to `Coercion` in this one case. This is enough to make things work, but it is clearly a cludge.
* Use dynamic linking only if the GHC package is compiled with -dynamic (#8376)Simon Marlow2013-10-111-6/+0
|
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-011-2/+2
|
* SIMD primops are now generated using schemas that are polymorphic inGeoffrey Mainland2013-09-221-2/+14
| | | | | | | | | | | | | width and element type. SIMD primops are now polymorphic in vector size and element type, but only internally to the compiler. More specifically, utils/genprimopcode has been extended so that it "knows" about SIMD vectors. This allows us to, for example, write a single definition for the "add two vectors" primop in primops.txt.pp and have it instantiated at many vector types. This generates a primop in GHC.Prim for each vector type at which "add two vectors" is instantiated, but only one data constructor for the PrimOp data type, so the code generator is much, much simpler.
* Restructure compilation pipeline to allow hooksAustin Seipp2013-09-221-1/+1
| | | | | | | | | | | | | | | | This commit exposes GHC's internal compiler pipeline through a `Hooks` module in the GHC API. It currently allows you to hook: * Foreign import/exports declarations * The frontend up to type checking * The one shot compilation mode * Core compilation, and the module iface * Linking and the phases in DriverPhases.hs * Quasiquotation Authored-by: Luite Stegeman <stegeman@gmail.com> Authored-by: Edsko de Vries <edsko@well-typed.com> Signed-off-by: Austin Seipp <austin@well-typed.com>
* Restore old names of comparison primopsJan Stolarek2013-09-181-2/+1
| | | | | | | | | | | | In 6579a6c we removed existing comparison primops and introduced new ones returning Int# instead of Bool. This commit (and associated commits in array, base, dph, ghc-prim, integer-gmp, integer-simple, primitive, testsuite and template-haskell) restores old names of primops. This allows us to keep our API cleaner at the price of not having backwards compatibility. This patch also temporalily disables fix for #8317 (optimization of tagToEnum# at Core level). We need to fix #8326 first, otherwise our primops code will be very slow.
* Trailing whitespacesJan Stolarek2013-09-181-2/+2
|
* Implement checkable "minimal complete definitions" (#7633)Twan van Laarhoven2013-09-181-1/+1
| | | | | | | | | | | | | | This commit adds a `{-# MINIMAL #-}` pragma, which defines the possible minimal complete definitions for a class. The body of the pragma is a boolean formula of names. The old warning for missing methods is replaced with this new one. Note: The interface file format is changed to store the minimal complete definition. Authored-by: Twan van Laarhoven <twanvl@gmail.com> Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Add support for evaluation of type-level natural numbers.Iavor S. Diatchki2013-09-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This patch implements some simple evaluation of type-level expressions featuring natural numbers. We can evaluate *concrete* expressions that use the built-in type families (+), (*), (^), and (<=?), declared in GHC.TypeLits. We can also do some type inference involving these functions. For example, if we encounter a constraint such as `(2 + x) ~ 5` we can infer that `x` must be 3. Note, however, this is used only to resolve unification variables (i.e., as a form of a constraint improvement) and not to generate new facts. This is similar to how functional dependencies work in GHC. The patch adds a new form of coercion, `AxiomRuleCo`, which makes use of a new form of axiom called `CoAxiomRule`. This is the form of evidence generate when we solve a constraint, such as `(1 + 2) ~ 3`. The patch also adds support for built-in type-families, by adding a new form of TyCon rhs: `BuiltInSynFamTyCon`. such built-in type-family constructors contain a record with functions that are used by the constraint solver to simplify and improve constraints involving the built-in function (see `TcInteract`). The record in defined in `FamInst`. The type constructors and rules for evaluating the type-level functions are in a new module called `TcTypeNats`.
* Merge branch 'ghc-parmake-gsoc' (#910)Patrick Palka2013-09-091-0/+6
|\
| * Merge remote-tracking branch 'origin/master' into ghc-parmake-gsocPatrick Palka2013-09-061-1/+16
| |\
| * | UniqSupply: make mkSplitUniqSupply thread-safePatrick Palka2013-08-261-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | unsafeInterleaveIO is used instead of unsafeDupableInterleaveIO because a mk_supply thunk that is simultaneously entered by two threads should evaluate to the same UniqSupply. The UniqSupply counter is now incremented atomically using the RTS's atomic_inc(). To mitigate the extra overhead of unsafeInterleaveIO in the single-threaded compiler, noDuplicate# is changed to exit early when n_capabilities == 1.
* | | Fix optimization of Parser.y.ppAustin Seipp2013-09-091-6/+9
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | In 9e133b, the build was modified to pass -fcmm-sink to Parser, but unfortunately Parser specifies -O0 in its OPTIONS_GHC directive, meaning the sinking pass was actually turned off. HC_OPTS is the last thing passed to the compiler for that source file however, so the correct fix is to also move -O0 out into the build system as well. This was uncovered thanks to a build report from Kazu Yamamoto. Thanks to Jan Stolarek for eyeballing this bug and finding it. Signed-off-by: Austin Seipp <aseipp@pobox.com>
* | Make sure -fcmm-sink is passed to Parser properlyAustin Seipp2013-09-041-1/+16
|/ | | | | | | | | | | | | | | | | | | Parser.hs needs to be compiled with -fcmm-sink on x86 platforms, so the register allocator doesn't run out of stack slots. Previously, we had to do some CPP hacks in order to emit an #ifdef into the file - this is because we preprocess it once up front, and run the preprocessor again when we compile it. There's two cases: the boostrap compiler is > 7.8, and the stage1 parser needs the flag, or the stage1 compiler is compiling the stage2 Parser.hs, and needs the flag.. The previous approach was super fragile with Clang. The more principled fix is to instead do this through the build system. This fixes #8182. Signed-off-by: Austin Seipp <aseipp@pobox.com>
* Fix Trac #8020.Richard Eisenberg2013-08-021-1/+1
| | | | | | | The solution is to use a different notion of apartness. See http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/axioms-extended.pdf for the gory details. Some comments are also in Notes [Compatibility] and [Apartness] in FamInstEnv.
* Link to the right RTS whenever we build a .dll on WindowsIan Lynagh2013-05-151-0/+16
| | | | | When GHCi makes temporary DLLs, those also need to be linked against the right RTS, or we won't be able to load them.
* Add a check that the Windows DLL split is OK; fixes #7780Ian Lynagh2013-04-071-0/+1
|
* Remove a redundant build-system hackIan Lynagh2013-04-061-11/+0
| | | | | We used to have to explicitly pass -lffi when linking the compiler, but it's no longer necessary.
* Change the list of modules that are put into a separate DLL on WindowsIan Lynagh2013-04-061-4/+2
| | | | Fixes #7780.
* By default, use the dynamic way for programs in the GHC treeIan Lynagh2013-03-151-0/+10
| | | | | In particular, this means that GHCi will use DLLs, rather than loading object files itself.
* Fix building the GHC package DLL on WindowsIan Lynagh2013-03-111-15/+9
| | | | | | We now put a handful of modules in a separate DLL. For now the list is hand-written, but we could automate it in the future.
* Automatically define _INPLACE variables for perl programs tooIan Lynagh2013-03-031-1/+1
| | | | and use them for split
* Use unlit_INPLACE rather than UNLIT in the build systemIan Lynagh2013-03-031-1/+1
|
* Define $(prog)_INPLACE variables automatically, and start using themIan Lynagh2013-03-031-24/+24
|
* Remove unused values from Config.hsIan Lynagh2013-03-021-12/+0
|
* Change how the build system handles packagesIan Lynagh2013-03-011-4/+0
| | | | | This makes the build system a little simpler, and in particular will make it easier to handle the changes needed for cross-compilation.
* fix some dependenciesSimon Marlow2013-02-191-3/+3
|
* fix PrimOp dependenciesSimon Marlow2013-02-181-3/+3
|
* Finish removing BootingFromHcIan Lynagh2013-02-171-2/+0
|
* Build system tweak: Do the package checks at configure timeIan Lynagh2013-02-151-0/+5
| | | | | | | | This removes the '.PHONY' rule, so means that "make" in a built tree won't repeat the check. We also now check the .cabal files for the executables as well as the libraries.
* Tidy up cross-compilingSimon Marlow2013-01-171-52/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have two cases: 1. building a cross-compiler 2. compiling GHC to run on a foreign platform These two are done with almost the same setup: (1) is the stage 1 compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES. The only difference between (1) and (2) is that you if you set up the build for (1), then it stops before stage 2 and you can 'make install' to install stage 1. Unfortunately, (2) didn't work, and the build system code needed some tidying up. Change to the way the build is set up: Before ------ To build a cross-compiler: ./configure --target=<..> To compile a foreign GHC: ./configure --host=<..> --target=<..> Now --- To build a cross-compiler: ./configure --target=<..> And set "Stage1Only=YES" in mk/build.mk To compile a foreign GHC: ./configure --target=<..>
* Don't define DYNAMIC when compiling the dyn wayIan Lynagh2012-12-051-6/+14
| | | | | | | | | We want to compile the sources only once, and to produce both vanilla and dyn object files. This means that the sources can't differ for the two ways. This needed a bit of a kludge to get keepCAFsForGHCi included only in the dynamic library.
* libffi build system tweaksIan Lynagh2012-11-301-0/+3
|
* Add fixity information to primops (ticket #6026)Michal Terepeta2012-11-231-0/+3
|
* Replace mkDerivedConstants.c with DeriveConstants.hsIan Lynagh2012-11-121-0/+10
| | | | | | | | | DeriveConstants.hs works in a cross-compilation-friendly way. Rather than running a C program that prints out the constants, we just compile a C file which has the constants are encoded in symbol sizes. We then parse the output of 'nm' to find out what the constants are. Based on work by Gabor Greif <ggreif@gmail.com>.
* Fix build on WindowsIan Lynagh2012-10-111-1/+1
| | | | | gcc couldn't find ghc_boot_platform.h. I'm not sure why it worked on Linux.
* Move the primop bits into the compiler/stage<n>/build directoriesIan Lynagh2012-10-101-61/+55
| | | | We shouldn't be generating files in the source directories
* Put the generated Parser.y under compiler/stage<n>/build; fixes #7195Ian Lynagh2012-10-101-1/+12
|
* Merge the remainder of HaskellConstants into ConstantsIan Lynagh2012-09-171-5/+1
|
* Add a couple more mkDerivedConstants modesIan Lynagh2012-09-131-0/+2
| | | | | | We now also generate nice wrappers for the platformConstants methods. For now it's all commented out as the definitions conflict with those in Constants.
* Add more modes to mkDerivedConstantsIan Lynagh2012-09-131-3/+10
| | | | We now generate a platformConstants file that we can read at runtime.
* remove $(GhcStage1DefaultNewCodegen) etc.Simon Marlow2012-09-051-12/+0
|
* Add "Unregisterised" as a field in the settings fileIan Lynagh2012-08-071-2/+0
| | | | | | To explicitly choose whether you want an unregisterised build you now need to use the "--enable-unregisterised"/"--disable-unregisterised" configure flags.
* More more ld-related settings into the settings fileIan Lynagh2012-08-051-6/+0
| | | | Related to #4862
View Lorry Controller Status