summaryrefslogtreecommitdiff
path: root/compiler/main/GhcMake.hs
Commit message (Collapse)AuthorAgeFilesLines
* Modules: Driver (#13009)Sylvain Henry2020-02-211-2739/+0
| | | | submodule updates: nofib, haddock
* If a :reload finds syntax errors in the module graph, remove the loaded ↵Roland Senn2020-02-181-18/+34
| | | | | | | | | | modules. (Fixes #17549) The processing in `compiler/main/GhcMake.hs` computes the ModuleGraph. If it finds errors in the module header or in the import specifications, then the new module graph is incomplete and should not be used. The code before #17549 just reported the errors and left the old ModuleGraph in place. The new code of this MR replaces the old ModuleGraph with an empty one.
* Module hierarchy: ByteCode and Runtime (cf #13009)Sylvain Henry2020-02-121-1/+1
| | | | Update haddock submodule
* Refactor package related codeSylvain Henry2020-01-311-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The package terminology is a bit of a mess. Cabal packages contain components. Instances of these components when built with some flags/options/dependencies are called units. Units are registered into package databases and their metadata are called PackageConfig. GHC only knows about package databases containing units. It is a sad mismatch not fixed by this patch (we would have to rename parameters such as `package-id <unit-id>` which would affect users). This patch however fixes the following internal names: - Renames PackageConfig into UnitInfo. - Rename systemPackageConfig into globalPackageDatabase[Path] - Rename PkgConfXX into PkgDbXX - Rename pkgIdMap into unitIdMap - Rename ModuleToPkgDbAll into ModuleNameProvidersMap - Rename lookupPackage into lookupUnit - Add comments on DynFlags package related fields It also introduces a new `PackageDatabase` datatype instead of explicitly passing the following tuple: `(FilePath,[PackageConfig])`. The `pkgDatabase` field in `DynFlags` now contains the unit info for each unit of each package database exactly as they have been read from disk. Previously the command-line flag `-distrust-all-packages` would modify these unit info. Now this flag only affects the "dynamic" consolidated package state found in `pkgState` field. It makes sense because `initPackages` could be called first with this `distrust-all-packages` flag set and then again (using ghc-api) without and it should work (package databases are not read again from disk when `initPackages` is called the second time). Bump haddock submodule
* Disable two warnings for files that trigger themTom Ellis2020-01-271-0/+2
| | | | | | incomplete-uni-patterns and incomplete-record-updates will be in -Wall at a future date, so prepare for that by disabling those warnings on files that trigger them.
* Fix more typos, via an improved Levenshtein-style correctorBrian Wignall2020-01-121-3/+3
|
* Module hierarchy: Iface (cf #13009)Sylvain Henry2020-01-061-2/+2
|
* Fix typos, using Wikipedia list of common typosBrian Wignall2019-11-281-1/+1
|
* Make dynflag argument for withTiming pure.Andreas Klebinger2019-10-231-1/+1
| | | | | | | | | | | | 19 times out of 20 we already have dynflags in scope. We could just always use `return dflags`. But this is in fact not free. When looking at some STG code I noticed that we always allocate a closure for this expression in the heap. Clearly a waste in these cases. For the other cases we can either just modify the callsite to get dynflags or use the _D variants of withTiming I added which will use getDynFlags under the hood.
* Make -fbyte-code prevent unboxed tuples/sums from implying object code (#16876)Ryan Scott2019-09-261-5/+8
| | | | | | | | | | | | | | | | | | | | 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.
* Add -fkeep-going to make compiler continue despite errors (#15424)Kari Pahula2019-09-231-3/+36
| | | | | Add a new optional failure handling for upsweep which continues the compilation on other modules if any of them has errors.
* Allow reusing temporary object files generated by GHCi by writing to -odir ↵nineonine2019-07-111-5/+7
| | | | in case -fwrite-interface was specified (#16670)
* Fix #16511: changes in interface dependencies should trigger recompilationPhuong Trinh2019-07-091-22/+0
| | | | | | | If the union of dependencies of imported modules change, the `mi_deps` field of the interface files should change as well. Because of that, we need to check for changes in this in recompilation checker which we are not doing right now. This adds a checks for that.
* Fix #16805 by formatting warning messagenineonine2019-06-271-6/+6
|
* Warn about unused packagesYuras Shumovich2019-06-111-1/+69
| | | | | | | | | | | | Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: hvr, simonpj, mpickering, rwbarton, carter GHC Trac Issues: #15838 Differential Revision: https://phabricator.haskell.org/D5285
* Improve targetContents code docsDaniel Gröber2019-05-301-0/+1
|
* Add depanalPartial to make getting a partial modgraph easierDaniel Gröber2019-05-301-10/+32
| | | | | | As per @mpickering's suggestion on IRC this is to make the partial module-graph more easily accessible for API clients which don't intend to re-implementing depanal.
* Catch preprocessor errors in downsweepDaniel Gröber2019-05-301-15/+2
| | | | | | | | | | | | | | | | This changes the way preprocessor failures are presented to the user. Previously the user would simply get an unlocated message on stderr such as: `gcc' failed in phase `C pre-processor'. (Exit code: 1) Now at the problematic source file is mentioned: A.hs:1:1: error: `gcc' failed in phase `C pre-processor'. (Exit code: 1) This also makes live easier for GHC API clients as the preprocessor error is now thrown as a SourceError exception.
* Make downsweep return all errors per-module instead of throwing someDaniel Gröber2019-05-301-13/+13
| | | | | | | | This enables API clients to handle such errors instead of immideately crashing in the face of some kinds of user errors, which is arguably quite bad UX. Fixes #10887
* Refactor summarise{File,Module} to extract checkSummaryTimestampDaniel Gröber2019-05-301-47/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces a slight change of behaviour in the interrest of keeping the code simple: Previously summariseModule would not call addHomeModuleToFinder for summaries that are being re-used but now we do. We're forced to to do this in summariseFile because the file being summarised might not even be on the regular search path! So if GHC is to find it at all we have to pre-populate the cache with its location. For modules however the finder cache is really just a cache so we don't have to pre-populate it with the module's location. As straightforward as that seems I did almost manage to introduce a bug (or so I thought) because the call to addHomeModuleToFinder I copied from summariseFile used to use `ms_location old_summary` instead of the `location` argument to checkSummaryTimestamp. If this call were to overwrite the existing entry in the cache that would have resulted in us using the old location of any module even if it was, say, moved to a different directory between calls to 'depanal'. However it turns out the cache just ignores the location if the module is already in the cache. Since summariseModule has to search for the module, which has the side effect of populating the cache, everything would have been fine either way. Well I'm adding a test for this anyways: tests/depanal/OldModLocation.hs.
* Refactor summarise{File,Module} to reduce code duplicationDaniel Gröber2019-05-301-84/+123
|
* Refactor downsweep to allow returning multiple errors per moduleDaniel Gröber2019-05-301-28/+26
|
* Export GhcMake.downsweepDaniel Gröber2019-05-301-0/+2
| | | | | This is to enable #10887 as well as to make it possible to test downsweep on its own in the testsuite.
* Inline `Settings` into `DynFlags`John Ericson2019-05-291-2/+2
| | | | | | | | | | After the previous commit, `Settings` is just a thin wrapper around other groups of settings. While `Settings` is used by GHC-the-executable to initalize `DynFlags`, in principle another consumer of GHC-the-library could initialize `DynFlags` a different way. It therefore doesn't make sense for `DynFlags` itself (library code) to separate the settings that typically come from `Settings` from the settings that typically don't.
* downsweep: Allow TargetFile not to exist when a buffer is givenDaniel Gröber2019-05-291-1/+1
| | | | | | | | | | Currently 'getRootSummary' will fail with an exception if a 'TargetFile' is given but it does not exist even if an input buffer is passed along for this target. In this case it is not necessary for the file to exist since the buffer will be used as input for the compilation pipeline instead of the file anyways.
* Allow using tagetContents for modules needing preprocessingDaniel Gröber2019-05-291-25/+3
| | | | | | | | | | | | | | | | | | This allows GHC API clients, most notably tooling such as Haskell-IDE-Engine, to pass unsaved files to GHC more easily. Currently when targetContents is used but the module requires preprocessing 'preprocessFile' simply throws an error because the pipeline does not support passing a buffer. This change extends `runPipeline` to allow passing the input buffer into the pipeline. Before proceeding with the actual pipeline loop the input buffer is immediately written out to a new tempfile. I briefly considered refactoring the pipeline at large to pass around in-memory buffers instead of files, but this seems needlessly complicated since no pipeline stages other than Hsc could really support this at the moment.
* Handle hs-boot files in -Wmissing-home-modules (#16551)Krzysztof Gogolewski2019-05-291-0/+4
|
* Have GHCi use object code for UnboxedTuples modules #15454Michael Sloan2019-05-221-10/+55
| | | | | | | | | | | | The idea is to automatically enable -fobject-code for modules that use UnboxedTuples, along with all the modules they depend on. When looking into how to solve this, I was pleased to find that there was already highly similar logic for enabling code generation when -fno-code is specified but TemplateHaskell is used. The state before this patch was that if you used unboxed tuples then you had to enable `-fobject-code` globally rather than on a per module basis.
* Remove all target-specific portions of Config.hsJohn Ericson2019-05-141-1/+1
| | | | | | | | | | | | | | | | | | | 1. If GHC is to be multi-target, these cannot be baked in at compile time. 2. Compile-time flags have a higher maintenance than run-time flags. 3. The old way makes build system implementation (various bootstrapping details) with the thing being built. E.g. GHC doesn't need to care about which integer library *will* be used---this is purely a crutch so the build system doesn't need to pass flags later when using that library. 4. Experience with cross compilation in Nixpkgs has shown things work nicer when compiler's can *optionally* delegate the bootstrapping the package manager. The package manager knows the entire end-goal build plan, and thus can make top-down decisions on bootstrapping. GHC can just worry about GHC, not even core library like base and ghc-prim!
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-151-4/+4
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Fix #16219: TemplateHaskell causes indefinite package build errorEdward Z. Yang2019-01-311-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | It should work to write an indefinite package using TemplateHaskell, so long as all of the actual TH code lives outside of the package. However, cleverness we had to build TH code even when building with -fno-code meant that we attempted to build object code for modules in an indefinite package, even when the signatures were not instantiated. This patch disables said logic in the event that an indefinite package is being typechecked. Signed-off-by: Edward Z. Yang <ezyang@fb.com> Test Plan: validate Reviewers: simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #16219 Differential Revision: https://phabricator.haskell.org/D5475
* Add -fdefer-diagnostics to defer and group diagnostic messages in make-modeZejun Wu2019-01-311-2/+37
| | | | | | | | | | | | | When loading many modules in parallel there can a lot of warnings and errors get mixed up with regular output. When the compilation fails, the relevant error message can be thousands of lines backward and is hard to find. When the compilation successes, warning message is likely to be ignored as it is not seen. We can address this by deferring the warning and error message after the compilation. We also put errors after warnings so it is more visible. This idea was originally proposed by Bartosz Nitka in https://phabricator.haskell.org/D4219.
* Remove an old OPTIONS_GHCÖmer Sinan Ağacan2018-12-201-4/+0
|
* Support generating HIE filesAlec Theriault2018-12-111-2/+11
| | | | | | | | | | | | | | | | | | | | Adds a `-fenable-ide-info` flag which instructs GHC to generate `.hie` files (see the wiki page: https://ghc.haskell.org/trac/ghc/wiki/HIEFiles). This is a rebased version of Zubin Duggal's (@wz1000) GHC changes for his GSOC project, as posted here: https://gist.github.com/wz1000/5ed4ddd0d3e96d6bc75e095cef95363d. Test Plan: ./validate Reviewers: bgamari, gershomb, nomeata, alanz, sjakobi Reviewed By: alanz, sjakobi Subscribers: alanz, hvr, sjakobi, rwbarton, wz1000, carter Differential Revision: https://phabricator.haskell.org/D5239
* Replace most occurences of foldl with foldl'.klebinger.andreas@gmx.at2018-08-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds foldl' to GhcPrelude and changes must occurences of foldl to foldl'. This leads to better performance especially for quick builds where GHC does not perform strictness analysis. It does change strictness behaviour when we use foldl' to turn a argument list into function applications. But this is only a drawback if code looks ONLY at the last argument but not at the first. And as the benchmarks show leads to fewer allocations in practice at O2. Compiler performance for Nofib: O2 Allocations: -1 s.d. ----- -0.0% +1 s.d. ----- -0.0% Average ----- -0.0% O2 Compile Time: -1 s.d. ----- -2.8% +1 s.d. ----- +1.3% Average ----- -0.8% O0 Allocations: -1 s.d. ----- -0.2% +1 s.d. ----- -0.1% Average ----- -0.2% Test Plan: ci Reviewers: goldfire, bgamari, simonmar, tdammers, monoidal Reviewed By: bgamari, monoidal Subscribers: tdammers, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4929
* Improve missing-home-modules warning formattingMatthew Pickering2018-03-021-4/+9
| | | | | | | | | | | | | | | | | | | | | | | Previously the modules were smashed together at the end of the line. As the header is quite long, this meant for quite long lines which wrapped on smaller terminals. err msg: A B Now they are nested underneath the long first line of the error message. err msg: A B Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4454
* compiler: introduce custom "GhcPrelude" PreludeHerbert Valerio Riedel2017-09-191-0/+2
| | | | | | | | | | | | | | | | | | This switches the compiler/ component to get compiled with -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all modules. This is motivated by the upcoming "Prelude" re-export of `Semigroup((<>))` which would cause lots of name clashes in every modulewhich imports also `Outputable` Reviewers: austin, goldfire, bgamari, alanz, simonmar Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari Differential Revision: https://phabricator.haskell.org/D3989
* Fix incorrect retypecheck loop in -j (#14075)Edward Z. Yang2017-08-221-2/+48
| | | | | | | | | | | | | | | | | | | | | | | | The parallel codepath was incorrectly retypechecking the hs-boot ModIface prior to typechecking the hs file, which was inconsistent with the non-parallel case. The non-parallel case gets it right: you don't want to retypecheck the hs-boot file itself (forwarding its declarations to hs) because you need it to be consistently knot-tied with itself when you compare the interfaces. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, simonpj, austin Reviewed By: bgamari Subscribers: duog, rwbarton, thomie GHC Trac Issues: #14075 Differential Revision: https://phabricator.haskell.org/D3815
* Make module membership on ModuleGraph fasterBartosz Nitka2017-07-181-24/+49
| | | | | | | | | | | | | | | | | | | When loading/reloading with a large number of modules (>5000) the cost of linear lookups becomes significant. The changes here made `:reload` go from 6s to 1s on my test case. The bottlenecks were `needsLinker` in `DriverPipeline` and `getModLoop` in `GhcMake`. Test Plan: ./validate Reviewers: simonmar, austin, bgamari Subscribers: thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D3703
* Fix logic error in GhcMake.enableCodeGenForTHDouglas Wilson2017-07-111-16/+21
| | | | | | | | | | | | | | | | | | | | | transitive_deps_set was incorrect, it was not considering the dependencies of dependencies in some cases. I've corrected it and tidied it up a little. The test case from leftaroundabout, as linked to from the ticket, is added with small modifications to flatten directory structure. Test Plan: make test TEST=T13949 Reviewers: austin, bgamari, alexbiehl Reviewed By: alexbiehl Subscribers: rwbarton, thomie, alexbiehl GHC Trac Issues: #13949 Differential Revision: https://phabricator.haskell.org/D3720
* Improve Wmissing-home-modules warning under CabalBen Gamari2017-07-111-1/+6
| | | | | | | | | | | | Reviewers: hvr, alanz, austin Reviewed By: alanz Subscribers: rwbarton, thomie GHC Trac Issues: #13899 Differential Revision: https://phabricator.haskell.org/D3686
* Fix -fno-code for modules that use -XQuasiQuotesDouglas Wilson2017-07-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | In commit 53c78be0aab76a3107c4dacbb1d177afacdd37fa object code is generated for modules depended on by modules that use -XTemplateHaskell. This turns the same logic on for modules that use -XQuasiQuotes. A test is added. Note that I've based this of D3646, as it has a function I want to use. Test Plan: ./validate Reviewers: austin, bgamari, alexbiehl Reviewed By: alexbiehl Subscribers: alexbiehl, rwbarton, thomie GHC Trac Issues: #13863 Differential Revision: https://phabricator.haskell.org/D3677
* Revert "Make module membership on ModuleGraph faster"Ben Gamari2017-06-271-34/+20
| | | | | | I had not intended on merging this. This reverts commit b0708588e87554899c2efc80a2d3eba353dbe926.
* Make module membership on ModuleGraph fasterBartosz Nitka2017-06-271-20/+34
| | | | | | | | | | | | | | | | | | | When loading/reloading with a large number of modules (>5000) the cost of linear lookups becomes significant. The changes here made `:reload` go from 6s to 1s on my test case. The bottlenecks were `needsLinker` in `DriverPipeline` and `getModLoop` in `GhcMake`. Test Plan: ./validate Reviewers: simonmar, austin, bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3646
* Refactor temp files cleanupDouglas Wilson2017-06-081-44/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove filesToNotIntermediateClean from DynFlags, create a data type FilesToClean, and change filesToClean in DynFlags to be a FilesToClean. Modify SysTools.newTempName and the Temporary constructor of PipelineMonad.PipelineOutput to take a TempFileLifetime, which specifies whether a temp file should live until the end of GhcMonad.withSession, or until the next time cleanIntermediateTempFiles is called. These changes allow the cleaning of intermediate files in GhcMake to be much more efficient. HscTypes.hptObjs is removed as it is no longer used. A new performance test T13701 is added, which passes both with and without -keep-tmp-files. The test fails by 25% without the patch, and passes when -keep-tmp-files is added. Note that there are still at two hotspots caused by algorithms quadratic in the number of modules, however neither of them allocate. They are: * DriverPipeline.compileOne'.needsLinker * GhcMake.getModLoop DriverPipeline.compileOne'.needsLinker is changed slightly to improve the situation. I don't like adding these Types to DynFlags, but they need to be seen by Dynflags, SysTools and PipelineMonad. The alternative seems to be to create a new module. Reviewers: austin, hvr, bgamari, dfeuer, niteria, simonmar, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #13701 Differential Revision: https://phabricator.haskell.org/D3620
* Efficient checks for stable modulesBartosz Nitka2017-05-301-19/+37
| | | | | | | | | | | | | | | | | | | | | | With a large number of modules in a home package (in my case 5000) the costs of linear lookups becomes significant. This changes them to efficient IntMap lookups. It reduces the cost of `:reload` on unchanged source from 5.77s to 1.62s on my test case. I could go further and make `Linker.unload` also take a set, but I prefer to concentrate on one thing at a time. Test Plan: harbormaster Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3611
* Handle file targets in missing home modules warningHerbert Valerio Riedel2017-05-221-10/+28
| | | | | | | | | | | | | | | When main module is listed on command line as a file, we should not issue a warning about it. See Trac #13727 Reviewers: austin, bgamari, Yuras Reviewed By: bgamari, Yuras Subscribers: 23Skidoo, rwbarton, thomie GHC Trac Issues: #13727 Differential Revision: https://phabricator.haskell.org/D3598
* Compile modules that are needed by template haskell, even with -fno-code.Douglas Wilson2017-05-201-17/+165
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch relates to Trac #8025 The goal here is to enable typechecking of packages that contain some template haskell. Prior to this patch, compilation of a package with -fno-code would fail if any functions in the package were called from within a splice. downsweep is changed to do an additional pass over the modules, targetting any ModSummaries transitively depended on by a module that has LangExt.TemplateHaskell enabled. Those targeted modules have hscTarget changed from HscNothing to the default target of the platform. There is a small change to the prevailing_target logic to enable this. A simple test is added. I have benchmarked with and without a patched haddock (available:https://github.com/duog/haddock/tree/wip-no-explicit-th-compi lation). Running cabal haddock on the wreq package results in a 25% speedup on my machine: time output from patched cabal haddock: real 0m5.780s user 0m5.304s sys 0m0.496s time output from unpatched cabal haddock: real 0m7.712s user 0m6.888s sys 0m0.736s Reviewers: austin, bgamari, ezyang Reviewed By: bgamari Subscribers: bgamari, DanielG, rwbarton, thomie GHC Trac Issues: #8025 Differential Revision: https://phabricator.haskell.org/D3441
* Fix a performance bug in GhcMake.downsweepSimon Marlow2017-05-101-5/+12
| | | | | | | | | | | | | | | | | | | | Every time we encountered a non-home module during the downsweep, we were removing it from the finder cache. That meant we were searching the filesystem for every import, rather than once per downsweep. The fix is just to flush the finder cache before the downsweep, and repopulate it for home modules that haven't changed. Speeds up downsweep by about 25% on a large example I have. Test Plan: Harbourmaster Reviewers: bgamari, niteria, austin, erikd Reviewed By: bgamari, niteria Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3554
* Efficient membership for home modulesBartosz Nitka2017-05-101-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | This changes the linear lookup in a list to an efficient lookup in an IntMap. The linear lookup effectively made the algorithm quadratic, which for a test case that I have (5000 modules) introduced significant slowdown. I ran 3 experiments to estimate the impact of this: "No-op", profiled, just `:load`: P146, `186s` "before", profiled, `:load` followed by 10x `:r`: P147, `315s` "after", profiled, `:load` followed by 10x `:r`: P148, `250s` Going by the math of `(250-186)/(315-186) = 50%` this is a 2x improvement on `:r`. Test Plan: ./validate Reviewers: simonmar, austin, bgamari Reviewed By: simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3562
View Lorry Controller Status