summaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
...
* Prevent -optc arguments from being duplicated in reverse order (#17471)Ryan Scott2019-11-231-3/+2
| | | | | | | | | | | | | | | | | This reverts a part of commit 7bc5d6c6578ab9d60a83b81c7cc14819afef32ba that causes all arguments to `-optc` (and `-optcxx`) to be passed twice to the C/C++ compiler, once in reverse order and then again in the correct order. While passing duplicate arguments is usually harmless it can cause breakage in this pattern, which is employed by Hackage libraries in the wild: ``` ghc Foo.hs foo.c -optc-D -optcFOO ``` As `FOO -D -D FOO` will cause compilers to error. Fixes #17471.
* Make CorePrep.tryEtaReducePrep and CoreUtils.tryEtaReduce line upMatheus Magalhães de Alcantara2019-11-232-20/+10
| | | | | | | Simon PJ says he prefers this fix to #17429 over banning eta-reduction for jumps entirely. Sure enough, this also works. Test case: simplCore/should_compile/T17429.hs
* Take care to not eta-reduce jumps in CorePrepMatheus Magalhães de Alcantara2019-11-231-2/+6
| | | | | | | | | | | | | | CorePrep already had a check to prevent it from eta-reducing Ids that respond true to hasNoBinding (foreign calls, constructors for unboxed sums and products, and Ids with compulsory unfoldings). It did not, however, consider join points as ids that 'must be saturated'. Checking whether the Id responds True to 'isJoinId' should prevent CorePrep from turning saturated jumps like the following (from #17429) into undersaturated ones: (\ eta_XP -> join { mapped_s1vo _ = lvl_s1vs } in jump mapped_s1vo eta_XP)
* Fix typo in Note reference [skip ci]nineonine2019-11-231-6/+6
|
* Strip parentheses in expressions contexts in error messagesVladislav Zavialov2019-11-192-1/+5
| | | | This makes error messages a tad less noisy.
* Packages.hs: use O(n*log(n)) ordNub instead of O(n*n) nubÖmer Sinan Ağacan2019-11-191-6/+6
| | | | | As reported in #8173 in some environments package lists can get quite long, so we use more efficient ordNub instead of nub on package lists.
* Give seq a more precise type and remove magicBen Gamari2019-11-194-134/+106
| | | | | | | | | | | | | | | | | | | | | `GHC.Prim.seq` previously had the rather plain type: seq :: forall a b. a -> b -> b However, it also had a special typing rule to applications where `b` is not of kind `Type`. Issue #17440 noted that levity polymorphism allows us to rather give it the more precise type: seq :: forall (r :: RuntimeRep) a (b :: TYPE r). a -> b -> b This allows us to remove the special typing rule that we previously required to allow applications on unlifted arguments. T9404 contains a non-Type application of `seq` which should verify that this works as expected. Closes #17440.
* desugar: Drop stale Note [Matching seqId]Ben Gamari2019-11-191-6/+0
| | | | | The need for this note vanished in eae703aa60f41fd232be5478e196b661839ec3de.
* Optimize MonadUnique instances based on IO (#16843)nineonine2019-11-1911-121/+79
| | | | | Metric Decrease: T14683
* Turn some comments into GHC.Hs.Utils into haddocksAndreas Klebinger2019-11-171-37/+46
|
* Fix random typos [skip ci]nineonine2019-11-178-9/+9
|
* base: Bump version to 4.14.0.0Ben Gamari2019-11-141-1/+1
| | | | | Metric Increase: T4801
* Only pass mod_location with HscRecomp instead of the entire ModSummaryÖmer Sinan Ağacan2019-11-133-15/+12
| | | | | | | | HscRecomp users only need the ModLocation of the module being compiled, so only pass that to users instead of the entire ModSummary Metric Decrease: T4801
* Print name prefixly in the Outputable instance for StandaloneKindSigRyan Scott2019-11-131-1/+2
| | | | | | | | | Issue #17461 was occurring because the `Outputable` instance for standalone kind signatures was simply calling `ppr` on the name in the kind signature, which does not add parentheses to infix names. The solution is simple: use `pprPrefixOcc` instead. Fixes #17461.
* Ensure that coreView/tcView are able to inlineBen Gamari2019-11-1339-246/+224
| | | | | | | | | | | | | | | | | | | | Previously an import cycle between Type and TyCoRep meant that several functions in TyCoRep ended up SOURCE import coreView. This is quite unfortunate as coreView is intended to be fused into a larger pattern match and not incur an extra call. Fix this with a bit of restructuring: * Move the functions in `TyCoRep` which depend upon things in `Type` into `Type` * Fold contents of `Kind` into `Type` and turn `Kind` into a simple wrapper re-exporting kind-ish things from `Type` * Clean up the redundant imports that popped up as a result Closes #17441. Metric Decrease: T4334
* Document CmmTopInfo typeÖmer Sinan Ağacan2019-11-131-0/+2
| | | | [ci skip]
* Fix #17405 by not checking imported equationsRichard Eisenberg2019-11-105-104/+125
| | | | | | | | | | | | | Previously, we checked all imported type family equations for injectivity. This is very silly. Now, we check only for conflicts. Before I could even imagine doing the fix, I needed to untangle several functions that were (in my opinion) overly complicated. It's still not quite as perfect as I'd like, but it's good enough for now. Test case: typecheck/should_compile/T17405
* Improve SPECIALIZE pragma error messages (Fixes #12126)Alina Banerjee2019-11-104-6/+8
|
* Use the right type in :forceSimon Peyton Jones2019-11-091-3/+5
| | | | | | | | A missing prime meant that we were considering the wrong type in the GHCi debugger, when doing :force on multiple arguments (issue #17431). The fix is trivial.
* SetLevels: Don't set context level when floating casesBen Gamari2019-11-081-4/+33
| | | | | | | | | | | When floating a single-alternative case we previously would set the context level to the level where we were floating the case. However, this is wrong as we are only moving the case and its binders. This resulted in #16978, where the disrepancy caused us to unnecessarily abstract over some free variables of the case body, resulting in shadowing and consequently Core Lint failures. (cherry picked from commit a2a0e6f3bb2d02a9347dec4c7c4f6d4480bc2421)
* Set correct length of DWARF .debug_aranges section (fixes #17428)Szymon Nowicki-Korgol2019-11-081-1/+2
|
* FlagChecker: Add ticky flags to hashed flagsBen Gamari2019-11-071-1/+5
| | | | These affect output and therefore should be part of the flag hash.
* For s390x issue a warning if LLVM 9 or older is usedStefan Schulze Frielinghaus2019-11-071-0/+6
| | | | | For s390x the GHC calling convention is only supported since LLVM version 10. Issue a warning in case an older version of LLVM is used.
* Clean up TH's treatment of unary tuples (or, #16881 part two)Ryan Scott2019-11-077-39/+86
| | | | | | | | | | | | | | !1906 left some loose ends in regards to Template Haskell's treatment of unary tuples. This patch ends to tie up those loose ends: * In addition to having `TupleT 1` produce unary tuples, `TupE [exp]` and `TupP [pat]` also now produce unary tuples. * I have added various special cases in GHC's pretty-printers to ensure that explicit 1-tuples are printed using the `Unit` type. See `testsuite/tests/th/T17380`. * The GHC 8.10.1 release notes entry has been tidied up a little. Fixes #16881. Fixes #17371. Fixes #17380.
* CoreTidy: hide tidyRuleÖmer Sinan Ağacan2019-11-051-1/+1
|
* TidyPgm: replace an explicit loop with mapAccumLÖmer Sinan Ağacan2019-11-051-7/+2
|
* Check EmptyCase by simply adding a non-void constraintSebastian Graf2019-11-055-301/+300
| | | | | | | | | | | | | | | | | | | | | | | | | | | We can handle non-void constraints since !1733, so we can now express the strictness of `-XEmptyCase` just by adding a non-void constraint to the initial Uncovered set. For `case x of {}` we thus check that the Uncovered set `{ x | x /~ ⊥ }` is non-empty. This is conceptually simpler than the plan outlined in #17376, because it talks to the oracle directly. In order for this patch to pass the testsuite, I had to fix handling of newtypes in the pattern-match checker (#17248). Since we use a different code path (well, the main code path) for `-XEmptyCase` now, we apparently also handle #13717 correctly. There's also some dead code that we can get rid off now. `provideEvidence` has been updated to provide output more in line with the old logic, which used `inhabitationCandidates` under the hood. A consequence of the shift away from the `UncoveredPatterns` type is that we don't report reduced type families for empty case matches, because the pretty printer is pure and only knows the match variable's type. Fixes #13717, #17248, #17386
* SysTools: Only apply Windows-specific workaround on WindowsBen Gamari2019-11-041-1/+7
| | | | | | | | | Issue #1110 was apparently due to a bug in Vista which prevented GCC from finding its binaries unless we explicitly added it to PATH. However, this workaround was incorrectly applied on non-Windows platforms as well, resulting in ill-formed PATHs (#17266). Fixes #17266.
* Update Note references -- comments onlyRichard Eisenberg2019-11-021-2/+2
| | | | Follow-on from !2041.
* Separate `LPat` from `Pat` on the type-levelSebastian Graf2019-11-0210-69/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the Trees That Grow effort started, we had `type LPat = Pat`. This is so that `SrcLoc`s would only be annotated in GHC's AST, which is the reason why all GHC passes use the extension constructor `XPat` to attach source locations. See #15495 for the design discussion behind that. But now suddenly there are `XPat`s everywhere! There are several functions which dont't cope with `XPat`s by either crashing (`hsPatType`) or simply returning incorrect results (`collectEvVarsPat`). This issue was raised in #17330. I also came up with a rather clean and type-safe solution to the problem: We define ```haskell type family XRec p (f :: * -> *) = r | r -> p f type instance XRec (GhcPass p) f = Located (f (GhcPass p)) type instance XRec TH f = f p type LPat p = XRec p Pat ``` This is a rather modular embedding of the old "ping-pong" style, while we only pay for the `Located` wrapper within GHC. No ping-ponging in a potential Template Haskell AST, for example. Yet, we miss no case where we should've handled a `SrcLoc`: `hsPatType` and `collectEvVarsPat` are not callable at an `LPat`. Also, this gets rid of one indirection in `Located` variants: Previously, we'd have to go through `XPat` and `Located` to get from `LPat` to the wrapped `Pat`. Now it's just `Located` again. Thus we fix #17330.
* Make CSE delay inlining lessSimon Peyton Jones2019-11-011-7/+49
| | | | | | | | | CSE delays inlining a little bit, to avoid losing vital specialisations; see Note [Delay inlining after CSE] in CSE. But it was being over-enthusiastic. This patch makes the delay only apply to Ids with specialisation rules, which avoids unnecessary delay (#17409).
* template-haskell: require at least 1 GADT constructor name (#17379)Adam Sandberg Eriksson2019-11-011-0/+6
|
* Describe optimisation of demand analysis of noinlineBen Gamari2019-11-011-0/+8
| | | | As described in #16588.
* Fix a bad error in tcMatchTySimon Peyton Jones2019-11-011-4/+28
| | | | | | | | | | | This patch fixes #17395, a very subtle and hard-to-trigger bug in tcMatchTy. It's all explained in Note [Matching in the presence of casts (2)] I have not added a regression test because it is very hard to trigger it, until we have the upcoming mkAppTyM patch, after which lacking this patch means you can't even compile the libraries.
* Makes Lint less chatty:Simon Peyton Jones2019-11-011-11/+13
| | | | | | | | | | | | | | | | | I found in #17415 that Lint was printing out truly gigantic warnings, unmanageably huge, with repeated copies of the same thing. This patch makes Lint less chatty, especially for warnings: * For **warnings**, I don't print details of the location, unless you add `-dppr-debug`. * For **errors**, I still print all the info. They are fatal and stop exection, whereas warnings appear repeatedly. * I've made much less use of `AnExpr` in `LintLocInfo`; the expression can be gigantic.
* Whitespace forward compatibility for proposal #229Vladislav Zavialov2019-10-302-4/+4
| | | | | | | | GHC Proposal #229 changes the lexical rules of Haskell, which may require slight whitespace adjustments in certain cases. This patch changes formatting in a few places in GHC and its testsuite in a way that enables it to compile under the proposed rules.
* MkIface: Remove redundant parameter and outdated comments from addFingerprintsÖmer Sinan Ağacan2019-10-291-8/+8
|
* HscMain: Move a comment closer to the relevant siteÖmer Sinan Ağacan2019-10-291-4/+4
|
* Remove unused DynFlags arg of lookupIfaceByModuleÖmer Sinan Ağacan2019-10-296-17/+12
|
* Return ModIface in compilation pipeline, remove IORef hack for generating ↵Ömer Sinan Ağacan2019-10-294-97/+114
| | | | | | | | | | | | | | | | | | | | | ModIfaces The compilation phases now optionally return ModIface (for phases that generate an interface, currently only HscOut when (re)compiling a file). The value is then used by compileOne' to return the generated interface with HomeModInfo (which is then used by the batch mode compiler when building rest of the tree). hscIncrementalMode also returns a DynFlags with plugin info, to be used in the rest of the pipeline. Unfortunately this introduces a (perhaps less bad) hack in place of the previous IORef: we now record the DynFlags used to generate the partial infterface in HscRecomp and use the same DynFlags when generating the full interface. I spent almost three days trying to understand what's changing in DynFlags that causes a backpack test to fail, but I couldn't figure it out. There's a FIXME added next to the field so hopefully someone who understands this better than I do will fix it leter.
* Refactor HscRecomp constructors:Ömer Sinan Ağacan2019-10-293-47/+45
| | | | | | | | | | | Make it evident in the constructors that the final interface is only available when HscStatus is not HscRecomp. (When HscStatus == HscRecomp we need to finish the compilation to get the final interface) `Maybe ModIface` return value of hscIncrementalCompile and the partial `expectIface` function are removed.
* Better arity for join pointsSimon Peyton Jones2019-10-287-24/+49
| | | | | | A join point was getting too large an arity, leading to #17294. I've tightened up the invariant: see CoreSyn, Note [Invariants on join points], invariant 2b
* Use FlexibleInstances for `Outputable (* p)` instead of match-all instances ↵Sebastian Graf2019-10-2816-205/+209
| | | | | | | | | | | | | | with equality constraints In #17304, Richard and Simon dicovered that using `-XFlexibleInstances` for `Outputable` instances of AST data types means users can provide orphan `Outputable` instances for passes other than `GhcPass`. Type inference doesn't currently to suffer, and Richard gave an example in #17304 that shows how rare a case would be where the slightly worse type inference would matter. So I went ahead with the refactoring, attempting to fix #17304.
* Attach API Annotations for {-# SOURCE #-} import pragmaAlan Zimmerman2019-10-281-14/+13
| | | | | | | Attach the API annotations for the start and end locations of the {-# SOURCE #-} pragma in an ImportDecl. Closes #17388
* Refactor TcDeriv to validity-check less in anyclass/via deriving (#13154)Ryan Scott2019-10-283-300/+499
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to the way `DerivEnv` is currently structured, there is an invariant that every derived instance must consist of a class applied to a non-empty list of argument types, where the last argument *must* be an application of a type constructor to some arguments. This works for many cases, but there are also some design patterns in standalone `anyclass`/`via` deriving that are made impossible due to enforcing this invariant, as documented in #13154. This fixes #13154 by refactoring `TcDeriv` and friends to perform fewer validity checks when using the `anyclass` or `via` strategies. The highlights are as followed: * Five fields of `DerivEnv` have been factored out into a new `DerivInstTys` data type. These fields only make sense for instances that satisfy the invariant mentioned above, so `DerivInstTys` is now only used in `stock` and `newtype` deriving, but not in other deriving strategies. * There is now a `Note [DerivEnv and DerivSpecMechanism]` describing the bullet point above in more detail, as well as explaining the exact requirements that each deriving strategy imposes. * I've refactored `mkEqnHelp`'s call graph to be slightly less complicated. Instead of the previous `mkDataTypeEqn`/`mkNewTypeEqn` dichotomy, there is now a single entrypoint `mk_eqn`. * Various bits of code were tweaked so as not to use fields that are specific to `DerivInstTys` so that they may be used by all deriving strategies, since not all deriving strategies use `DerivInstTys`.
* Fix #15344: use fail when desugaring applicative-doJosef Svenningsson2019-10-288-59/+156
| | | | | | | | | | | | | | | | Applicative-do has a bug where it fails to use the monadic fail method when desugaring patternmatches which can fail. See #15344. This patch fixes that problem. It required more rewiring than I had expected. Applicative-do happens mostly in the renamer; that's where decisions about scheduling are made. This schedule is then carried through the typechecker and into the desugarer which performs the actual translation. Fixing this bug required sending information about the fail method from the renamer, through the type checker and into the desugarer. Previously, the desugarer didn't have enough information to actually desugar pattern matches correctly. As a side effect, we also fix #16628, where GHC wouldn't catch missing MonadFail instances with -XApplicativeDo.
* Parenthesize nullary constraint tuples using sigPrec (#17403)Ryan Scott2019-10-271-1/+1
| | | | | | | | | We were using `appPrec`, not `sigPrec`, as the precedence when determining whether or not to parenthesize `() :: Constraint`, which lead to the parentheses being omitted in function contexts like `(() :: Constraint) => String`. Easily fixed. Fixes #17403.
* Remove redundant -fno-cse optionsÖmer Sinan Ağacan2019-10-262-4/+0
| | | | | These were probably added with some GLOBAL_VARs, but those GLOBAL_VARs are now gone.
* Implement shrinkSmallMutableArray# and resizeSmallMutableArray#.Andrew Martin2019-10-262-1/+18
| | | | | | | | | | | | | | | | | | | | | This is a part of GHC Proposal #25: "Offer more array resizing primitives". Resources related to the proposal: - Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/121 - Proposal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0025-resize-boxed.rst Only shrinkSmallMutableArray# is implemented as a primop since a library-space implementation of resizeSmallMutableArray# (in GHC.Exts) is no less efficient than a primop would be. This may be replaced by a primop in the future if someone devises a strategy for growing arrays in-place. The library-space implementation always copies the array when growing it. This commit also tweaks the documentation of the deprecated sizeofMutableByteArray#, removing the mention of concurrency. That primop is unsound even in single-threaded applications. Additionally, the non-negativity assertion on the existing shrinkMutableByteArray# primop has been removed since this predicate is trivially always true.
* Mark promoted InfixT names as IsPromoted (#17394)Ryan Scott2019-10-241-8/+13
| | | | | We applied a similar fix for `ConT` in #15572 but forgot to apply the fix to `InfixT` as well. This patch fixes #17394 by doing just that.
View Lorry Controller Status