summaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
* mkGadtDecl no longer in P monadJan Stolarek2015-11-112-12/+10
| | | | | | | | | | | | | | | | Since `mkGadtDecl` does not use any of the functions specific to the `P` monad we can extract it from that monad and reuse in other parts of the compiler. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1461
* nativeGen.PPC: Fix shift arith. right > 31 bitsPeter Trommler2015-11-111-3/+8
| | | | | | | | | | | | | | | | | | | | | Arithmetic right shifts of more than 31 bits set all bits to the sign bit on PowerPC. iThe assembler does not allow shift amounts larger than 32 so do an arithemetic right shift of 31 bit instead. Fixes #10870 Test Plan: validate (especially on powerpc) Reviewers: austin, erikd, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1459 GHC Trac Issues: #10870
* Detect invalid foreign imports in bytecode compilerSylvain HENRY2015-11-111-8/+23
| | | | | | | | | | | | | | | | | | | | The bytecode compiler doesn't handle every foreign import calling convention. Instead of crashing during the generation of the foreign call, we display an error. Fix lint warnings Test Plan: prog014 ghci test added Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1458 GHC Trac Issues: #10462
* Put kind variables before type variables when specializingBartosz Nitka2015-11-111-5/+6
| | | | | | | | | | | | | | | | | | | | | | | When you reverse the order of uniques you get the core lint error from the testcase. The testcase is copied from tests/simplCore/should_compile/T10689a.hs. The problem is that we would put type and kind variables ordered by unique order, which happened to be the right order for this testcase to pass under normal conditions. I think it's enough to sort them with `sortQuantVars`, but I'm not really sure if some more sophisticated dependency analysis isn't needed. Test Plan: added a new testcase Reviewers: simonpj, goldfire, simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1457
* Systools: read ELF section without calling readelfSylvain HENRY2015-11-114-62/+501
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch tackles two issues: 1) GHC stores a "link info" string into a ELF section. Initially a section with type "note" was used but GHC didn't follow the ELF specification which specifies a record-based format for these sections. With D1375 we switched to a "progbits" section type for which there isn't any format constraint. This is an issue for D1242 which use GCC's --gc-sections which collects "unused" sections, such as our section containing link info... In this patch, we fall back to a section with type "note" but we respect the specified format. 2) Reading back the ELF section was done by parsing the result of a call to "readelf". Calling readelf is problematic because the program may not be available or it may be renamed on some platforms (see D1326). Moreover we have no garanty that its output layout will stay the same in future releases of readelf. Finally we would need to fix the parsing to support "note" sections because of 1. Instead, this patch proposes to use Data.Binary.Get to directly read the "link info" note into its section. ELF has a specification, hence it should work on every conforming platform. This patch "reverts" D1375, hence it supersedes D1432. It makes D1326 not necessary anymore. Test Plan: - recomp011 should pass (test that relinking is avoided when both "link info" match) - we should add a test for ELF objects with more than 0xff00 sections => added test "recomp015" - we should check that GAS generates 32-bit words with .int on every supported platform using ELF (or find a place where this is documented). harbomaster and I (@hsyl20) only tested on x86-64. On platforms where it is not true, it should make recomp011 fail. => tested to work on Linux/amd64, Solaris/i386 and OpenBSD/amd64 Reviewers: olsner, ony, thomie, kgardas, austin, bgamari Reviewed By: thomie, bgamari Subscribers: kgardas, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1381 GHC Trac Issues: #10974, #11022
* Remove fun_infix from Funbind, as it is now in MatchAlan Zimmerman2015-11-1116-93/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the changes D538 introduced is to add `m_fun_id_infix` to `Match` ```lang=hs data Match id body = Match { m_fun_id_infix :: (Maybe (Located id,Bool)), -- fun_id and fun_infix for functions with multiple equations -- only present for a RdrName. See note [fun_id in Match] m_pats :: [LPat id], -- The patterns m_type :: (Maybe (LHsType id)), -- A type signature for the result of the match -- Nothing after typechecking m_grhss :: (GRHSs id body) } deriving (Typeable) ``` This was done to track the individual locations and fixity of the `fun_id` for each of the defining equations for a function when there are more than one. For example, the function `(&&&)` is defined with some prefix and some infix equations below. ```lang=hs (&&& ) [] [] = [] xs &&& [] = xs ( &&& ) [] ys = ys ``` This means that the fun_infix is now superfluous in the `FunBind`. This has not been removed as a potentially risky change just before 7.10 RC2, and so must be done after. This ticket captures that task, which includes processing these fields through the renamer and beyond. Ticket #9988 introduced these fields into `Match` through renaming, this ticket it to continue through type checking and then remove it from `FunBind` completely. The split happened so that #9988 could land in 7.10 Trac ticket : #10061 Test Plan: ./validate Reviewers: goldfire, austin, simonpj, bgamari Reviewed By: bgamari Subscribers: simonpj, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1285 GHC Trac Issues: #10061
* Remove unused field in ConDeclJan Stolarek2015-11-113-19/+3
| | | | | | | | | | | | | | | | | We no longer parse old-style GADT syntax but there was some left-over code for emitting deprecation warnings. Updates haddock submodule. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1460
* OPTIONS_GHC compiler flags may contain spaces (#4931)Thomas Miedema2015-11-112-16/+30
| | | | | | | | | | | | | | | | | | | When a .hsc contains `#define FOO "bar baz"`, hsc2hs emits: {-# OPTIONS_GHC -optc-DFOO="bar baz" #-} Make sure GHC can compile this, by tweaking `HeaderInfo.getOptions` a bit. Test Plan: driver/T4931 Reviewers: austin, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1452 GHC Trac Issues: #4931
* Associate pattern synonyms with types in module exportsMatthew Pickering2015-11-1117-94/+408
| | | | | | | | | | | | | | | | | | | | | | This patch implements #10653. It adds the ability to bundle pattern synonyms with type constructors in export lists so that users can treat pattern synonyms more like data constructors. Updates haddock submodule. Test Plan: ./validate Reviewers: goldfire, austin, bgamari Reviewed By: bgamari Subscribers: simonpj, gridaphobe, thomie Differential Revision: https://phabricator.haskell.org/D1258 GHC Trac Issues: #10653
* Abstract TFs can have injectivity informationJan Stolarek2015-11-091-4/+3
| | | | | | | | | | | | | | | | Summary: For abstract type families we incorrectly rejected their injectivity annotation. Fixes #11007. Test Plan: #6018 Reviewers: goldfire, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1453 GHC Trac Issues: #11007
* Quote file paths in linker scriptsBen Gamari2015-11-081-1/+1
| | | | | | | | | | | | Reviewers: bgamari, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1442 GHC Trac Issues: #11063
* Add pprSTrace for debugging with call stacksBartosz Nitka2015-11-081-1/+15
| | | | | | | | | | | | | | | | | I've spent quite a bit of time giving unique labels to my `pprTrace` calls and then trying to intuit where the function is called from. Thanks to the new implicit parameter CallStack functionality I don't have to do that anymore. Test Plan: harbormaster Reviewers: austin, simonmar, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1440
* Replace freeVarsOf scrut with scrut_fvs to avoid repetitionBartosz Nitka2015-11-081-1/+1
| | | | | | | | | | | | Test Plan: harbormaster Reviewers: bgamari, simonmar, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1439
* minor: use unless instead of (when . not)Ömer Sinan Ağacan2015-11-081-3/+3
| | | | | | | | | | Reviewers: bgamari, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1438
* Parser: allow empty multi-line deprecation warningsThomas Miedema2015-11-081-0/+1
| | | | | | | | | | | | | | | | | | This should work, {-# DEPRECATED someFunction [] #-} Test Plan: parser/should_compile/T3303 Reviewers: bgamari, austin Reviewed By: austin Subscribers: mpickering Differential Revision: https://phabricator.haskell.org/D1433 GHC Trac Issues: #11044
* Remove PatSynBuilderIdMatthew Pickering2015-11-0713-38/+30
| | | | | | | | | | | | | | | | | Summary: It was only used to pass field labels between the typechecker and desugarer. Instead we add an extra field the RecordCon to carry this information. Reviewers: austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1443 GHC Trac Issues: #11057
* Allow the GHCi Linker to resolve related dependencies when loading DLLsTamar Christina2015-11-072-53/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: GHCi does not correctly tell the Windows Loader how to handle dependencies to DLL's that are not on the standard Windows load path: 1. The directory from which the application loaded. 2. The current directory. 3. The system directory. Use the GetSystemDirectory function to get the path of this directory. 4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. 5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory. 6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the AppPaths registry key. The App Paths key is not used when computing the DLL search path. So what this means is given two DLLs `A` and `B` and `B` depending on `A`. If we put both DLLs into a new folder bin and then call GHC with: `ghc -L$(PWD)/bin -lB` the loading will fail as the Windows loader will try to load the dependency of `B` and fail since it cannot find `A`. *IMPORTANT* this patch drops XP Support. The APIs being used were natively added to Windows 8+ and backported to Windows 7 and Vista via a mandatory security patch (in 2011). This means that there is a chance that KB2533623 has not been installed on certain machines. For those machines I display a warning and temporarily expand the `PATH` to allow it to load. This patch will make sure that paths provided by the user with `-L` *and* the folder in which a DLL is found are added to the search path. It does so using one of two methods depending upon how new of a Windows version we are running on: - If the APIs are available it will use `addDllDirectory` and `removeDllDirectory`. The order of which these directories are searched is nondeterministic. - If the APIs are not available it means that we're running on a pretty old unpatched machine. But if it's being used in an environment with no internet access it may be the case. So if the APIs are not available we temporarily extend the `PATH` with the directories. A warning is also displayed to the user informing them that the linking may fail, and if it does, install the needed patch. The `PATH` variable has limitations. Test Plan: ./validate Added two new test T10955 and T10955dyn Reviewers: erikd, bgamari, thomie, hvr, austin Reviewed By: erikd, thomie Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1340 GHC Trac Issues: #10955
* Make GHCi & TH work when the compiler is built with -profSimon Marlow2015-11-077-62/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Amazingly, there were zero changes to the byte code generator and very few changes to the interpreter - mainly because we've used good abstractions that hide the differences between profiling and non-profiling. So that bit was pleasantly straightforward, but there were a pile of other wibbles to get the whole test suite through. Note that a compiler built with -prof is now like one built with -dynamic, in that to use TH you have to build the code the same way. For dynamic, we automatically enable -dynamic-too when TH is required, but we don't have anything equivalent for profiling, so you have to explicitly use -prof when building code that uses TH with a profiled compiler. For this reason Cabal won't work with TH. We don't expect to ship a profiled compiler, so I think that's OK. Test Plan: validate with GhcProfiled=YES in validate.mk Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang Reviewed By: ezyang Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1407 GHC Trac Issues: #4837, #545
* Call Arity: In "e x", the result of "x" is not sharedJoachim Breitner2015-11-061-5/+15
| | | | | | | | | | | | | | | | | | | | in contrast to "e (f x)", where CorePrep will turn it into "let y = f x in e x". So in let f = ... in e (f x) we know that f is called at most once, but in let f = ... in e f we do not know that. Previously Call Arity would assume that in "e x", "x" is evaluated at most once. This rarely would make a difference (the argument "x" is analized with an incoming arity of 0, so no eta-expansion would be done anyways), but of course this should still be fixed. This fixes #11064. Note the corresponding code dmdTransformThunkDmd in DmdAnal.
* Use full name of LLVM program in error messageErik de Castro Lopo2015-11-041-1/+1
| | | | | | | | | | | | Previously something like `/usr/bin/opt-3.7` was being shortened to `opt-3` using the `takeBaseName` function. This shortened form is actually not correct. We should use `takeFileName` instead. Reviewers: bgamari, austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1420
* Update process submodule to process-1.4 releaseHerbert Valerio Riedel2015-11-021-1/+1
| | | | | We already used a process-1.4 snapshot with non-bumped version, so this commit is mostly a `.cabal` file upper-bound relaxation change.
* Minor simplification in unariser pass:Ömer Sinan Ağacan2015-11-011-13/+11
| | | | | | | | | | | | | | | | | We don't need to update StgCase's AltType, because it's already set correctly in `CoreToStg.mkStgAltType`, so we can just remove extra argument passing and return values. (I think this is a useful refactoring because it makes it clear that we don't need to update AltTypes) Reviewers: austin, bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1403
* Dwarf.Constants: Introduce Haddock sectionsBen Gamari2015-11-011-8/+8
|
* cmm: Expose machine's stack and return address registerBen Gamari2015-11-016-1/+26
| | | | | | | | | | We will need to use these to setup proper unwinding information for the stg_stop_thread closure. This pokes a hole in the STG abstraction, exposing the machine's stack pointer register so that we can accomplish this. We also expose a dummy return address register, which corresponds to the register used to hold the DWARF return address. Differential Revision: https://phabricator.haskell.org/D1225
* Dwarf.Types: Fix comment styleBen Gamari2015-11-011-5/+5
|
* Dwarf: Preserve stack pointer registerBen Gamari2015-11-011-1/+11
| | | | | | | | | | | | | | | | | Here we add a `same_value $sp` instruction to our default unwinding rules to ensure that the implicit `$sp = CFA` rule (which `libdw` appears to exhibit on x86_64) doesn't overwrite it (necessary since we don't use $sp to track our call stack). See Phab Diff D1189 for details on how we arrived at this resolution. Reviewers: scpmw, austin, simonmar Reviewed By: austin, simonmar Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D1224
* DynFlags: -freverse-errors should be defFlagBen Gamari2015-11-011-2/+2
| | | | | This flag works under both GHC and GHCi, as pointed out on D1367. Thanks to @thomie for pointing this out.
* keepCAFsForGHCi was brokenSimon Marlow2015-11-011-2/+2
| | | | | | | | | | | | | | | Buggy Makefile code meant it was always included, instead of being included only for the dyn ways. Test Plan: validate Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1400
* ApiAnnotations: BooleanFormula is not properly LocatedAlan Zimmerman2015-11-015-50/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment BooleanFormula is defined as data BooleanFormula a = Var a | And [BooleanFormula a] | Or [BooleanFormula a] deriving (Eq, Data, Typeable, Functor, Foldable, Traversable) An API Annotation can only be attached to an item of the form Located a. Replace this with a properly Located version, and attach the appropriate API Annotations to it Updates haddock submodule. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1384 GHC Trac Issues: #11017
* Update process submoduleHerbert Valerio Riedel2015-11-011-1/+1
| | | | | | | | | | This is needed to prepare for #11026 as this update relaxes the upper bounds on `base` to allow for `base-4.9.0.0` This also needs to relax a few upper bounds on process in some cabal files (there will be another process submodule update soon, as a major version bump of process' version is still pending)
* Provide a utility to check API Annotations docsAlan Zimmerman2015-11-011-0/+5
| | | | | | | | | | | | | | | | | | | | | | | A utility to check API Annotations was provided in https://git.haskell.org/ghc.git/commitdiff/43751b2436f370d956d8021b3cdd3 eb77801470b This commit had poor documentation. This patch improves the output generated by the utility as well as supplying better documentation Test Plan: ./validate Reviewers: simonpj, austin, bgamari Reviewed By: austin, bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1397 GHC Trac Issues: #10917
* llvmGen: Really fix build with ClangErik de Castro Lopo2015-11-011-5/+6
| | | | | | | | | | Test Plan: Build with Clang and GCC Reviewers: austin, thomie, hvr, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1414
* llvmGen: Fix build with ClangErik de Castro Lopo2015-11-011-2/+2
| | | | | | | | | | | | | Another weird case of Clang not accepting whitespace in CPP that GCC accepts without a problem. Test Plan: Build with Clang and GCC Reviewers: austin, thomie, hvr, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1409
* Add subWordC# on x86ishNikita Karetnikov2015-10-318-7/+47
| | | | | | | | | | | | | | | This adds a subWordC# primop which implements subtraction with overflow reporting. Reviewers: tibbe, goldfire, rwbarton, bgamari, austin, hvr Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1334 GHC Trac Issues: #10962
* unreg: handle CmmStack in C codegen (unbreaks '-g')Sergei Trofimovich2015-10-301-0/+1
| | | | | | | | The patch makes $ make test TEST="debug T10667" not to fail on CmmStack code generation phase Signed-off-by: Sergei Trofimovich <siarheit@google.com>
* Make type-class dictionary let binds deterministicBartosz Nitka2015-10-305-7/+173
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When generating dictionary let binds in dsTcEvBinds we may end up generating them in arbitrary order according to Unique order. Consider: ``` let $dEq = GHC.Classes.$fEqInt in let $$dNum = GHC.Num.$fNumInt in ... ``` vs ``` let $dNum = GHC.Num.$fNumInt in let $dEq = GHC.Classes.$fEqInt in ... ``` The way this change fixes it is by using `UniqDFM` - a type of deterministic finite maps of things keyed on `Unique`s. This way when you pull out evidence variables corresponding to type-class dictionaries they are in deterministic order. Currently it's the order of insertion and the way it's implemented is by tagging the values with the time of insertion. Test Plan: I've added a new test case to reproduce the issue. ./validate Reviewers: ezyang, simonmar, austin, simonpj, bgamari Reviewed By: simonmar, simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1396 GHC Trac Issues: #4012
* Reimplement shadowing on a per database basis.Edward Z. Yang2015-10-302-77/+121
| | | | | | | | | | | | | | | | | | | | | Summary: This commit reimplements shadowing on package databases by doing the shadowing calculation on a per-database basis: specifically, if a later package database shadows a package from the earlier databases, we first remove that package (and its transitive dependencies) before merging the databases together. This should also fix bootstrapping GHC HEAD with HEAD. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: ggreif, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1385
* Generate Typeable info at definition sitesBen Gamari2015-10-3044-1133/+1753
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second attempt at merging D757. This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T1969: GHC allocates 19% more * T4801: GHC allocates 13% more * T5321FD: GHC allocates 13% more * T9675: GHC allocates 11% more * T783: GHC allocates 11% more * T5642: GHC allocates 10% more I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Updates haddock submodule Test Plan: Let Harbormaster validate Reviewers: austin, hvr, goldfire Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1404 GHC Trac Issues: #9858
* driver: use PROGBITS type for .debug-ghc-link-info sectionSylvain HENRY2015-10-301-9/+27
| | | | | | | | | | | | | | | | | | | | Previously the `.debug-ghc-link-info` section was of type `SHT_NOTE` but this is not compliant with the ELF specification, which requires that `NOTE` sections are in a particular record-based format. We mark this section as `PROGBITS` instead, which is defined as implying no particular format. Fixes #11022. Reviewers: bgamari, austin Reviewed By: bgamari, austin Subscribers: thomie, hsyl20 Differential Revision: https://phabricator.haskell.org/D1375 GHC Trac Issues: #11022
* Unify: Add Outputable instance for UnifyResultMBen Gamari2015-10-301-0/+7
| | | | | | | | | | Reviewers: simonpj, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1389
* Insert an empty line between two STG definitions in dump output.Ömer Sinan Ağacan2015-10-301-1/+2
| | | | | | | | | | | | (Simplifier and desugarer do this already) Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1395
* CmmParse: Expose popcnt operationsBen Gamari2015-10-301-1/+6
| | | | | | | | | | | | | | | Make various population count operations available via C-- syntax under the names %popcnt{8,16,32,64}. Fixes #11037. Reviewers: simonmar, austin, ekmett Reviewed By: austin, ekmett Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1402 GHC Trac Issues: #11037
* Disambiguate record selectors by type signatureAdam Gundry2015-10-309-122/+229
| | | | | | | | | | | | | | | This makes DuplicateRecordFields more liberal in when it will accept ambiguous record selectors, making use of type information in a similar way to updates. See Note [Disambiguating record fields] for more details. I've also refactored how record updates are disambiguated. Test Plan: New and amended tests in overloadedrecflds Reviewers: simonpj, goldfire, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1391
* Kill redundant importSimon Peyton Jones2015-10-301-1/+0
| | | | | | | | | | | | | | | | | I don't really understand this. GHC.hs had: module GHC( ..., module HsSyn, ... ) where import HsSyn import qualified HsSyn -- hack as we want to reexport the whole module GHC now reports the 'import qualified' line as redundant; and it certainly is, because 'import HsSyn' brings everything into scope qualified *and* unqualified. I have no idea why the "hack" was necessary before, but following my refactoring of tcg_used_gres (previous commit), it's reported as redundant, so I've deleted it. I'm making it a separate commit because it seems a bit mysterious and I wanted to draw attention to it.
* Record usage information using GlobalRdrEltSimon Peyton Jones2015-10-3011-246/+177
| | | | | | | | | | | | | | | | | This patch implements an improvment that I've wanted to do for ages, but never gotten around to. Unused imports are computed based on how imported entities occur (qualified, unqualified). This info was accumulated in tcg_used_rdrnames :: Set RdrName. But that was a huge pain, and it got worse when we introduced duplicate record fields. The Right Thing is to record tcg_used_gres :: [GlobalRdrElt], which records the GRE *after* filtering with pickGREs. See Note [GRE filtering] in RdrName. This is much, much bette. This patch deletes quite a bit of code, and is conceptually much easier to follow. Hooray. There should be no change in functionality.
* Fix unused-import stuff in a better waySimon Peyton Jones2015-10-302-48/+42
| | | | | | | | | | | | | | | | The fix for Trac #10890 in commit 1818b48, namely Fix incorrect import warnings when methods with identical names are imported was wrong, as demonstrated by the new test T10890_2. It suppressed far too many warnings! This patch fixes the original problem in a different way, by making RdrName.greUsedRdrName a bit cleverer. But this too is not really the Right Thing. I think the Right Thing is to store the /GRE/ in the tcg_used_rdrnames, not the /RdrName/. That would be a lot simpler and more direct. But one step at a time.
* Swap prov/req in variable naming in Parser.ySimon Peyton Jones2015-10-301-2/+2
| | | | | This is a follow on to the patch for Trac #10928. It's a local renaming of variables only; no change in behaviour.
* x86 codegen: don't generate location commentsSergei Trofimovich2015-10-291-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The following source snippet 'module A where x */* y = 42' when being compiled with '-g' option emits syntactically invalid comment for GNU as: .text .align 8 .loc 1 3 1 /* */* */ Fixed by not emitting comments at all. We already suppress all asm comments in 'X86/Ppr.hs'. Signed-off-by: Sergei Trofimovich <siarheit@google.com> Test Plan: added test and check it works Reviewers: scpmw, simonmar, austin, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1386 GHC Trac Issues: #10667
* Revert "Generate Typeable info at definition sites"Ben Gamari2015-10-2943-1713/+1116
| | | | | | | | This reverts commit bef2f03e4d56d88a7e9752a7afd6a0a35616da6c. This merge was botched Also reverts haddock submodule.
* Generate Typeable info at definition sitesBen Gamari2015-10-2943-1116/+1713
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T3294: GHC allocates 110% more (filed #11030 to track this) * T1969: GHC allocates 30% more * T4801: GHC allocates 14% more * T5321FD: GHC allocates 13% more * T783: GHC allocates 12% more * T9675: GHC allocates 12% more * T5642: GHC allocates 10% more * T9961: GHC allocates 6% more * T9203: Program allocates 54% less I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Requires update of the haddock submodule. Differential Revision: https://phabricator.haskell.org/D757
View Lorry Controller Status