1. 09 May, 2015 2 commits
    • Edward Z. Yang's avatar
      Revert stage 1 template-haskell. This is a combination of 5 commits. · 5c459eef
      Edward Z. Yang authored
      Revert "Quick fix: drop base bound on template-haskell."
      
      This reverts commit 3c70ae03.
      
      Revert "Always do polymorphic typed quote check, c.f. #10384"
      
      This reverts commit 9a43b2c1.
      
      Revert "RnSplice's staging test should be applied for quotes in stage1."
      
      This reverts commit eb0ed403.
      
      Revert "Split off quotes/ from th/ for tests that can be done on stage1 compiler."
      
      This reverts commit 21c72e7d.
      
      Revert "Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382."
      
      This reverts commit 28257cae.
      5c459eef
    • Edward Z. Yang's avatar
      Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382. · 28257cae
      Edward Z. Yang authored
      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: default avatarEdward 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
      28257cae
  2. 24 Feb, 2015 1 commit
  3. 16 Jan, 2015 1 commit
    • Alan Zimmerman's avatar
      API Annotations tweaks. · 11881ec6
      Alan Zimmerman authored
      Summary:
      HsTyLit now has SourceText
      
      Update documentation of HsSyn to reflect which annotations are attached to which element.
      
      Ensure that the parser always keeps HsSCC and HsTickPragma values, to
      be ignored in the desugar phase if not needed
      
      Bringing in SourceText for pragmas
      
      Add Location in NPlusKPat
      
      Add Location in FunDep
      
      Make RecCon payload Located
      
      Explicitly add AnnVal to RdrName where it is compound
      
      Add Location in IPBind
      
      Add Location to name in IEThingAbs
      
      Add Maybe (Located id,Bool) to Match to track fun_id,infix
        This includes converting Match into a record and adding a note about why
        the fun_id needs to be replicated in the Match.
      
      Add Location in KindedTyVar
      
      Sort out semi-colons for parsing
      
        - import statements
        - stmts
        - decls
        - decls_cls
        - decls_inst
      
      This updates the haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: hvr, austin, goldfire, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D538
      11881ec6
  4. 06 Jan, 2015 1 commit
    • Simon Peyton Jones's avatar
      Make the location in TcLclEnv and CtLoc into a RealSrcSpan · d2b6e767
      Simon Peyton Jones authored
      Previously it was a SrcSpan, which can be an UnhelpulSrcSpan,
      but actually for TcLclEnv and CtLoc we always know it is
      a real source location, and it's good to make the types
      reflect that fact.
      
      There is a continuing slight awkwardness (not new with this
      patch) about what "file name" to use for GHCi code.  Current
      we say "<interactive>" which seems just about OK.
      d2b6e767
  5. 28 Dec, 2014 1 commit
    • cactus's avatar
      Support pattern synonyms in GHCi (fixes #9900) · 0cc0cc86
      cactus authored
      This involves recognizing lines starting with `"pattern "` as declarations,
      keeping non-exported pattern synonyms in `deSugar`, and including
      pattern synonyms in the result of `hscDeclsWithLocation`.
      0cc0cc86
  6. 17 Dec, 2014 1 commit
    • Simon Peyton Jones's avatar
      Fix GHCi/GHC-API tidying and modules (Trac #9424, #9426) · 67a0cab6
      Simon Peyton Jones authored
      There were two related bugs here
      
      Trac #9426
         We must increment the ic_mod_index field of the InteractiveContext
         if we have new instances, because we maek DFunIds that should be
         distinct from previous ones.  Previously we were only incrementing
         when defining new user-visible Ids.
      
         The main change is in HscTypes.extendInteractiveContext, which now
         alwyas bumps the ic_mod_index.  I also added a specialised
         extendInteractiveContextWithIds for the case where we are *only*
         adding new user-visible Ids.
      
      Trac #9424
         In HscMain.hscDeclsWithLocations we were failing to use the
         *tidied* ClsInsts; but the un-tidied ones are LocalIds which
         causes a later ASSERT error.
      
         On the way I realised that, to behave consistently, the tcg_insts
         and tcg_fam_insts field of TcGblEnv should really only contain
         instances from the current GHCi command, not all the ones to date.
         That in turn meant I had to move the code for deleting replacement
         instances from addLocalInst, addLocalFamInst to
         HscTypes.extendInteractiveContext
      67a0cab6
  7. 16 Dec, 2014 1 commit
    • Peter Wortmann's avatar
      Source notes (Core support) · 993975d3
      Peter Wortmann authored
      This patch introduces "SourceNote" tickishs that link Core to the
      source code that generated it. The idea is to retain these source code
      links throughout code transformations so we can eventually relate
      object code all the way back to the original source (which we can,
      say, encode as DWARF information to allow debugging).  We generate
      these SourceNotes like other tickshs in the desugaring phase. The
      activating command line flag is "-g", consistent with the flag other
      compilers use to decide DWARF generation.
      
      Keeping ticks from getting into the way of Core transformations is
      tricky, but doable. The changes in this patch produce identical Core
      in all cases I tested -- which at this point is GHC, all libraries and
      nofib. Also note that this pass creates *lots* of tick nodes, which we
      reduce somewhat by removing duplicated and overlapping source
      ticks. This will still cause significant Tick "clumps" - a possible
      future optimization could be to make Tick carry a list of Tickishs
      instead of one at a time.
      
      (From Phabricator D169)
      993975d3
  8. 15 Dec, 2014 1 commit
    • Simon Peyton Jones's avatar
      Make Core Lint check for locally-bound GlobalIds · d59c59f4
      Simon Peyton Jones authored
      There should be no bindings in this module for a GlobalId;
      except after CoreTidy, when top-level bindings are globalised.
      
      To check for this, I had to make the CoreToDo pass part of the
      environment that Core Lint caries.  But CoreToDo is defined in
      CoreMonad, which (before this patch) called CoreLint.
      
      So I had to do quite a bit of refactoring, moving some
      lint-invoking code into CoreLint itself.  Crucially, I also
      more tcLookupImported_maybe, importDecl, and checkwiredInTyCon
      from TcIface (which use CoreLint) to LoadIface (which doesn't).
      This is probably better structure anyway.
      
      So most of this patch is refactoring. The actual check for
      GlobalIds is in CoreLint.lintAndScopeId
      d59c59f4
  9. 03 Dec, 2014 1 commit
  10. 21 Nov, 2014 2 commits
    • Alan Zimmerman's avatar
      Add API Annotations · 803fc5db
      Alan Zimmerman authored
      Summary:
      The final design and discussion is captured at
      https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations
      
      This is a proof of concept implementation of a completely
      separate annotation structure, populated in the parser,and tied to the
      AST by means of a virtual "node-key" comprising the surrounding
      SrcSpan and a value derived from the specific constructor used for the
      node.
      
      The key parts of the design are the following.
      
      == The Annotations ==
      
      In `hsSyn/ApiAnnotation.hs`
      
      ```lang=haskell
      type ApiAnns = (Map.Map ApiAnnKey SrcSpan, Map.Map SrcSpan [Located Token])
      
      type ApiAnnKey = (SrcSpan,AnnKeywordId)
      
      -- ---------------------------------------------------------------------
      
      -- | Retrieve an annotation based on the @SrcSpan@ of the annotated AST
      -- element, and the known type of the annotation.
      getAnnotation :: ApiAnns -> SrcSpan -> AnnKeywordId -> Maybe SrcSpan
      getAnnotation (anns,_) span ann = Map.lookup (span,ann) anns
      
      -- |Retrieve the comments allocated to the current @SrcSpan@
      getAnnotationComments :: ApiAnns -> SrcSpan -> [Located Token]
      getAnnotationComments (_,anns) span =
        case Map.lookup span anns of
          Just cs -> cs
          Nothing -> []
      
      -- | Note: in general the names of these are taken from the
      -- corresponding token, unless otherwise noted
      data AnnKeywordId
               = AnnAs
               | AnnBang
               | AnnClass
               | AnnClose -- ^ } or ] or ) or #) etc
               | AnnComma
               | AnnDarrow
               | AnnData
               | AnnDcolon
               ....
      ```
      
      == Capturing in the lexer/parser ==
      
      The annotations are captured in the lexer / parser by extending PState to include a field
      
      In `parser/Lexer.x`
      
      ```lang=haskell
      data PState = PState {
              ....
              annotations :: [(ApiAnnKey,SrcSpan)]
              -- Annotations giving the locations of 'noise' tokens in the
              -- source, so that users of the GHC API can do source to
              -- source conversions.
           }
      ```
      
      The lexer exposes a helper function to add an annotation
      
      ```lang=haskell
      addAnnotation :: SrcSpan -> Ann -> SrcSpan -> P ()
      addAnnotation l a v = P $ \s -> POk s {
        annotations = ((AK l a), v) : annotations s
        } ()
      
      ```
      
      The parser also has some helper functions of the form
      
      ```lang=haskell
      type MaybeAnn = Maybe (SrcSpan -> P ())
      
      gl = getLoc
      gj x = Just (gl x)
      
      ams :: Located a -> [MaybeAnn] -> P (Located a)
      ams a@(L l _) bs = (mapM_ (\a -> a l) $ catMaybes bs) >> return a
      ```
      
      This allows annotations to be captured in the parser by means of
      
      ```
      ctypedoc :: { LHsType RdrName }
              : 'forall' tv_bndrs '.' ctypedoc {% hintExplicitForall (getLoc $1) >>
                                                  ams (LL $ mkExplicitHsForAllTy $2 (noLoc []) $4)
                                                      [mj AnnForall $1,mj AnnDot $3] }
              | context '=>' ctypedoc         {% ams (LL $ mkQualifiedHsForAllTy   $1 $3)
                                                     [mj AnnDarrow $2] }
              | ipvar '::' type               {% ams (LL (HsIParamTy (unLoc $1) $3))
                                                     [mj AnnDcolon $2] }
              | typedoc                       { $1 }
      ```
      
      == Parse result ==
      
      ```lang-haskell
      data HsParsedModule = HsParsedModule {
          hpm_module    :: Located (HsModule RdrName),
          hpm_src_files :: [FilePath],
             -- ^ extra source files (e.g. from #includes).  The lexer collects
             -- these from '# <file> <line>' pragmas, which the C preprocessor
             -- leaves behind.  These files and their timestamps are stored in
             -- the .hi file, so that we can force recompilation if any of
             -- them change (#3589)
          hpm_annotations :: ApiAnns
        }
      
      -- | The result of successful parsing.
      data ParsedModule =
        ParsedModule { pm_mod_summary   :: ModSummary
                     , pm_parsed_source :: ParsedSource
                     , pm_extra_src_files :: [FilePath]
                     , pm_annotations :: ApiAnns }
      ```
      
      This diff depends on D426
      
      Test Plan: sh ./validate
      
      Reviewers: austin, simonpj, Mikolaj
      
      Reviewed By: simonpj, Mikolaj
      
      Subscribers: Mikolaj, goldfire, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D438
      
      GHC Trac Issues: #9628
      803fc5db
    • Alan Zimmerman's avatar
      AST changes to prepare for API annotations, for #9628 · 7927658e
      Alan Zimmerman authored
      Summary:
      AST changes to prepare for API annotations
      
      Add locations to parts of the AST so that API annotations can
      then be added.
      
      The outline of the whole process is captured here
      https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations
      
      This change updates the haddock submodule.
      
      Test Plan: sh ./validate
      
      Reviewers: austin, simonpj, Mikolaj
      
      Reviewed By: simonpj, Mikolaj
      
      Subscribers: thomie, goldfire, carter
      
      Differential Revision: https://phabricator.haskell.org/D426
      
      GHC Trac Issues: #9628
      7927658e
  11. 13 Nov, 2014 1 commit
  12. 06 Nov, 2014 1 commit
  13. 24 Oct, 2014 1 commit
    • Edward Z. Yang's avatar
      Implementation of hsig (module signatures), per #9252 · aa479953
      Edward Z. Yang authored
      Summary:
      Module signatures, like hs-boot files, are Haskell modules which omit
      value definitions and contain only signatures.  This patchset implements
      one particular aspect of module signature, namely compiling them against
      a concrete implementation.  It works like this: when we compile an hsig
      file, we must be told (via the -sig-of flag) what module this signature
      is implementing.  The signature is compiled into an interface file which
      reexports precisely the entities mentioned in the signature file.  We also
      verify that the interface is compatible with the implementation.
      
      This feature is useful in a few situations:
      
          1. Like explicit import lists, signatures can be used to reduce
          sensitivity to upstream changes.  However, a signature can be defined
          once and then reused by many modules.
      
          2. Signatures can be used to quickly check if a new upstream version
          is compatible, by typechecking just the signatures and not the actual
          modules.
      
          3. A signature can be used to mediate separate modular development,
          where the signature is used as a placeholder for functionality which
          is loaded in later.  (This is only half useful at the moment, since
          typechecking against signatures without implementations is not implemented
          in this patchset.)
      
      Unlike hs-boot files, hsig files impose no performance overhead.
      
      This patchset punts on the type class instances (and type families) problem:
      instances simply leak from the implementation to the signature.  You can
      explicitly specify what instances you expect to have, and those will be checked,
      but you may get more instances than you asked for.  Our eventual plan is
      to allow hiding instances, but to consider all transitively reachable instances
      when considering overlap and soundness.
      
      ToDo: signature merging: when a module is provided by multiple signatures
      for the same base implementation, we should not consider this ambiguous.
      
      ToDo: at the moment, signatures do not constitute use-sites, so if you
      write a signature for a deprecated function, you won't get a warning
      when you compile the signature.
      
      Future work: The ability to feed in shaping information so that we can take
      advantage of more type equalities than might be immediately evident.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate and new tests
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, ezyang, carter, goldfire
      
      Differential Revision: https://phabricator.haskell.org/D130
      
      GHC Trac Issues: #9252
      aa479953
  14. 05 Aug, 2014 3 commits
    • Edward Z. Yang's avatar
      Thinning and renaming modules from packages on the command line. · 20787529
      Edward Z. Yang authored
      Summary:
      This patch set adds support for extra syntax on -package and related
      arguments which allow you to thin and rename modules from a package.
      For example, this argument:
      
          -package "base (Data.Bool as Bam, Data.List)"
      
      adds two more modules into scope, Bam and Data.List, without adding
      any of base's other modules to scope.
      
      These flags are additive: so, for example, saying:
      
          -hide-all-packages -package base -package "base (Data.Bool as Bam)"
      
      will provide both the normal bindings for modules in base, as well as
      the module Bam.
      
      There is also a new debug flag -ddump-mod-map which prints the state
      of the module mapping database.  H = hidden, E = exposed (so for
      example EH says the module in question is exported, but in a hidden
      package.)
      
      Module suggestions have been minorly overhauled to work better with reexports:
      if you have -package "base (Data.Bool as Bam)" and mispell Bam, GHC
      will suggest "Did you mean Bam (defined via package flags to be
      base:Data.Bool)"; and generally you will get more accurate information.
      Also, fix a bug where we suggest the -package flag when we really need
      the -package-key flag.
      
      NB: The renaming afforded here does *not* affect what wired in
      symbols GHC generates.  (But it does affect implicit prelude!)
      
      ToDo: add 'hiding' functionality, to make it easier to support the alternative
      prelude use-case.
      
      ToDo: Cabal support
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: new tests and validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D113
      
      GHC Trac Issues: #9375
      20787529
    • Edward Z. Yang's avatar
      Make PackageState an abstract type. · de3f0644
      Edward Z. Yang authored
      Summary: Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D107
      de3f0644
    • Edward Z. Yang's avatar
      Package keys (for linking/type equality) separated from package IDs. · 66218d15
      Edward Z. Yang authored
      This patch set makes us no longer assume that a package key is a human
      readable string, leaving Cabal free to "do whatever it wants" to allocate
      keys; we'll look up the PackageId in the database to display to the user.
      This also means we have a new level of qualifier decisions to make at the
      package level, and rewriting some Safe Haskell error reporting code to DTRT.
      
      Additionally, we adjust the build system to use a new ghc-cabal output
      Make variable PACKAGE_KEY to determine library names and other things,
      rather than concatenating PACKAGE/VERSION as before.
      
      Adds a new `-this-package-key` flag to subsume the old, erroneously named
      `-package-name` flag, and `-package-key` to select packages by package key.
      
      RFC: The md5 hashes are pretty tough on the eye, as far as the file
      system is concerned :(
      
      ToDo: safePkg01 test had its output updated, but the fix is not really right:
      the rest of the dependencies are truncated due to the fact the we're only
      grepping a single line, but ghc-pkg is wrapping its output.
      
      ToDo: In a later commit, update all submodules to stop using -package-name
      and use -this-package-key.  For now, we don't do it to avoid submodule
      explosion.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D80
      66218d15
  15. 02 Aug, 2014 1 commit
  16. 21 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Rename PackageId to PackageKey, distinguishing it from Cabal's PackageId. · 4bebab25
      Edward Z. Yang authored
      Summary:
      Previously, both Cabal and GHC defined the type PackageId, and we expected
      them to be roughly equivalent (but represented differently).  This refactoring
      separates these two notions.
      
      A package ID is a user-visible identifier; it's the thing you write in a
      Cabal file, e.g. containers-0.9.  The components of this ID are semantically
      meaningful, and decompose into a package name and a package vrsion.
      
      A package key is an opaque identifier used by GHC to generate linking symbols.
      Presently, it just consists of a package name and a package version, but
      pursuant to #9265 we are planning to extend it to record other information.
      Within a single executable, it uniquely identifies a package.  It is *not* an
      InstalledPackageId, as the choice of a package key affects the ABI of a package
      (whereas an InstalledPackageId is computed after compilation.)  Cabal computes
      a package key for the package and passes it to GHC using -package-name (now
      *extremely* misnamed).
      
      As an added bonus, we don't have to worry about shadowing anymore.
      
      As a follow on, we should introduce -current-package-key having the same role as
      -package-name, and deprecate the old flag.  This commit is just renaming.
      
      The haddock submodule needed to be updated.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D79
      
      Conflicts:
      	compiler/main/HscTypes.lhs
      	compiler/main/Packages.lhs
      	utils/haddock
      4bebab25
  17. 27 Jun, 2014 2 commits
  18. 26 Jun, 2014 1 commit
  19. 08 Jun, 2014 1 commit
  20. 30 May, 2014 1 commit
  21. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
      23892440
  22. 03 May, 2014 1 commit
  23. 23 Mar, 2014 1 commit
    • Simon Peyton Jones's avatar
      Simplify handling of the interactive package; fixes Trac #8831 · 28e8d878
      Simon Peyton Jones authored
      This patch is really a fix to the big commint
         73c08ab1
         Re-work the naming story for the GHCi prompt (Trac #8649)
      which introduced the 'interactive' package
      See Note [The interactive package] in HscTypes
      
      The original commit set both
        (a) The tcg_mod field of TcGblEnv to 'interactive:Ghci4' (say)
        (b) The thisPackage field of DynFlags to 'interactive'
      
      But the second step interacts badly with linking.  :loaded modules are
      in the package set by 'thisPackage' (usually 'main'); if you change
      that, then we try to link package 'main', but can't find it, and
      that is what happened in #8831.
      
      The fix was simple: do (a) but not (b).
      
      I changed Note [The interactive package] in HscTypes to describe this.
      28e8d878
  24. 20 Jan, 2014 1 commit
    • cactus's avatar
      Implement pattern synonyms · 4f8369bf
      cactus authored
      This patch implements Pattern Synonyms (enabled by -XPatternSynonyms),
      allowing y ou to assign names to a pattern and abstract over it.
      
      The rundown is this:
      
        * Named patterns are introduced by the new 'pattern' keyword, and can
          be either *unidirectional* or *bidirectional*. A unidirectional
          pattern is, in the simplest sense, simply an 'alias' for a pattern,
          where the LHS may mention variables to occur in the RHS. A
          bidirectional pattern synonym occurs when a pattern may also be used
          in expression context.
      
        * Unidirectional patterns are declared like thus:
      
              pattern P x <- x:_
      
          The synonym 'P' may only occur in a pattern context:
      
              foo :: [Int] -> Maybe Int
              foo (P x) = Just x
              foo _     = Nothing
      
        * Bidirectional patterns are declared like thus:
      
              pattern P x y = [x, y]
      
          Here, P may not only occur as a pattern, but also as an expression
          when given values for 'x' and 'y', i.e.
      
              bar :: Int -> [Int]
              bar x = P x 10
      
        * Patterns can't yet have their own type signatures; signatures are inferred.
      
        * Pattern synonyms may not be recursive, c.f. type synonyms.
      
        * Pattern synonyms are also exported/imported using the 'pattern'
          keyword in an import/export decl, i.e.
      
              module Foo (pattern Bar) where ...
      
          Note that pattern synonyms share the namespace of constructors, so
          this disambiguation is required as a there may also be a 'Bar'
          type in scope as well as the 'Bar' pattern.
      
        * The semantics of a pattern synonym differ slightly from a typical
          pattern: when using a synonym, the pattern itself is matched,
          followed by all the arguments. This means that the strictness
          differs slightly:
      
              pattern P x y <- [x, y]
      
              f (P True True) = True
              f _             = False
      
              g [True, True] = True
              g _            = False
      
          In the example, while `g (False:undefined)` evaluates to False,
          `f (False:undefined)` results in undefined as both `x` and `y`
          arguments are matched to `True`.
      
      For more information, see the wiki:
      
          https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms
          https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/ImplementationReviewed-by: Simon Peyton Jones's avatarSimon Peyton Jones <simonpj@microsoft.com>
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      4f8369bf
  25. 09 Jan, 2014 1 commit
    • Simon Peyton Jones's avatar
      Re-work the naming story for the GHCi prompt (Trac #8649) · 73c08ab1
      Simon Peyton Jones authored
      The basic idea here is simple, and described in Note [The interactive package]
      in HscTypes, which starts thus:
      
          Note [The interactive package]
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          Type and class declarations at the command prompt are treated as if
          they were defined in modules
             interactive:Ghci1
             interactive:Ghci2
             ...etc...
          with each bunch of declarations using a new module, all sharing a
          common package 'interactive' (see Module.interactivePackageId, and
          PrelNames.mkInteractiveModule).
      
          This scheme deals well with shadowing.  For example:
      
             ghci> data T = A
             ghci> data T = B
             ghci> :i A
             data Ghci1.T = A  -- Defined at <interactive>:2:10
      
          Here we must display info about constructor A, but its type T has been
          shadowed by the second declaration.  But it has a respectable
          qualified name (Ghci1.T), and its source location says where it was
          defined.
      
          So the main invariant continues to hold, that in any session an original
          name M.T only refers to oe unique thing.  (In a previous iteration both
          the T's above were called :Interactive.T, albeit with different uniques,
          which gave rise to all sorts of trouble.)
      
      This scheme deals nicely with the original problem.  It allows us to
      eliminate a couple of grotseque hacks
        - Note [Outputable Orig RdrName] in HscTypes
        - Note [interactive name cache] in IfaceEnv
      (both these comments have gone, because the hacks they describe are no
      longer necessary). I was also able to simplify Outputable.QueryQualifyName,
      so that it takes a Module/OccName as args rather than a Name.
      
      However, matters are never simple, and this change took me an
      unreasonably long time to get right.  There are some details in
      Note [The interactive package] in HscTypes.
      73c08ab1
  26. 03 Jan, 2014 1 commit
    • Simon Peyton Jones's avatar
      Refactor the way shadowing in handled in GHCi · 5dffb4ac
      Simon Peyton Jones authored
      If you say
        ghci> import Foo( T )
        ghci> data T = MkT
        ghci> data T = XXX
      then the second 'data T' should shadow the first.  But the qualified
      Foo.T should still be available.  We really weren't handling this
      correctly at all, resulting in Trac #8639 and #8628 among others
      
      This patch:
      
      * Add RdrName.extendGlobalRdrEnv, which does shadowing properly
      
      * Change HscTypes.icExtendGblRdrEnv (was badly-named icPlusGblRdrEnv)
        to use the new function
      
      * Change RnNames.extendGobalRdrEnvRn to use the new function
      
      * Move gresFrom Avails into RdrName
      * Better pprGlobalRdrEnv function in RdrName
      5dffb4ac
  27. 03 Dec, 2013 1 commit
  28. 28 Nov, 2013 1 commit
    • Simon Peyton Jones's avatar
      More faff to get GHCi's top-level environment right · f3a84161
      Simon Peyton Jones authored
      This fixes #8540 (again), and simplifies matters a bit more. In
      particular, I got rid of ic_sys_vars altogether.  Mostly they can just
      go in ic_tythings, apart from dfuns, which are readily gettable from
      the instances anyway.
      
      See documentation in Note [Initialising the type environment for GHCi]
      in TcEnv.
      f3a84161
  29. 21 Nov, 2013 1 commit
  30. 23 Oct, 2013 1 commit
  31. 16 Oct, 2013 2 commits
  32. 22 Sep, 2013 1 commit
  33. 11 Sep, 2013 1 commit
  34. 03 Sep, 2013 1 commit
    • Simon Peyton Jones's avatar
      Improve Linting in GHCi (fixes Trac #8215) · dfa8ef03
      Simon Peyton Jones authored
      The original problem was that we weren't bringing varaibles bound in the
      interactive context into scope before Linting the result of a top-level
      declaration in GHCi.  (We were doing this for expressions.)
      
      Moreover I found that we weren't Linting the result of desugaring
      a GHCi expression, which we really should be doing.
      
      It took me a bit of time to unravel all this, and I did some refactoring
      to make it easier next time.
      
        * CoreMonad contains the Lint wrappers that get the right
          environments into place.  It always had endPass and lintPassResult
          (which Lints bindings), but now it has lintInteractiveExpr.
      
        * Both use a common function CoreMonad.interactiveInScope to find
          those in-scope variables.
      
      Quite a bit of knock-on effects from this, but nothing exciting.
      dfa8ef03