summaryrefslogtreecommitdiff
path: root/compiler/rename
Commit message (Collapse)AuthorAgeFilesLines
...
* Disambiguate record selectors by type signatureAdam Gundry2015-10-303-5/+9
| | | | | | | | | | | | | | | 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
* Record usage information using GlobalRdrEltSimon Peyton Jones2015-10-303-131/+61
| | | | | | | | | | | | | | | | | 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-301-21/+7
| | | | | | | | | | | | | | | | 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.
* Record pattern synonymsMatthew Pickering2015-10-294-22/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements an extension to pattern synonyms which allows user to specify pattern synonyms using record syntax. Doing so generates appropriate selectors and update functions. === Interaction with Duplicate Record Fields === The implementation given here isn't quite as general as it could be with respect to the recently-introduced `DuplicateRecordFields` extension. Consider the following module: {-# LANGUAGE DuplicateRecordFields #-} {-# LANGUAGE PatternSynonyms #-} module Main where pattern S{a, b} = (a, b) pattern T{a} = Just a main = do print S{ a = "fst", b = "snd" } print T{ a = "a" } In principle, this ought to work, because there is no ambiguity. But at the moment it leads to a "multiple declarations of a" error. The problem is that pattern synonym record selectors don't do the same name mangling as normal datatypes when DuplicateRecordFields is enabled. They could, but this would require some work to track the field label and selector name separately. In particular, we currently represent datatype selectors in the third component of AvailTC, but pattern synonym selectors are just represented as Avails (because they don't have a corresponding type constructor). Moreover, the GlobalRdrElt for a selector currently requires it to have a parent tycon. (example due to Adam Gundry) === Updating Explicitly Bidirectional Pattern Synonyms === Consider the following ``` pattern Silly{a} <- [a] where Silly a = [a, a] f1 = a [5] -- 5 f2 = [5] {a = 6} -- currently [6,6] ``` === Fixing Polymorphic Updates === They were fixed by adding these two lines in `dsExpr`. This might break record updates but will be easy to fix. ``` + ; let req_wrap = mkWpTyApps (mkTyVarTys univ_tvs) - , pat_wrap = idHsWrapper } +, pat_wrap = req_wrap } ``` === Mixed selectors error === Note [Mixed Record Field Updates] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider the following pattern synonym. data MyRec = MyRec { foo :: Int, qux :: String } pattern HisRec{f1, f2} = MyRec{foo = f1, qux=f2} This allows updates such as the following updater :: MyRec -> MyRec updater a = a {f1 = 1 } It would also make sense to allow the following update (which we reject). updater a = a {f1 = 1, qux = "two" } ==? MyRec 1 "two" This leads to confusing behaviour when the selectors in fact refer the same field. updater a = a {f1 = 1, foo = 2} ==? ??? For this reason, we reject a mixture of pattern synonym and normal record selectors in the same update block. Although of course we still allow the following. updater a = (a {f1 = 1}) {foo = 2} > updater (MyRec 0 "str") MyRec 2 "str"
* Pattern synonyms: swap provided/requiredSimon Peyton Jones2015-10-281-4/+4
| | | | | | | | | | | | | | This patch swaps the order of provided and required constraints in a pattern signature, so it now goes pattern P :: req => prov => t1 -> ... tn -> res_ty See the long discussion in Trac #10928. I think I have found all the places, but I could have missed something particularly in comments. There is a Haddock changes; so a submodule update.
* Systools.hs: Improve detection of GCC and ClangErik de Castro Lopo2015-10-201-1/+1
| | | | | | | | | | | | Test Plan: Build on Debian using `--with-gcc=clang` Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1336 GHC Trac Issues: #10981
* Make Monad/Applicative instances MRP-friendlyHerbert Valerio Riedel2015-10-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This patch refactors pure/(*>) and return/(>>) in MRP-friendly way, i.e. such that the explicit definitions for `return` and `(>>)` match the MRP-style default-implementation, i.e. return = pure and (>>) = (*>) This way, e.g. all `return = pure` definitions can easily be grepped and removed in GHC 8.1; Test Plan: Harbormaster Reviewers: goldfire, alanz, bgamari, quchen, austin Reviewed By: quchen, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1312
* Add typed holes support in Template Haskell.Jan Stolarek2015-10-164-36/+53
| | | | | Fixes #10267. Typed holes in typed Template Haskell currently don't work. See #10945 and #10946.
* Implement DuplicateRecordFieldsAdam Gundry2015-10-166-304/+601
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements DuplicateRecordFields, the first part of the OverloadedRecordFields extension, as described at https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields This includes fairly wide-ranging changes in order to allow multiple records within the same module to use the same field names. Note that it does *not* allow record selector functions to be used if they are ambiguous, and it does not have any form of type-based disambiguation for selectors (but it does for updates). Subsequent parts will make overloading selectors possible using orthogonal extensions, as described on the wiki pages. This part touches quite a lot of the codebase, and requires changes to several GHC API datatypes in order to distinguish between field labels (which may be overloaded) and selector function names (which are always unique). The Haddock submodule has been adapted to compile with the GHC API changes, but it will need further work to properly support modules that use the DuplicateRecordFields extension. Test Plan: New tests added in testsuite/tests/overloadedrecflds; these will be extended once the other parts are implemented. Reviewers: goldfire, bgamari, simonpj, austin Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D761
* Rename package key to unit ID, and installed package ID to component ID.Edward Z. Yang2015-10-142-13/+13
| | | | | | Comes with Haddock submodule update. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Fix incorrect import warnings when methods with identical names are importedÖmer Sinan Ağacan2015-10-131-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, GHC's warning generation code is assuming that a name (`RdrName`) can be imported at most once. This is a correct assumption, because 1) it's OK to import same names as long as we don't use any of them 2) when we use one of them, GHC generates an error because it doesn't disambiguate it automatically. But apparently the story is different with typeclass methods. If I import two methods with same names, it's OK to use them in typeclass instance declarations, because the context specifies which one to use. For example, this is OK (where modules A and B define typeclasses A and B, both with a function has), import A import B data Blah = Blah instance A Blah where has = Blah instance B Blah where has = Blah But GHC's warning generator is not taking this into account, and so if I change import list of this program to: import A (A (has)) import B (B (has)) GHC is printing these warnings: Main.hs:5:1: Warning: The import of ‘A.has’ from module ‘A’ is redundant Main.hs:6:1: Warning: The import of ‘B.has’ from module ‘B’ is redundant Why? Because warning generation code is _silently_ ignoring multiple symbols with same names. With this patch, GHC takes this into account. If there's only one name, then this patch reduces to the previous version, that is, it works exactly the same as current GHC (thanks goes to @quchen for realizing this). Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1257 GHC Trac Issues: #10890
* Revert "Revert "Revert "Change loadSrcInterface to return a list of ModIface"""Edward Z. Yang2015-09-212-50/+30
| | | | This reverts commit 0c6c015d42c2bd0ee008f790c7c0cb4c5b78ca6b.
* Replace [PostTc id Type] with PostTc id [Type]Matthew Pickering2015-09-201-1/+1
| | | | | | | | | | | | | | | This gives a clearer indication as to what gets filled in when. It was suggested by Richard on D1152. Test Plan: ./validate Reviewers: austin, goldfire, bgamari Reviewed By: goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1245
* ApplicativeDo transformationSimon Marlow2015-09-172-47/+500
| | | | | | | | | | | | | | | | Summary: This is an implementation of the ApplicativeDo proposal. See the Note [ApplicativeDo] in RnExpr for details on the current implementation, and the wiki page https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo for design notes. Test Plan: validate Reviewers: simonpj, goldfire, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D729
* Dead code removal, export cleanupJan Stolarek2015-09-121-13/+1
|
* Injective type familiesJan Stolarek2015-09-032-33/+189
| | | | | | | | | | | | | | | | | | | For details see #6018, Phab:D202 and the wiki page: https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies This patch also wires-in Maybe data type and updates haddock submodule. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Subscribers: mpickering, bgamari, alanz, thomie, goldfire, simonmar, carter Differential Revision: https://phabricator.haskell.org/D202 GHC Trac Issues: #6018
* Expand declaration QQs first (#10047)Michael Smith2015-09-022-1/+10
| | | | | | | | | | | | | | | | | | | | | Declaration QuasiQuoters do not cause a group split like $(...) splices, and are run and expanded before other declarations in the group. Resolves the lingering issue with #10047, and fixes broken tests qq007 and qq008. Test Plan: validate Reviewers: goldfire, austin, bgamari Reviewed By: bgamari Subscribers: goldfire, simonpj, thomie, spinda Differential Revision: https://phabricator.haskell.org/D1199 GHC Trac Issues: #10047
* Minor refactor to use filterInScopeSimon Peyton Jones2015-08-051-8/+9
|
* Comments onlySimon Peyton Jones2015-08-051-88/+120
|
* Support wild cards in data/type family instancesThomas Winant2015-08-031-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Handle anonymous wild cards in type or data family instance declarations like unnamed type variables. For instance (pun intented): type family F (a :: *) (b :: *) :: * type instance F Int _ = Int Is now the same as: type family F (a :: *) (b :: *) :: * type instance F Int x = Int Note that unlike wild cards in partial type signatures, no errors (or warnings with -XPartialTypeSignatures) are generated for these wild cards, as there is nothing interesting to report to the user, i.e. the inferred kind. Only anonymous wild cards are supported here, named and extra-constraints wild card are not. Test Plan: pass new tests Reviewers: goldfire, austin, simonpj, bgamari Reviewed By: simonpj, bgamari Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1092 GHC Trac Issues: #3699, #10586
* Replace (SourceText,FastString) with StringLiteral data typeAlan Zimmerman2015-08-021-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Phab:D907 introduced SourceText for a number of data types, by replacing FastString with (SourceText,FastString). Since this has an Outputable instance, no warnings are generated when ppr is called on it, but unexpected output is generated. See Phab:D1096 for an example of this. Replace the (SourceText,FastString) tuples with a new data type, ```lang=hs data StringLiteral = StringLiteral SourceText FastString ``` Update haddock submodule accordingly Test Plan: ./validate Reviewers: hvr, austin, rwbarton, trofi, bgamari Reviewed By: trofi, bgamari Subscribers: thomie, trofi, rwbarton, mpickering Differential Revision: https://phabricator.haskell.org/D1101 GHC Trac Issues: #10692
* Fix comment that confused HaddockSimon Peyton Jones2015-07-301-2/+2
| | | | | | | | | | I wish Haddock did not fall over when some random non-Haddock comment contains *'s. I got compiler/rename/RnBinds.hs:732:8: error: parse error on input ‘-- *are not* in scope in the SPECIALISE instance pramas; e.g.’ This patch says '-- /are not/ in scope...' to pacify Haddock.
* Better treatment of signatures in cls/instSimon Peyton Jones2015-07-303-113/+103
| | | | | | | | | The provoking cause for this patch is Trac #5001, comment:23. There was an INLINE pragma in an instance decl, that shouldn't be there. But there was no complaint, just a mysterious WARN later. I ended up having to do some real refactoring but the result is, I think, simpler and more robust.
* renamer: fix module-level deprecation messageSergei Trofimovich2015-07-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Noticed today that deprecation warnings are slightly broken in -HEAD: mtl-2.2.1/Control/Monad/Error/Class.hs:46:1: warning: Module ‘Control.Monad.Trans.Error’ is deprecated: ([", U, s, e, , C, o, n, t, r, o, l, ., M, o, n, a, d, ., T, r, a, n, s, ., E, x, c, e, p, t, , i, n, s, t, e, a, d, "], Use Control.Monad.Trans.Except instead) Commit e6191d1cc37e98785af8b309100ea840084fa3ba slightly changed WarningTxt declaration: -data WarningTxt = WarningTxt (Located SourceText) [Located FastString] - | DeprecatedTxt (Located SourceText) [Located FastString] +data WarningTxt = WarningTxt (Located SourceText) + [Located (SourceText,FastString)] + | DeprecatedTxt (Located SourceText) + [Located (SourceText,FastString)] But 'moduleWarn' function was not updated to do the stripping. Signed-off-by: Sergei Trofimovich <siarheit@google.com> Reviewers: austin, bgamari, hvr, goldfire, rwbarton, alanz Reviewed By: rwbarton, alanz Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1096 GHC Trac Issues: #10313
* Parenthesise TypeOperator in import hintsThomas Winant2015-07-231-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a constructor was mistakenly imported directly instead of as a constructor of a data type, a hint will be shown on how to correctly import it. Just like the constructor, the data type should be surrounded in parentheses if it is an operator (TypeOperator in this case). Instead of: error: In module ‘Data.Type.Equality’: ‘Refl’ is a data constructor of ‘:~:’ To import it use ‘import’ Data.Type.Equality( :~:( Refl ) ) or ‘import’ Data.Type.Equality( :~:(..) ) Print: error: In module ‘Data.Type.Equality’: ‘Refl’ is a data constructor of ‘(:~:)’ To import it use ‘import’ Data.Type.Equality( (:~:)( Refl ) ) or ‘import’ Data.Type.Equality( (:~:)(..) ) Test Plan: pass new test Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1093 GHC Trac Issues: #10668
* Refactor self-boot infoSimon Peyton Jones2015-07-212-28/+36
| | | | | | | | | | | | | | | | This patch is a simple refactoring that prepares for a later one, related to Trac #10083. * Add a field tcg_self_boot :: SelfBootInfo to TcGblEnv, where SelfBootInfo is a new data type, describing the hi-boot file, if any, for the module being compiled. * Make tcHiBootIface return SelfBootInfo, a new data type * Make other functions get SelfBootInfo from the monad. * Remove tcg_mod_name from TcGblEnv; it was barely used and simpler to pass around explicitly.
* Revert "Revert "Change loadSrcInterface to return a list of ModIface""Edward Z. Yang2015-07-202-30/+49
| | | | This reverts commit c60704fc405149407c155e297433f1cc299ae58a.
* Support wild cards in TH splicesThomas Winant2015-07-202-24/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Declaration splices: partial type signatures are fully supported in TH declaration splices. For example, the wild cards in the example below will unify with `Eq a` and `a -> a -> Bool`, as expected: ``` [d| foo :: _ => _ foo x y = x == y |] ``` - Expression splices: anonymous and named wild cards are supported in expression signatures, but extra-constraints wild cards aren't. Just as is the case for regular expression signatures. ``` [e | Just True :: _a _ |] ``` - Typed expression splices: the same wildcards as in (untyped) expression splices are supported. - Pattern splices: TH doesn't support type signatures in pattern splices, consequently, partial type signatures aren't supported either. - Type splices: partial type signatures are only partially supported in type splices, specifically: only anonymous wild cards are allowed. So `[t| _ |]`, `[t| _ -> Maybe _ |]` will work, but `[t| _ => _ |]` or `[| _a |]` won't (without `-XNamedWildCards`, the latter will work as the named wild card is treated as a type variable). Normally, named wild cards are collected before renaming a (partial) type signature. However, TH type splices are run during renaming, i.e. after the initial traversal, leading to out of scope errors for named wild cards. We can't just extend the initial traversal to collect the named wild cards in TH type splices, as we'd need to expand them, which is supposed to happen only once, during renaming. Similarly, the extra-constraints wild card is handled right before renaming too, and is therefore also not supported in a TH type splice. Another reason not to support extra-constraints wild cards in TH type splices is that a single signature can contain many TH type splices, whereas it mustn't contain more than one extra-constraints wild card. Enforcing would this be hard the way things are currently organised. Anonymous wild cards pose no problem, because they start without names and are given names during renaming. These names are collected right after renaming. The names generated for anonymous wild cards in TH type splices will thus be collected as well. With a more invasive refactoring of the renaming, partial type signatures could be fully supported in TH type splices. As only anonymous wild cards have been requested so far, these small changes satisfying this request will do for now. Also don't forget that a TH declaration splices support all kinds of wild cards. - Extra-constraints wild cards were silently ignored in expression and pattern signatures, appropriate error messages are now generated. Test Plan: run new tests Reviewers: austin, goldfire, adamgundry, bgamari Reviewed By: goldfire, adamgundry, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1048 GHC Trac Issues: #10094, #10548
* Fix Trac #10618 (out of scope operator)Simon Peyton Jones2015-07-081-2/+5
| | | | | | Out of scope variables now generate HsUnboundVar, and the fixity re-jigging wasn't taking this into account.
* Fix Trac #10519Thomas Winant2015-07-031-1/+1
| | | | | | | | | | | | | | | | | Look through nested foralls when checking the validity of a partial type signature. The combination of D836 and D613 prompts this change. Test Plan: The test T10519 must pass Reviewers: simonpj, alanz, austin Reviewed By: simonpj, alanz, austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D994 GHC Trac Issues: #10519
* Enable using qualified field of constructor in GHCiZejun Wu2015-07-031-2/+7
| | | | | | | | | | | | | | | | | | | | The -fimplicit-import-qualified made it possible to uses qualifed names in GHCi without explicitly import the modules. But it didn't work for field of constructor, this patch fixed this issue. Test Plan: cd testsuite/tests/rename/ && make cd testsuite/tests/ghci/ && make Reviewers: austin, simonpj Reviewed By: austin, simonpj Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D900 GHC Trac Issues: #10439
* Treat out-of-scope variables as holesSimon Peyton Jones2015-06-262-42/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the idea in Trac #10569. * An out-of-scope variable is treated as a typed expression hole. * That is, we don't report it in the type checker, not the renamer, and we when we do report it, we give its type. * Moreover, we can defer the error to runtime with -fdefer-typed-holes In implementation terms: * The renamer turns an unbound variable into a HsUnboundVar * The type checker emits a Hole constraint for a HsUnboundVar, and turns it back into a HsVar It was a bit painful to implement because a whole raft of error messages change slightly. But there was absolutely nothing hard in principle. Holes are reported with a bunch of possibly-useful context, notably the "relevant bindings". I found that this was distracting clutter in the very common case of a mis-typed variable that is only accidentally not in scope, so I've arranged to print the context information only for true holes, that is ones starting with an underscore. Unbound data constructors use in patterns, like f (D x) = x are still reportd by the renamer, and abort compilation before type checking.
* Minor fix to free-vars in RnTypesSimon Peyton Jones2015-06-261-2/+6
| | | | | A type wild-card should't appear in the "uses" free-variable set.
* Spelling in commentsSimon Peyton Jones2015-06-151-1/+1
|
* Revert "Change loadSrcInterface to return a list of ModIface"Edward Z. Yang2015-06-112-49/+30
| | | | | | | | As it turns out, in our new design these changes are no longer needed. The code is simpler without returning a list of ModIface, so let's do it! This reverts commit 8c7d20d8c7e63a1123755aae69cfa825c749e9e8.
* Refactor wild card renamingThomas Winant2015-06-093-85/+196
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Refactor wild card error reporting * Merge `HsWildcardTy` and `HsNamedWildcardTy` into one constructor `HsWildCardTy` with as field the new type `HsWildCardInfo`, which has two constructors: `AnonWildCard` and `NamedWildCard`. * All partial type checks are removed from `RdrHsSyn.hs` and are now done during renaming in order to report better error messages. When wild cards are allowed in a type, the new function `rnLHsTypeWithWildCards` (or `rnHsSigTypeWithWildCards`) should be used. This will bring the named wild cards into scope before renaming them. When this is not done, renaming will trigger "Unexpected wild card..." errors. Unfortunately, this has to be done separately for anonymous wild cards because they are given a fresh name during renaming, so they will not cause an out-of-scope error. They are handled in `tc_hs_type`, as a special case of a lookup that fails. The previous opt-out approach is replaced with an opt-in approach. No more panics because of forgotten checks! * `[t| _ |]` isn't caught by the above two checks, so it is currently handled by a special case. The error message (generated in the `DsM` monad) doesn't provide as much context information as the other cases. * Instead of three (!) functions that walk `HsType`, there is now only one pure function called `collectWildCards`. * Alternative approach: catch all unwanted wild cards in `rnHsTyKi` by looking at the `HsDocContext`. This will reduce the number of places to catch unwanted wild cards form three to one, and make the error messages more uniform, albeit less informative, as the error context for renaming is not as informative as the one for type checking. A new constructor of `HsDocContext` will be required for pattern synonyms signatures. Small problem: currently type-class type signatures can't be distinguished from type signatures using the `HsDocContext`. This requires an update to the Haddock submodule. Test Plan: validate Reviewers: goldfire, simonpj, austin Reviewed By: simonpj Subscribers: bgamari, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D613 GHC Trac Issues: #10098
* Refactor RdrName.Provenance, to fix #7672Simon Peyton Jones2015-06-033-108/+83
| | | | | | | | | | | Trac #7672 has a data type T in module A that is in scope *both* locally-bound *and* imported (with a qualified) name. The Provenance of a GlobalRdrElt simply couldn't express that before. Now you can. In doing so, I flattened out Provenance into GlobalRdrElt, so quite a lot of modules are touched in a not-very-interesting way.
* Refactor the GlobalRdrEnv, fixing #7672Simon Peyton Jones2015-06-022-125/+137
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch started innocently enough, by deleting a single call from rnImportDecl, namely let gbl_env = mkGlobalRdrEnv (filterOut from_this_mod gres) The 'filterOut' makes no sense, and was the cause of #7672. But that little loose end led to into a twisty maze of little passages, all alike, which has taken me an unreasonably long time to straighten out. Happily, I think the result is really much better. In particular: * INVARIANT 1 of the GlobalRdrEnv type was simply not true: we had multiple GlobalRdrElts in a list with the same gre_name field. This kludgily implmented one form of shadowing. * Meanwhile, extendGlobalRdrEnvRn implemented a second form of shadowing, by deleting stuff from the GlobalRdrEnv. * In turn, much of this shadowing stuff depended on the Names of the Ids bound in the GHCi InteractiveContext being Internal names, even though the TyCons and suchlike all had External Names. Very confusing. So I have made the following changes * I re-established INVARIANT 1 of GlobalRdrEnv. As a result some strange code in RdrName.pickGREs goes away. * RnNames.extendGlobalRdrEnvRn now makes one call to deal with shadowing, where necessary, and another to extend the environment. It deals separately with duplicate bindings. The very complicated RdrName.extendGlobalRdrEnv becomes much simpler; we need to export the shadowing function, now called RdrName.shadowNames; and we can nuke RdrName.findLocalDupsRdrEnv altogether. RdrName Note [GlobalRdrEnv shadowing] summarises the shadowing story * The Names of the Ids bound in the GHCi interactive context are now all External. See Note [Interactively-bound Ids in GHCi] in HscTypes. * Names for Ids created by the debugger are now made by IfaceEnv.newInteractiveBinder. This fixes a lurking bug which was that the debugger was using mkNewUniqueSupply 'I' to make uniques, which does NOT guarantee a fresh supply of uniques on successive calls. * Note [Template Haskell ambiguity] in RnEnv shows that one TH-related error is reported lazily (on occurrences) when it might be better reported when extending the environment. In some (but not all) cases this was done before; but now it's uniformly at occurrences. In some ways it'd be better to report when extending the environment, but it's a tiresome test and the error is rare, so I'm leaving it at the lookup site for now, with the above Note. * A small thing: RnNames.greAvail becomes RdrName.availFromGRE, where it joins the dual RdrName.gresFromAvail.
* Treat pattern-synonym binders more consistentlySimon Peyton Jones2015-06-024-51/+41
| | | | | | | | | | | Pattern-synonyms are in value declarations, but were being bound by getLocalNonValBinders. This seemed odd, and indeed staightening it out allowed me to remove a field from TopSigCtxt. The main changes are in RnSource.rnSrcDecls. Nice.
* ApiAnnotations : strings in warnings do not return SourceTextAlan Zimmerman2015-06-012-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The strings used in a WARNING pragma are captured via strings :: { Located ([AddAnn],[Located FastString]) } : STRING { sL1 $1 ([],[L (gl $1) (getSTRING $1)]) } .. The STRING token has a method getSTRINGs that returns the original source text for a string. A warning of the form {-# WARNING Logic , mkSolver , mkSimpleSolver , mkSolverForLogic , solverSetParams , solverPush , solverPop , solverReset , solverGetNumScopes , solverAssertCnstr , solverAssertAndTrack , solverCheck , solverCheckAndGetModel , solverGetReasonUnknown "New Z3 API support is still incomplete and fragile: \ \you may experience segmentation faults!" #-} returns the concatenated warning string rather than the original source. This patch now deals with all remaining instances of getSTRING to bring in a SourceText for each. This updates the haddock submodule as well, for the AST change. Test Plan: ./validate Reviewers: hvr, austin, goldfire Reviewed By: austin Subscribers: bgamari, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D907 GHC Trac Issues: #10313
* Remove unnecessary loadInterface for TH quoted name.Edward Z. Yang2015-05-281-13/+2
| | | | | | | | | | | | | | | | | | | | | | | Summary: The load was introduced a32d3e4da0aceb624c958f02cad7327e17ac94db to fix a bug where deprecations assumed that the name in question had already had their interface loaded. The new deprecation code no longer makes this assumption and just loads the interface, so this eager load is not necessary. Verified that TH_reifyType2 continues to work. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D891 GHC Trac Issues: #10419
* Omit the static form error for variables not in scope.Facundo Domínguez2015-05-251-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fixes T10446. The following program > g = static f now produces only: > ...: error > Not in scope: 'f' Before it would also produce a complaint about 'f' not being a top-level identifier. Test Plan: validate Reviewers: austin Reviewed By: austin Subscribers: bgamari, thomie, mboes Differential Revision: https://phabricator.haskell.org/D906 GHC Trac Issues: #10446
* ApiAnnotations : AST version of nested forall loses forall annotationAlan Zimmerman2015-05-212-48/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When parsing {-# LANGUAGE ScopedTypeVariables #-} extremumNewton :: forall tag. forall tag1. tag -> tag1 -> Int extremumNewton = undefined the parser creates nested HsForAllTy's for the two forall statements. These get flattened into a single one in `HsTypes.mk_forall_ty` This patch removes the flattening, so that API Annotations are not lost in the process. Test Plan: ./validate Reviewers: goldfire, austin, simonpj Reviewed By: simonpj Subscribers: bgamari, mpickering, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D836 GHC Trac Issues: #10278, #10315, #10354, #10363
* Refactor tuple constraintsSimon Peyton Jones2015-05-183-16/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make tuple constraints be handled by a perfectly ordinary type class, with the component constraints being the superclasses: class (c1, c2) => (c2, c2) This change was provoked by #10359 inability to re-use a given tuple constraint as a whole #9858 confusion between term tuples and constraint tuples but it's generally a very nice simplification. We get rid of - In Type, the TuplePred constructor of PredTree, and all the code that dealt with TuplePreds - In TcEvidence, the constructors EvTupleMk, EvTupleSel See Note [How tuples work] in TysWiredIn. Of course, nothing is ever entirely simple. This one proved quite fiddly. - I did quite a bit of renaming, which makes this patch touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. - I made constraint tuples known-key rather than wired-in. This is different to boxed/unboxed tuples, but it proved awkward to have all the superclass selectors wired-in. Easier just to use the standard mechanims. - While I was fiddling with known-key names, I split the TH Name definitions out of DsMeta into a new module THNames. That meant that the known-key names can all be gathered in PrelInfo, without causing module loops. - I found that the parser was parsing an import item like T( .. ) as a *data constructor* T, and then using setRdrNameSpace to fix it. Stupid! So I changed the parser to parse a *type constructor* T, which means less use of setRdrNameSpace. I also improved setRdrNameSpace to behave better on Exact Names. Largely on priciple; I don't think it matters a lot. - When compiling a data type declaration for a wired-in thing like tuples (,), or lists, we don't really need to look at the declaration. We have the wired-in thing! And not doing so avoids having to line up the uniques for data constructor workers etc. See Note [Declarations for wired-in things] - I found that FunDeps.oclose wasn't taking superclasses into account; easily fixed. - Some error message refactoring for invalid constraints in TcValidity - Haddock needs to absorb the change too; so there is a submodule update
* Revert multiple commitsAustin Seipp2015-05-143-33/+16
| | | | | | | | | | | | | | | | | | | | This reverts multiple commits from Simon: - 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359 - a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403 - c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248 - eb6ca851f553262efe0824b8dcbe64952de4963d Make the "matchable-given" check happen first - ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to checkValidTyCon - 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule - 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet from fixVarSet - a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain (stage2) - a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the build - 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation of error msg - 130e93aab220bdf14d08028771f83df210da340b Refactor tuple constraints - 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out line These break the build by causing Haddock to fail mysteriously when trying to examine GHC.Prim it seems.
* Refactor tuple constraintsSimon Peyton Jones2015-05-133-16/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make tuple constraints be handled by a perfectly ordinary type class, with the component constraints being the superclasses: class (c1, c2) => (c2, c2) This change was provoked by #10359 inability to re-use a given tuple constraint as a whole #9858 confusion between term tuples and constraint tuples but it's generally a very nice simplification. We get rid of - In Type, the TuplePred constructor of PredTree, and all the code that dealt with TuplePreds - In TcEvidence, the constructors EvTupleMk, EvTupleSel See Note [How tuples work] in TysWiredIn. Of course, nothing is ever entirely simple. This one proved quite fiddly. - I did quite a bit of renaming, which makes this patch touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. - I made constraint tuples known-key rather than wired-in. This is different to boxed/unboxed tuples, but it proved awkward to have all the superclass selectors wired-in. Easier just to use the standard mechanims. - While I was fiddling with known-key names, I split the TH Name definitions out of DsMeta into a new module THNames. That meant that the known-key names can all be gathered in PrelInfo, without causing module loops. - I found that the parser was parsing an import item like T( .. ) as a *data constructor* T, and then using setRdrNameSpace to fix it. Stupid! So I changed the parser to parse a *type constructor* T, which means less use of setRdrNameSpace. I also improved setRdrNameSpace to behave better on Exact Names. Largely on priciple; I don't think it matters a lot. - When compiling a data type declaration for a wired-in thing like tuples (,), or lists, we don't really need to look at the declaration. We have the wired-in thing! And not doing so avoids having to line up the uniques for data constructor workers etc. See Note [Declarations for wired-in things] - I found that FunDeps.oclose wasn't taking superclasses into account; easily fixed. - Some error message refactoring for invalid constraints in TcValidity
* Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382.Edward Z. Yang2015-05-111-157/+151
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit adds stage 1 support for Template Haskell quoting, e.g. [| ... expr ... |], which is useful for authors of quasiquoter libraries that do not actually need splices. The TemplateHaskell extension now does not unconditionally fail; it only fails if the renamer encounters a splice that it can't run. In order to make sure the referenced data structures are consistent, template-haskell is now a boot library. There are some minor BC changes to template-haskell to make it boot on GHC 7.8. Note for reviewer: big diff changes are simply code being moved out of an ifdef; there was no other substantive change to that code. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, goldfire Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D876 GHC Trac Issues: #10382
* Revert stage 1 template-haskell. This is a combination of 5 commits.Edward Z. Yang2015-05-091-151/+157
| | | | | | | | | | | | | | | | | | | | | | Revert "Quick fix: drop base bound on template-haskell." This reverts commit 3c70ae032e4361b203dfcf22b0a424e8838a5037. Revert "Always do polymorphic typed quote check, c.f. #10384" This reverts commit 9a43b2c1f78b3cf684646af64b9b67dc8079f58f. Revert "RnSplice's staging test should be applied for quotes in stage1." This reverts commit eb0ed4030374af542c0a459480d32c8d4525e48d. Revert "Split off quotes/ from th/ for tests that can be done on stage1 compiler." This reverts commit 21c72e7d38c96ac80d31addf67ae4b3c7a6c3bbb. Revert "Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382." This reverts commit 28257cae77023f2ccc4cc1c0cd1fbbd329947a00.
* RnSplice's staging test should be applied for quotes in stage1.Edward Z. Yang2015-05-091-11/+6
| | | | | | | | | | | | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D878 GHC Trac Issues: #10382
* Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382.Edward Z. Yang2015-05-091-148/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit adds stage 1 support for Template Haskell quoting, e.g. [| ... expr ... |], which is useful for authors of quasiquoter libraries that do not actually need splices. The TemplateHaskell extension now does not unconditionally fail; it only fails if the renamer encounters a splice that it can't run. In order to make sure the referenced data structures are consistent, template-haskell is now a boot library. In the following patches, there are: - A few extra safety checks which should be enabled in stage1 - Separation of the th/ testsuite into quotes/ which can be run on stage1 Note for reviewer: big diff changes are simply code being moved out of an ifdef; there was no other substantive change to that code. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, goldfire Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D876 GHC Trac Issues: #10382
View Lorry Controller Status