summaryrefslogtreecommitdiff
path: root/compiler/parser
Commit message (Collapse)AuthorAgeFilesLines
* Modules (#13009)Sylvain Henry2020-04-186-11136/+0
| | | | | | | | | | | | | | * SysTools * Parser * GHC.Builtin * GHC.Iface.Recomp * Settings Update Haddock submodule Metric Decrease: Naperian parsing001
* Use trees that grow for rebindable operators for `<-` bindsJohn Ericson2020-04-171-1/+1
| | | | Also add more documentation.
* Make NoExtCon fields strictwip/strict-NoExtConRyan Scott2020-04-071-3/+0
| | | | | | | | | | | | | | | | This changes every unused TTG extension constructor to be strict in its field so that the pattern-match coverage checker is smart enough any such constructors are unreachable in pattern matches. This lets us remove nearly every use of `noExtCon` in the GHC API. The only ones we cannot remove are ones underneath uses of `ghcPass`, but that is only because GHC 8.8's and 8.10's coverage checkers weren't smart enough to perform this kind of reasoning. GHC HEAD's coverage checker, on the other hand, _is_ smart enough, so we guard these uses of `noExtCon` with CPP for now. Bumps the `haddock` submodule. Fixes #17992.
* Modules: type-checker (#13009)Sylvain Henry2020-04-072-11/+6
| | | | Update Haddock submodule
* Modules: Types (#13009)Sylvain Henry2020-03-295-26/+26
| | | | | | | Update Haddock submodule Metric Increase: haddock.compiler
* Modules: Core (#13009)Sylvain Henry2020-03-162-10/+10
| | | | Update submodule: haddock
* Monotonic locations (#17632)Vladislav Zavialov2020-02-293-109/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When GHC is parsing a file generated by a tool, e.g. by the C preprocessor, the tool may insert #line pragmas to adjust the locations reported to the user. As the result, the locations recorded in RealSrcLoc are not monotonic. Elements that appear later in the StringBuffer are not guaranteed to have a higher line/column number. In fact, there are no guarantees whatsoever, as #line pragmas can arbitrarily modify locations. This lack of guarantees makes ideas such as #17544 infeasible. This patch adds an additional bit of information to every SrcLoc: newtype BufPos = BufPos { bufPos :: Int } A BufPos represents the location in the StringBuffer, unaffected by any pragmas. Updates haddock submodule. Metric Increase: haddock.Cabal haddock.base haddock.compiler MultiLayerModules Naperian parsing001 T12150
* Modules: Driver (#13009)Sylvain Henry2020-02-213-6/+6
| | | | submodule updates: nofib, haddock
* Parser API annotations: RealSrcLocVladislav Zavialov2020-02-213-65/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During parsing, GHC collects lexical information about AST nodes and stores it in a map. It is needed to faithfully restore original source code, e.g. compare these expressions: a = b a = b The position of the equality sign is not recorded in the AST, so it must be stored elsewhere. This system is described in Note [Api annotations]. Before this patch, the mapping was represented by: Map (SrcSpan, AnnKeywordId) SrcSpan After this patch, the mapping is represented by: Map (RealSrcSpan, AnnKeywordId) RealSrcSpan The motivation behind this change is to avoid using the Ord SrcSpan instance (required by Map here), as it interferes with #17632 (see the discussion there). SrcSpan is isomorphic to Either String RealSrcSpan, but we shouldn't use those strings as Map keys. Those strings are intended as hints to the user, e.g. "<interactive>" or "<compiler-generated code>", so they are not a valid way to identify nodes in the source code.
* Use Type instead of * in GHCBen Gamari2020-02-201-2/+3
|
* Remove the MonadFail P instanceVladislav Zavialov2020-02-181-9/+1
| | | | | | | | | | | | | There were two issues with this instance: * its existence meant that a pattern match failure in the P monad would produce a user-visible parse error, but the error message would not be helpful to the user * due to the MFP migration strategy, we had to use CPP in Lexer.x, and that created issues for #17750 Updates haddock submodule.
* Fix the "unused terminals: 2" warning in Parser.yVladislav Zavialov2020-02-161-3/+1
|
* TemplateHaskellQuotes: Allow nested splicesMatthew Pickering2020-02-111-3/+3
| | | | | | There is no issue with nested splices as they do not require any compile time code execution. All execution is delayed until the top-level splice.
* Import qualified Prelude in parserÖmer Sinan Ağacan2020-02-081-0/+1
| | | | | This is in preparation of backwards-incompatible changes in happy. See https://github.com/simonmar/happy/issues/166
* Introduce IsPass; refactor wrappers.Richard Eisenberg2020-02-082-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two main payloads of this patch: 1. This introduces IsPass, which allows e.g. printing code to ask what pass it is running in (Renamed vs Typechecked) and thus print extension fields. See Note [IsPass] in Hs.Extension 2. This moves the HsWrap constructor into an extension field, where it rightly belongs. This is done for HsExpr and HsCmd, but not for HsPat, which is left as an exercise for the reader. There is also some refactoring around SyntaxExprs, but this is really just incidental. This patch subsumes !1721 (sorry @chreekat). Along the way, there is a bit of refactoring in GHC.Hs.Extension, including the removal of NameOrRdrName in favor of NoGhcTc. This meant that we had no real need for GHC.Hs.PlaceHolder, so I got rid of it. Updates haddock submodule. ------------------------- Metric Decrease: haddock.compiler -------------------------
* Refactor package related codeSylvain Henry2020-01-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-272-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-6/+6
|
* Monomorphize HsModule to GhcPs (#17642)Ryan Scott2020-01-071-3/+3
| | | | | | | | Analyzing the call sites for `HsModule` reveals that it is only ever used with parsed code (i.e., `GhcPs`). This simplifies `HsModule` by concretizing its `pass` parameter to always be `GhcPs`. Fixes #17642.
* Add lexerDbg to dump the tokens fed to the parserVladislav Zavialov2020-01-042-2/+10
| | | | | This a small utility function that comes in handy when debugging the lexer and the parser.
* Fix typos, via a Levenshtein-style correctorBrian Wignall2020-01-041-1/+1
|
* Minor refactor in ghc.cabal.in:Ömer Sinan Ağacan2019-12-262-34/+0
| | | | | | - Remove outdated comments - Move cutils.c from parser to cbits - Remove unused cutils.h
* Improve error messages for SCC pragmasVladislav Zavialov2019-12-052-19/+22
|
* Meaning-preserving SCC annotations (#15730)Vladislav Zavialov2019-12-051-48/+93
| | | | | | | | | | | | | | | This patch implements GHC Proposal #176: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0176-scc-parsing.rst Before the change: 1 / 2 / 2 = 0.25 1 / {-# SCC "name" #-} 2 / 2 = 1.0 After the change: 1 / 2 / 2 = 0.25 1 / {-# SCC "name" #-} 2 / 2 = parse error
* Fix more typosBrian Wignall2019-12-022-2/+2
|
* API Annotations: Unicode '->' on HsForallTyAlan Zimmerman2019-12-021-1/+1
| | | | | | | | | | | The code fragment type family Proxy2' ∷ ∀ k → k → Type where Proxy2' = Proxy' Generates AnnRarrow instead of AnnRarrowU for the first →. Fixes #17519
* Update DisambECP-related commentsVladislav Zavialov2019-12-011-112/+36
|
* Remove HasSrcSpan (#17494)Vladislav Zavialov2019-11-302-433/+421
| | | | | Metric Decrease: haddock.compiler
* Factor out HsSCC/HsCoreAnn/HsTickPragma into HsPragEwip/hs-pragVladislav Zavialov2019-11-281-44/+35
| | | | | | | | | | | | | | | | | | | | | | | This is a refactoring with no user-visible changes (except for GHC API users). Consider the HsExpr constructors that correspond to user-written pragmas: HsSCC representing {-# SCC ... #-} HsCoreAnn representing {-# CORE ... #-} HsTickPragma representing {-# GENERATED ... #-} We can factor them out into a separate datatype, HsPragE. It makes the code a bit tidier, especially in the parser. Before this patch: hpc_annot :: { Located ( (([AddAnn],SourceText),(StringLiteral,(Int,Int),(Int,Int))), ((SourceText,SourceText),(SourceText,SourceText)) ) } After this patch: prag_hpc :: { Located ([AddAnn], HsPragE GhcPs) }
* Fix typos, using Wikipedia list of common typosBrian Wignall2019-11-282-3/+3
|
* Whitespace-sensitive bang patterns (#1087, #17162)wip/whitespace-and-lookaheadVladislav Zavialov2019-11-274-333/+324
| | | | | | | | | | | | | | | | | | This patch implements a part of GHC Proposal #229 that covers five operators: * the bang operator (!) * the tilde operator (~) * the at operator (@) * the dollar operator ($) * the double dollar operator ($$) Based on surrounding whitespace, these operators are disambiguated into bang patterns, lazy patterns, strictness annotations, type applications, splices, and typed splices. This patch doesn't cover the (-) operator or the -Woperator-whitespace warning, which are left as future work.
* Ensure that coreView/tcView are able to inlineBen Gamari2019-11-131-1/+0
| | | | | | | | | | | | | | | | | | | | 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
* Use FlexibleInstances for `Outputable (* p)` instead of match-all instances ↵Sebastian Graf2019-10-281-5/+6
| | | | | | | | | | | | | | 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
* Solve constraints from top-level groups soonerRichard Eisenberg2019-10-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, all constraints from all top-level groups (as separated by top-level splices) were lumped together and solved at the end. This could leak metavariables to TH, though, and that's bad. This patch solves each group's constraints before running the next group's splice. Naturally, we now report fewer errors in some cases. One nice benefit is that this also fixes #11680, but in a much simpler way than the original fix for that ticket. Admittedly, the error messages degrade just a bit from the fix from #11680 (previously, we informed users about variables that will be brought into scope below a top-level splice, and now we just report an out-of-scope error), but the amount of complexity required throughout GHC to get that error was just not worth it. This patch thus reverts much of f93c9517a2c6e158e4a5c5bc7a3d3f88cb4ed119. Fixes #16980 Test cases: th/T16980{,a}
* Clean up `#include`s in the compilerJohn Ericson2019-10-052-3/+3
| | | | | | | | - Remove unneeded ones - Use <..> for inter-package. Besides general clean up, helps distinguish between the RTS we link against vs the RTS we compile for.
* Improve documentation around empty tuples/listsRichard Eisenberg2019-10-031-0/+8
| | | | | | | | | | | | | | This patch also changes the way we handle empty lists, simplifying them somewhat. See Note [Empty lists]. Previously, we had to special-case empty lists in the type-checker. Now no more! Finally, this patch improves some documentation around the ir_inst field used in the type-checker. This breaks a test case, but I really think the problem is #17251, not really related to this patch. Test case: typecheck/should_compile/T13680
* Add `module {-# SOURCE #-} Foo` syntax for hs-boot in bkpJohn Ericson2019-10-031-13/+26
| | | | This is a good convenience for testing.
* Standalone kind signatures (#16794)wip/top-level-kind-signaturesVladislav Zavialov2019-09-252-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implements GHC Proposal #54: .../ghc-proposals/blob/master/proposals/0054-kind-signatures.rst With this patch, a type constructor can now be given an explicit standalone kind signature: {-# LANGUAGE StandaloneKindSignatures #-} type Functor :: (Type -> Type) -> Constraint class Functor f where fmap :: (a -> b) -> f a -> f b This is a replacement for CUSKs (complete user-specified kind signatures), which are now scheduled for deprecation. User-facing changes ------------------- * A new extension flag has been added, -XStandaloneKindSignatures, which implies -XNoCUSKs. * There is a new syntactic construct, a standalone kind signature: type <name> :: <kind> Declarations of data types, classes, data families, type families, and type synonyms may be accompanied by a standalone kind signature. * A standalone kind signature enables polymorphic recursion in types, just like a function type signature enables polymorphic recursion in terms. This obviates the need for CUSKs. * TemplateHaskell AST has been extended with 'KiSigD' to represent standalone kind signatures. * GHCi :info command now prints the kind signature of type constructors: ghci> :info Functor type Functor :: (Type -> Type) -> Constraint ... Limitations ----------- * 'forall'-bound type variables of a standalone kind signature do not scope over the declaration body, even if the -XScopedTypeVariables is enabled. See #16635 and #16734. * Wildcards are not allowed in standalone kind signatures, as partial signatures do not allow for polymorphic recursion. * Associated types may not be given an explicit standalone kind signature. Instead, they are assumed to have a CUSK if the parent class has a standalone kind signature and regardless of the -XCUSKs flag. * Standalone kind signatures do not support multiple names at the moment: type T1, T2 :: Type -> Type -- rejected type T1 = Maybe type T2 = Either String See #16754. * Creative use of equality constraints in standalone kind signatures may lead to GHC panics: type C :: forall (a :: Type) -> a ~ Int => Constraint class C a where f :: C a => a -> Int See #16758. Implementation notes -------------------- * The heart of this patch is the 'kcDeclHeader' function, which is used to kind-check a declaration header against its standalone kind signature. It does so in two rounds: 1. check user-written binders 2. instantiate invisible binders a la 'checkExpectedKind' * 'kcTyClGroup' now partitions declarations into declarations with a standalone kind signature or a CUSK (kinded_decls) and declarations without either (kindless_decls): * 'kinded_decls' are kind-checked with 'checkInitialKinds' * 'kindless_decls' are kind-checked with 'getInitialKinds' * DerivInfo has been extended with a new field: di_scoped_tvs :: ![(Name,TyVar)] These variables must be added to the context in case the deriving clause references tcTyConScopedTyVars. See #16731.
* Fix some duplication in the parserSebastian Graf2019-09-241-20/+4
| | | | | | | | | | | | | | | | | | | | | | D3673 experienced reduce/reduce conflicts when trying to use opt_instance for associated data families. That was probably because the author tried to use it for Haskell98-syntax without also applying it to GADT-syntax, which actually leads to a reduce/reduce conflict. Consider the following state: ``` data . T = T data . T where T :: T ``` The parser must decide at this point whether or not to reduce an empty `opt_instance`. But doing so would also commit to either Haskell98 or GADT syntax! Good thing we also accept an optional "instance" for GADT syntax, so the `opt_instance` is there in both productions and there's no reduce/reduce conflict anymore. Also no need to inline `opt_instance`, how it used to be.
* Remove pointless partiality in `Parser.ajs`John Ericson2019-09-201-15/+16
|
* Module hierarchy: Hs (#13009)Sylvain Henry2019-09-203-14/+14
| | | | | | | Add GHC.Hs module hierarchy replacing hsSyn. Metric Increase: haddock.compiler
* Remove unused `#include`s from parser/cutils.cJohn Ericson2019-09-121-6/+0
| | | | | Looks like these have been unused since 7c665f9ce0980ee7c81a44c8f861686395637453.
* PV is not P (#16611)Vladislav Zavialov2019-07-152-42/+133
|
* Decouple AddAnn from PVladislav Zavialov2019-07-153-14/+13
|
* Use an empty data type in TTG extension constructors (#15247)Ryan Scott2019-07-092-241/+241
| | | | | | | | | | | | | | | To avoid having to `panic` any time a TTG extension constructor is consumed, this MR introduces an uninhabited 'NoExtCon' type and uses that in every extension constructor's type family instance where it is appropriate. This also introduces a 'noExtCon' function which eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates a 'Void'. I also renamed the existing `NoExt` type to `NoExtField` to better distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of code churn resulting from this. Bumps the Haddock submodule. Fixes #15247.
* Some forall-related cleanup in deriving codeRyan Scott2019-05-231-2/+2
| | | | | | | | * Tweak the parser to allow `deriving` clauses to mention explicit `forall`s or kind signatures without gratuitous parentheses. (This fixes #14332 as a consequence.) * Allow Haddock comments on `deriving` clauses with explicit `forall`s. This requires corresponding changes in Haddock.
* Use HsTyPats in associated type family defaultsRyan Scott2019-05-221-59/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Associated type family default declarations behave strangely in a couple of ways: 1. If one tries to bind the type variables with an explicit `forall`, the `forall`'d part will simply be ignored. (#16110) 2. One cannot use visible kind application syntax on the left-hand sides of associated default equations, unlike every other form of type family equation. (#16356) Both of these issues have a common solution. Instead of using `LHsQTyVars` to represent the left-hand side arguments of an associated default equation, we instead use `HsTyPats`, which is what other forms of type family equations use. In particular, here are some highlights of this patch: * `FamEqn` is no longer parameterized by a `pats` type variable, as the `feqn_pats` field is now always `HsTyPats`. * The new design for `FamEqn` in chronicled in `Note [Type family instance declarations in HsSyn]`. * `TyFamDefltEqn` now becomes the same thing as `TyFamInstEqn`. This means that many of `TyFamDefltEqn`'s code paths can now reuse the code paths for `TyFamInstEqn`, resulting in substantial simplifications to various parts of the code dealing with associated type family defaults. Fixes #16110 and #16356.
* Implement ImportQualifiedPostShayne Fletcher2019-05-083-14/+72
|
* Fix #16632 by using the correct SrcSpan in checkTyClHdrRyan Scott2019-05-081-2/+2
| | | | | | `checkTyClHdr`'s case for `HsTyVar` was grabbing the wrong `SrcSpan`, which lead to error messages pointing to the wrong location. Easily fixed.
View Lorry Controller Status