summaryrefslogtreecommitdiff
path: root/compiler/main
Commit message (Collapse)AuthorAgeFilesLines
...
* 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-295-101/+126
| | | | | | | | | | 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.
* Break up `Settings` into smaller structsJohn Ericson2019-05-297-190/+508
| | | | | | | | | | | | | | | | | As far as I can tell, the fields within `Settings` aren't *intrinsicly* related. They just happen to be initialized the same way (in particular prior to the rest of `DynFlags`), and that is why they are grouped together. Within `Settings`, however, there are groups of settings that clearly do share something in common, regardless of how they anything is initialized. In the spirit of GHC being a library, where the end cosumer may choose to initialize this configuration in arbitrary ways, I made some new data types for thoses groups internal to `Settings`, and used them to define `Settings` instead. Hopefully this is a baby step towards a general decoupling of the stateful and stateless parts of GHC.
* downsweep: Allow TargetFile not to exist when a buffer is givenDaniel Gröber2019-05-292-1/+6
| | | | | | | | | | 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-293-38/+43
| | | | | | | | | | | | | | | | | | 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.
* Allow for multiple linker instances. Fixes Haskell portion of #3372.Julian Leviston2019-05-213-54/+21
|
* Include CPP preprocessor dependencies in -M outputDavid Eichmann2019-05-212-1/+21
| | | | Issue #16521
* Guard CUSKs behind a language pragmaVladislav Zavialov2019-05-141-0/+3
| | | | | | | | | | | | | | GHC Proposal #36 describes a transition plan away from CUSKs and to top-level kind signatures: 1. Introduce a new extension, -XCUSKs, on by default, that detects CUSKs as they currently exist. 2. We turn off the -XCUSKs extension in a few releases and remove it sometime thereafter. This patch implements phase 1 of this plan, introducing a new language extension to control whether CUSKs are enabled. When top-level kind signatures are implemented, we can transition to phase 2.
* Remove all target-specific portions of Config.hsJohn Ericson2019-05-145-32/+87
| | | | | | | | | | | | | | | | | | | 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!
* Purge TargetPlatform_NAME and cTargetPlatformStringJohn Ericson2019-05-082-1/+4
|
* Implement ImportQualifiedPostShayne Fletcher2019-05-083-5/+11
|
* Enable external interpreter when TH is requested but no internal interpreter ↵Alp Mestanogullari2019-05-061-2/+9
| | | | is available
* Remove cGhcEnableTablesNextToCodeJohn Ericson2019-05-062-10/+12
| | | | Get "Tables next to code" from the settings file instead.
* Emit GHC timing events to eventlogBen Gamari2019-04-301-0/+2
|
* ErrUtils: Emit progress messages to eventlogBen Gamari2019-04-301-3/+5
|
* Move cGHC_UNLIT_PGM to be "unlit command" in settingsJohn Ericson2019-04-301-3/+3
| | | | | | | | | | | | The bulk of the work was done in #712, making settings be make/Hadrian controlled. This commit then just moves the unlit command rules in make/Hadrian from the `Config.hs` generator to the `settings` generator in each build system. I think this is a good change because the crucial benefit is *settings* don't affect the build: ghc gets one baby step closer to being a regular cabal executable, and make/Hadrian just maintains settings as part of bootstrapping.
* Show dynamic object files (#16062)erthalion2019-04-162-12/+28
| | | | | | | | | | | | | Closes #16062. When -dynamic-too is specified, reflect that in the progress message, like: $ ghc Main.hs -dynamic-too [1 of 1] Compiling Lib ( Main.hs, Main.o, Main.dyn_o ) instead of: $ ghc Main.hs -dynamic-too [1 of 1] Compiling Lib ( Main.hs, Main.o )
* Add -ddump-stg-final to dump stg as it is used for codegen.klebinger.andreas@gmx.at2019-04-122-0/+5
| | | | | Intermediate STG does not contain free variables which can be useful sometimes. So adding a flag to dump that info.
* removing x87 register support from native code genCarter Schonwald2019-04-101-8/+12
| | | | | | | | | | | | | | | | * simplifies registers to have GPR, Float and Double, by removing the SSE2 and X87 Constructors * makes -msse2 assumed/default for x86 platforms, fixing a long standing nondeterminism in rounding behavior in 32bit haskell code * removes the 80bit floating point representation from the supported float sizes * theres still 1 tiny bit of x87 support needed, for handling float and double return values in FFI calls wrt the C ABI on x86_32, but this one piece does not leak into the rest of NCG. * Lots of code thats not been touched in a long time got deleted as a consequence of all of this all in all, this change paves the way towards a lot of future further improvements in how GHC handles floating point computations, along with making the native code gen more accessible to a larger pool of contributors.
* GHC no longer ever defines TABLES_NEXT_TO_CODE on its ownJoachim Breitner2019-04-092-8/+2
| | | | | | | | | | | | | | | It should be entirely the responsibility of make/Hadrian to ensure that everything that needs this flag gets it. GHC shouldn't be hardcoded to assist with bootstrapping since it builds other things besides itself. Reviewers: Subscribers: TerrorJack, rwbarton, carter GHC Trac Issues: #15548 -- progress towards but not fix Differential Revision: https://phabricator.haskell.org/D5082 -- extract from that
* codegen: use newtype for Alignment in BasicTypesArtem Pyanykh2019-04-091-1/+5
|
* Add `-optcxx` option (#16477)Yuriy Syrovetskiy2019-04-087-20/+49
|
* Fix #16500: look for interface files in -hidir flag in OneShot modePhuong Trinh2019-04-081-2/+13
| | | | | | | | | | | We are currently ignoring options set in the hiDir field of hsc_dflags when looking for interface files while compiling in OneShot mode. This is inconsistent with the behaviour of other directory redirecting fields (such as objectDir or hieDir). It is also inconsistent with the behaviour of compilation in CompManager mode (a.k.a `ghc --make`) which looks for interface files in the directory set in hidir flag. This changes Finder.hs so that we use the value of hiDir while looking for interface in OneShot mode.
* Remove unnecessary uses of UnboxedTuples pragma (see #13101 / #15454)Michael Sloan2019-04-011-1/+1
| | | | Also removes a couple unnecessary MagicHash pragmas
* Visibility: handle multiple units with the same nameMichael Peyton Jones2019-03-291-13/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #16228. The included test case is adapted from the reproduction in the issue, and fails without this patch. ------ We compute an initial visilibity mapping for units based on what is present in the package databases. To seed this, we compute a set of all the package configs to add visibilities for. However, this set was keyed off the unit's *package name*. This is correct, since we compare packages across databases by version. However, we would only ever consider a single, most-preferable unit from the database in which it was found. The effect of this was that only one of the libraries in a Cabal package would be added to this initial set. This would cause attempts to use modules from the omitted libraries to fail, claiming that the package was hidden (even though `ghc-pkg` would correctly show it as visible). A solution is to do the selection of the most preferable packages separately, and then be sure to consider exposing all units in the same package in the same package db. We can do this by picking a most-preferable unit for each package name, and then considering exposing all units that are equi-preferable with that unit. ------ Why wasn't this bug apparent to all people trying to use sub-libraries in Cabal? The answer is that Cabal explicitly passes `-package` and `-package-id` flags for all the packages it wants to use, rather than relying on the state of the package database. So this bug only really affects people who are trying to use package databases produced by Cabal outside of Cabal itself. One particular example of this is the way that the Nixpkgs Haskell infrastructure provides wrapped GHCs: typically these are equipped with a package database containing all the needed package dependencies, and the user is not expected to pass `-package` flags explicitly.
* Update Wiki URLs to point to GitLabTakenobu Tani2019-03-254-6/+6
| | | | | | | | | | | | | | | | | | | | | | | This moves all URL references to Trac Wiki to their corresponding GitLab counterparts. This substitution is classified as follows: 1. Automated substitution using sed with Ben's mapping rule [1] Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy... New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy... 2. Manual substitution for URLs containing `#` index Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz 3. Manual substitution for strings starting with `Commentary` Old: Commentary/XxxYyy... New: commentary/xxx-yyy... See also !539 [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
* base: Remove `Monad(fail)` method and reexport `MonadFail(fail)` insteadHerbert Valerio Riedel2019-03-221-6/+6
| | | | | | As per https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail Coauthored-by: Ben Gamari <ben@well-typed.com>
* Simplify monadic codeKrzysztof Gogolewski2019-03-192-13/+10
|
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-1515-47/+47
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* compiler: Refactor: extract `withAtomicRename`Niklas Hambüchen2019-03-091-7/+6
|
* compiler: Write .o files atomically. See #14533Niklas Hambüchen2019-03-091-1/+6
| | | | | | | | | | | | | | | | | | | This issue was reproduced with, and the fix confirmed with, the `hatrace` tool for syscall-based fault injection: https://github.com/nh2/hatrace The concrete test case for GHC is at https://github.com/nh2/hatrace/blob/e23d35a2d2c79e8bf49e9e2266b3ff7094267f29/test/HatraceSpec.hs#L185 A previous, nondeterministic reproducer for the issue was provided by Alexey Kuleshevich in https://github.com/lehins/exec-kill-loop Signed-off-by: Niklas Hambüchen <niklas@fpcomplete.com> Reviewed-by: Alexey Kuleshevich <alexey@fpcomplete.com>
* Rip out object splittingBen Gamari2019-03-057-199/+26
| | | | | | | | | | | | | | | The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629
* Revert "compiler: Write .o files atomically. See #14533"Ben Gamari2019-03-041-6/+1
| | | | This reverts commit 0e2d300a59b1b5c167d2e7d99a448c8663ba6d7d.
* Revert "compiler: Refactor: extract `withAtomicRename`"Ben Gamari2019-03-041-6/+7
| | | | This reverts commit e8a08f400744a860d1366c6680c8419d30f7cc2a.
* Treat kind/type variables identically, demolish FKTVVladislav Zavialov2019-02-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst Fixes Trac #16334, Trac #16315 With this patch, scoping rules for type and kind variables have been unified: kind variables no longer receieve special treatment. This simplifies both the language and the implementation. User-facing changes ------------------- * Kind variables are no longer implicitly quantified when an explicit forall is used: p :: Proxy (a :: k) -- still accepted p :: forall k a. Proxy (a :: k) -- still accepted p :: forall a. Proxy (a :: k) -- no longer accepted In other words, now we adhere to the "forall-or-nothing" rule more strictly. Related function: RnTypes.rnImplicitBndrs * The -Wimplicit-kind-vars warning has been deprecated. * Kind variables are no longer implicitly quantified in constructor declarations: data T a = T1 (S (a :: k) | forall (b::k). T2 (S b) -- no longer accepted data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b) -- still accepted Related function: RnTypes.extractRdrKindSigVars * Implicitly quantified kind variables are no longer put in front of other variables: f :: Proxy (a :: k) -> Proxy (b :: j) f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b -- old order f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b -- new order This is a breaking change for users of TypeApplications. Note that we still respect the dpendency order: 'k' before 'a', 'j' before 'b'. See "Ordering of specified variables" in the User's Guide. Related function: RnTypes.rnImplicitBndrs * In type synonyms and type family equations, free variables on the RHS are no longer implicitly quantified unless used in an outermost kind annotation: type T = Just (Nothing :: Maybe a) -- no longer accepted type T = Just Nothing :: Maybe (Maybe a) -- still accepted The latter form is a workaround due to temporary lack of an explicit quantification method. Ideally, we would write something along these lines: type T @a = Just (Nothing :: Maybe a) Related function: RnTypes.extractHsTyRdrTyVarsKindVars * Named wildcards in kinds are fixed (Trac #16334): x :: (Int :: _t) -- this compiles, infers (_t ~ Type) Related function: RnTypes.partition_nwcs Implementation notes -------------------- * One of the key changes is the removal of FKTV in RnTypes: - data FreeKiTyVars = FKTV { fktv_kis :: [Located RdrName] - , fktv_tys :: [Located RdrName] } + type FreeKiTyVars = [Located RdrName] We used to keep track of type and kind variables separately, but now that they are on equal footing when it comes to scoping, we can put them in the same list. * extract_lty and family are no longer parametrized by TypeOrKind, as we now do not distinguish kind variables from type variables. * PatSynExPE and the related Note [Pattern synonym existentials do not scope] have been removed (Trac #16315). With no implicit kind quantification, we can no longer trigger the error. * reportFloatingKvs and the related Note [Free-floating kind vars] have been removed. With no implicit kind quantification, we can no longer trigger the error.
* Fix regression incorrectly advertising TH supportHerbert Valerio Riedel2019-02-231-0/+8
| | | | | | | | `--supported-languages` must only advertise language extensions which are supported by the compiler in order for tooling such as Cabal relying on this signalling not to behave incorrectly. Fixes #16331
* compiler: Refactor: extract `withAtomicRename`Niklas Hambüchen2019-02-211-7/+6
|
* compiler: Write .o files atomically. See #14533Niklas Hambüchen2019-02-211-1/+6
| | | | | | | | | | | | | | | | | | | This issue was reproduced with, and the fix confirmed with, the `hatrace` tool for syscall-based fault injection: https://github.com/nh2/hatrace The concrete test case for GHC is at https://github.com/nh2/hatrace/blob/e23d35a2d2c79e8bf49e9e2266b3ff7094267f29/test/HatraceSpec.hs#L185 A previous, nondeterministic reproducer for the issue was provided by Alexey Kuleshevich in https://github.com/lehins/exec-kill-loop Signed-off-by: Niklas Hambüchen <niklas@fpcomplete.com> Reviewed-by: Alexey Kuleshevich <alexey@fpcomplete.com>
* Fix warnings and fatal parsing errorsVladislav Zavialov2019-02-176-37/+49
|
* HIE: Save module name and module exportsMatthew Pickering2019-02-161-2/+3
|
* Make a smart mkAppTyMSimon Peyton Jones2019-02-142-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch finally delivers on Trac #15952. Specifically * Completely remove Note [The tcType invariant], along with its complicated consequences (IT1-IT6). * Replace Note [The well-kinded type invariant] with: Note [The Purely Kinded Type Invariant (PKTI)] * Instead, establish the (PKTI) in TcHsType.tcInferApps, by using a new function mkAppTyM when building a type application. See Note [mkAppTyM]. * As a result we can remove the delicate mkNakedXX functions entirely. Specifically, mkNakedCastTy retained lots of extremly delicate Refl coercions which just cluttered everything up, and(worse) were very vulnerable to being silently eliminated by (say) substTy. This led to a succession of bug reports. The result is noticeably simpler to explain, simpler to code, and Richard and I are much more confident that it is correct. It does not actually fix any bugs, but it brings us closer. E.g. I hoped it'd fix #15918 and #15799, but it doesn't quite do so. However, it makes it much easier to fix. I also did a raft of other minor refactorings: * Use tcTypeKind consistently in the type checker * Rename tcInstTyBinders to tcInvisibleTyBinders, and refactor it a bit * Refactor tcEqType, pickyEqType, tcEqTypeVis Simpler, probably more efficient. * Make zonkTcType zonk TcTyCons, at least if they have any free unification variables -- see zonk_tc_tycon in TcMType.zonkTcTypeMapper. Not zonking these TcTyCons was actually a bug before. * Simplify try_to_reduce_no_cache in TcFlatten (a lot) * Combine checkExpectedKind and checkExpectedKindX. And then combine the invisible-binder instantation code Much simpler now. * Fix a little bug in TcMType.skolemiseQuantifiedTyVar. I'm not sure how I came across this originally. * Fix a little bug in TyCoRep.isUnliftedRuntimeRep (the ASSERT was over-zealous). Again I'm not certain how I encountered this. * Add a missing solveLocalEqualities in TcHsType.tcHsPartialSigType. I came across this when trying to get level numbers right.
* Implement -Wredundant-record-wildcards and -Wunused-record-wildcardsMatthew Pickering2019-02-141-1/+7
| | | | | | | | | -Wredundant-record-wildcards warns when a .. pattern binds no variables. -Wunused-record-wildcards warns when none of the variables bound by a .. pattern are used. These flags are enabled by `-Wall`.
* NCG: fast compilation of very large strings (#16190)Sylvain Henry2019-02-141-0/+6
| | | | | | | | | | This patch adds an optimization into the NCG: for large strings (threshold configurable via -fbinary-blob-threshold=NNN flag), instead of printing `.asciz "..."` in the generated ASM source, we print `.incbin "tmpXXX.dat"` and we dump the contents of the string into a temporary "tmpXXX.dat" file. See the note for more details.
* Add `-fplugin-trustworthy` to avoid marking modules as unsafeZejun Wu2019-02-042-3/+8
| | | | | | | | By default, when a module is compiled with plugins, it will be marked as unsafe. With this flag passed, all plugins are treated as trustworthy and the safety inference will no longer be affected. This fixes Trac #16260.
* Fix #16219: TemplateHaskell causes indefinite package build errorEdward Z. Yang2019-01-312-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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-312-2/+39
| | | | | | | | | | | | | 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.
View Lorry Controller Status