summaryrefslogtreecommitdiff
path: root/docs/users_guide/8.10.1-notes.rst
Commit message (Collapse)AuthorAgeFilesLines
* users-guide: Drop old release notesBen Gamari2020-02-241-388/+0
|
* users-guide: Shuffle textBen Gamari2020-02-241-18/+16
|
* users-guide: Mention dependency on `exceptions` in release notesBen Gamari2020-02-201-0/+1
| | | | Fixes #17845.
* 8.10 Release notes for --disable-delayed-os-memory-return [skip ci]Niklas Hambüchen2020-02-201-0/+15
|
* 8.10 Release notes for atomic .o writes [skip ci]Niklas Hambüchen2020-02-201-0/+15
|
* users-guide: Fix broken referenceBen Gamari2020-02-141-1/+1
|
* users-guide: Fix unknown link targetsBen Gamari2020-02-141-2/+2
|
* 8.10 Release notes for improvements to the pattern-match checker [skip ci]Sebastian Graf2020-02-091-0/+14
| | | | A little late to the game, but better late than never.
* Switch to ReadTheDocs theme for the user-guideSylvain Henry2019-12-251-2/+2
|
* Make warnings for TH splices opt-inSebastian Graf2019-11-271-1/+12
| | | | | | | | | | | | | | | | | | | | | | | In #17270 we have the pattern-match checker emit incorrect warnings. The reason for that behavior is ultimately an inconsistency in whether we treat TH splices as written by the user (`FromSource :: Origin`) or as generated code (`Generated`). This was first reported in #14838. The current solution is to TH splices as `Generated` by default and only treat them as `FromSource` when the user requests so (-fenable-th-splice-warnings). There are multiple reasons for opt-in rather than opt-out: * It's not clear that the user that compiles a splice is the author of the code that produces the warning. Think of the situation where she just splices in code from a third-party library that produces incomplete pattern matches. In this scenario, the user isn't even able to fix that warning. * Gathering information for producing the warnings (pattern-match check warnings in particular) is costly. There's no point in doing so if the user is not interested in those warnings. Fixes #17270, but not #14838, because the proper solution needs a GHC proposal extending the TH AST syntax.
* rts: Expose interface for configuring EventLogWritersBen Gamari2019-11-231-0/+4
| | | | | | This exposes a set of interfaces from the GHC API for configuring EventLogWriters. These can be used by consumers like [ghc-eventlog-socket](https://github.com/bgamari/ghc-eventlog-socket).
* Update release notes about #16512 / #17405.Richard Eisenberg2019-11-101-0/+12
|
* Clean up TH's treatment of unary tuples (or, #16881 part two)Ryan Scott2019-11-071-3/+6
| | | | | | | | | | | | | | !1906 left some loose ends in regards to Template Haskell's treatment of unary tuples. This patch ends to tie up those loose ends: * In addition to having `TupleT 1` produce unary tuples, `TupE [exp]` and `TupP [pat]` also now produce unary tuples. * I have added various special cases in GHC's pretty-printers to ensure that explicit 1-tuples are printed using the `Unit` type. See `testsuite/tests/th/T17380`. * The GHC 8.10.1 release notes entry has been tidied up a little. Fixes #16881. Fixes #17371. Fixes #17380.
* rts/linker: Ensure that code isn't writableBen Gamari2019-11-041-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | For many years the linker would simply map all of its memory with PROT_READ|PROT_WRITE|PROT_EXEC. However operating systems have been becoming increasingly reluctant to accept this practice (e.g. #17353 and #12657) and for good reason: writable code is ripe for exploitation. Consequently mmapForLinker now maps its memory with PROT_READ|PROT_WRITE. After the linker has finished filling/relocating the mapping it must then call mmapForLinkerMarkExecutable on the sections of the mapping which contain executable code. Moreover, to make all of this possible it was necessary to redesign the m32 allocator. First, we gave (in an earlier commit) each ObjectCode its own m32_allocator. This was necessary since code loading and symbol resolution/relocation are currently interleaved, meaning that it is not possible to enforce W^X when symbols from different objects reside in the same page. We then redesigned the m32 allocator to take advantage of the fact that all of the pages allocated with the allocator die at the same time (namely, when the owning ObjectCode is unloaded). This makes a number of things simpler (e.g. no more page reference counting; the interface provided by the allocator for freeing is simpler). See Note [M32 Allocator] for details.
* users-guide: Add some new features and fix warnings for GHC 8.10Takenobu Tani2019-10-291-2/+10
| | | | | | | | | | This updates the following: * Add description for ImportQualifiedPost extension * Add description for ghci command name resolution * Fix markdown warnings [skip ci]
* Fix RankNTypes :ghc-flag: in users guideLuke Lau2019-10-271-2/+2
| | | | This fixes a hadrian `build docs` failure
* eventlog: Dump cost centre stack on each sampleMatthew Pickering2019-10-231-0/+3
| | | | | | | | | | | | | | | | With this change it is possible to reconstruct the timing portion of a `.prof` file after the fact. By logging the stacks at each time point a more precise executation trace of the program can be observed rather than all identical cost centres being identified in the report. There are two new events: 1. `EVENT_PROF_BEGIN` - emitted at the start of profiling to communicate the tick interval 2. `EVENT_PROF_SAMPLE_COST_CENTRE` - emitted on each tick to communicate the current call stack. Fixes #17322
* compiler: introduce DynFlags pluginsAlp Mestanogullari2019-10-231-0/+6
| | | | | | | | | | | | | | | | They have type '[CommandLineOpts] -> Maybe (DynFlags -> IO DynFlags)'. All plugins that supply a non-Nothing 'dynflagsPlugin' will see their updates applied to the current DynFlags right after the plugins are loaded. One use case for this is to superseede !1580 for registering hooks from a plugin. Frontend/parser plugins were considered to achieve this but they respectively conflict with how this plugin is going to be used and don't allow overriding/modifying the DynFlags, which is how hooks have to be registered. This commit comes with a test, 'test-hook-plugin', that registers a "fake" meta hook that replaces TH expressions with the 0 integer literal.
* Windows: Update tarballs to GCC 9.2 and remove MAX_PATH limit.Tamar Christina2019-10-201-0/+4
|
* Mention changes from #16980, #17213 in 8.10.1 release notesRyan Scott2019-10-141-5/+59
| | | | | | | | The fixes for these issues both have user-facing consequences, so it would be good to mention them in the release notes for GHC 8.10.1. While I'm in town, also mention `UnboxedSums` in the release notes entry related to `-fobject-code`.
* Template Haskell: make unary tuples legal (#16881)nineonine2019-10-131-0/+4
|
* users-guide: Fix various warningsBen Gamari2019-10-081-1/+1
|
* users-guide: Refer to language extension flags via :extension:Ben Gamari2019-10-081-1/+1
| | | | Previously several were referred to via :ghc-flag:`-X...`.
* Deprecate -fwarn-hi-shadowing, because it was never implemented and isDaroc Alden2019-10-041-0/+4
| | | | | | not used. This fixes #10913.
* Make -fbyte-code prevent unboxed tuples/sums from implying object code (#16876)Ryan Scott2019-09-261-5/+6
| | | | | | | | | | | | | | | | | | | | This resolves #16876 by making the explicit use of `-fbyte-code` prevent code that enables `UnboxedTuples` or `UnboxedSums` from automatically compiling to object code. This allows for a nice middle ground where most code that enables `UnboxedTuples`/-`Sums` will still benefit from automatically enabling `-fobject-code`, but allows power users who wish to avoid this behavior in certain corner cases (such as `lens`, whose use case is documented in #16876) to do so. Along the way, I did a little cleanup of the relevant code and documentation: * `enableCodeGenForUnboxedTuples` was only checking for the presence of `UnboxedTuples`, but `UnboxedSums` has the same complications. I fixed this and renamed the function to `enableCodeGenForUnboxedTuplesOrSums`. * I amended the users' guide with a discussion of these issues.
* Standalone kind signatures (#16794)wip/top-level-kind-signaturesVladislav Zavialov2019-09-251-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Add -Wderiving-defaults (#15839)Kari Pahula2019-09-251-0/+10
| | | | | | Enabling both DeriveAnyClass and GeneralizedNewtypeDeriving can cause a warning when no explicit deriving strategy is in use. This change adds an enable/suppress flag for it.
* Add -fkeep-going to make compiler continue despite errors (#15424)Kari Pahula2019-09-231-0/+3
| | | | | Add a new optional failure handling for upsweep which continues the compilation on other modules if any of them has errors.
* users-guide: Fix links and formats for GHC 8.10Takenobu Tani2019-09-231-12/+12
| | | | | | This commit only fixes links and markdown syntax. [skip ci]
* eventlog: Add biographical and retainer profiling tracesMatthew Pickering2019-09-171-0/+5
| | | | | | | | | | This patch adds a new eventlog event which indicates the start of a biographical profiler sample. These are different to normal events as they also include the timestamp of when the census took place. This is because the LDV profiler only emits samples at the end of the run. Now all the different profiling modes emit consumable events to the eventlog.
* Balance parentheses in GHC 8.10.1 release notesRyan Scott2019-08-281-3/+3
| | | | [ci skip]
* Bump containers submodule to v0.6.2.1Ben Gamari2019-06-251-1/+1
|
* Implement the -XUnliftedNewtypes extension.Andrew Martin2019-06-141-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | GHC Proposal: 0013-unlifted-newtypes.rst Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/98 Issues: #15219, #1311, #13595, #15883 Implementation Details: Note [Implementation of UnliftedNewtypes] Note [Unifying data family kinds] Note [Compulsory newtype unfolding] This patch introduces the -XUnliftedNewtypes extension. When this extension is enabled, GHC drops the restriction that the field in a newtype must be of kind (TYPE 'LiftedRep). This allows types like Int# and ByteArray# to be used in a newtype. Additionally, coerce is made levity-polymorphic so that it can be used with newtypes over unlifted types. The bulk of the changes are in TcTyClsDecls.hs. With -XUnliftedNewtypes, getInitialKind is more liberal, introducing a unification variable to return the kind (TYPE r0) rather than just returning (TYPE 'LiftedRep). When kind-checking a data constructor with kcConDecl, we attempt to unify the kind of a newtype with the kind of its field's type. When typechecking a data declaration with tcTyClDecl, we again perform a unification. See the implementation note for more on this. Co-authored-by: Richard Eisenberg <rae@richarde.dev>
* Add disable/enable commands to ghci debugger #2215Roland Senn2019-06-091-1/+4
| | | | | | | | | | | | | | | | | | | | This patch adds two new commands `:enable` and `:disable` to the GHCi debugger. Opposite to `:set stop <n> :continue` a breakpoint disabled with `:disable` will not loose its previously set stop command. A new field breakEnabled is added to the BreakLocation data structure to track the enable/disable state. When a breakpoint is disabled with a `:disable` command, the following happens: The corresponding BreakLocation data element is searched dictionary of the `breaks` field of the GHCiStateMonad. If the break point is found and not already in the disabled state, the breakpoint is removed from bytecode. The BreakLocation data structure is kept in the breaks list and the new breakEnabled field is set to false. The `:enable` command works similar. The breaks field in the GHCiStateMonad was changed from an association list to int `IntMap`.
* Add GHCi :instances commandXavier Denis2019-06-041-0/+5
| | | | | | | | | | | This commit adds the `:instances` command to ghci following proosal number 41. This makes it possible to query which instances are available to a given type. The output of this command is all the possible instances with type variables and constraints instantiated.
* Fix some warnings in users_guide (incl #16640)Oleg Grenrus2019-05-291-2/+2
| | | | | | | | | | | | | | - short underline - :ghc-flag:, not :ghc-flags: - :since: have to be separate - newline before code block - workaround anchor generation so - pragma:SPECIALISE - pragma:SPECIALIZE-INLINE - pragma:SPECIALIZE-inline are different anchors, not all the same `pragma:SPECIALIZE`
* Use HsTyPats in associated type family defaultsRyan Scott2019-05-221-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Have GHCi use object code for UnboxedTuples modules #15454Michael Sloan2019-05-221-0/+7
| | | | | | | | | | | | The idea is to automatically enable -fobject-code for modules that use UnboxedTuples, along with all the modules they depend on. When looking into how to solve this, I was pleased to find that there was already highly similar logic for enabling code generation when -fno-code is specified but TemplateHaskell is used. The state before this patch was that if you used unboxed tuples then you had to enable `-fobject-code` globally rather than on a per module basis.
* Allow for multiple linker instances. Fixes Haskell portion of #3372.Julian Leviston2019-05-211-0/+4
|
* users-guide: Add libraries section to 8.10.1 release notesBen Gamari2019-04-211-0/+40
|
* TH: make `Lift` and `TExp` levity-polymorphicAlec Theriault2019-04-181-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Besides the obvious benefits of being able to manipulate `TExp`'s of unboxed types, this also simplified `-XDeriveLift` all while making it more capable. * `ghc-prim` is explicitly depended upon by `template-haskell` * The following TH things are parametrized over `RuntimeRep`: - `TExp(..)` - `unTypeQ` - `unsafeTExpCoerce` - `Lift(..)` * The following instances have been added to `Lift`: - `Int#`, `Word#`, `Float#`, `Double#`, `Char#`, `Addr#` - unboxed tuples of lifted types up to arity 7 - unboxed sums of lifted types up to arity 7 Ideally we would have levity-polymorphic _instances_ of unboxed tuples and sums. * The code generated by `-XDeriveLift` uses expression quotes instead of generating large amounts of TH code and having special hard-coded cases for some unboxed types.
* docs: mention memcpy optimization for ByteArrays in 8.10.1-notesArtem Pyanykh2019-04-141-4/+5
|
* docs: add a note about changes in memset unrolling to 8.10.1-notesArtem Pyanykh2019-04-091-0/+5
|
* Add support for bitreverse primopAlexandre2019-04-011-0/+4
| | | | | | This commit includes the necessary changes in code and documentation to support a primop that reverses a word's bits. It also includes a test.
* Visible dependent quantificationRyan Scott2019-03-011-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements GHC proposal 35 (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst) by adding the ability to write kinds with visible dependent quantification (VDQ). Most of the work for supporting VDQ was actually done _before_ this patch. That is, GHC has been able to reason about kinds with VDQ for some time, but it lacked the ability to let programmers directly write these kinds in the source syntax. This patch is primarly about exposing this ability, by: * Changing `HsForAllTy` to add an additional field of type `ForallVisFlag` to distinguish between invisible `forall`s (i.e, with dots) and visible `forall`s (i.e., with arrows) * Changing `Parser.y` accordingly The rest of the patch mostly concerns adding validity checking to ensure that VDQ is never used in the type of a term (as permitting this would require full-spectrum dependent types). This is accomplished by: * Adding a `vdqAllowed` predicate to `TcValidity`. * Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy` that only splits invisible `forall`s. This function is used in certain places (e.g., in instance declarations) to ensure that GHC doesn't try to split visible `forall`s (e.g., if it tried splitting `instance forall a -> Show (Blah a)`, then GHC would mistakenly allow that declaration!) This also updates Template Haskell by introducing a new `ForallVisT` constructor to `Type`. Fixes #16326. Also fixes #15658 by documenting this feature in the users' guide.
* Treat kind/type variables identically, demolish FKTVVladislav Zavialov2019-02-271-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst Fixes Trac #16334, Trac #16315 With this patch, scoping rules for type and kind variables have been unified: kind variables no longer receieve special treatment. This simplifies both the language and the implementation. User-facing changes ------------------- * Kind variables are no longer implicitly quantified when an explicit forall is used: p :: Proxy (a :: k) -- still accepted p :: forall k a. Proxy (a :: k) -- still accepted p :: forall a. Proxy (a :: k) -- no longer accepted In other words, now we adhere to the "forall-or-nothing" rule more strictly. Related function: RnTypes.rnImplicitBndrs * The -Wimplicit-kind-vars warning has been deprecated. * Kind variables are no longer implicitly quantified in constructor declarations: data T a = T1 (S (a :: k) | forall (b::k). T2 (S b) -- no longer accepted data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b) -- still accepted Related function: RnTypes.extractRdrKindSigVars * Implicitly quantified kind variables are no longer put in front of other variables: f :: Proxy (a :: k) -> Proxy (b :: j) f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b -- old order f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b -- new order This is a breaking change for users of TypeApplications. Note that we still respect the dpendency order: 'k' before 'a', 'j' before 'b'. See "Ordering of specified variables" in the User's Guide. Related function: RnTypes.rnImplicitBndrs * In type synonyms and type family equations, free variables on the RHS are no longer implicitly quantified unless used in an outermost kind annotation: type T = Just (Nothing :: Maybe a) -- no longer accepted type T = Just Nothing :: Maybe (Maybe a) -- still accepted The latter form is a workaround due to temporary lack of an explicit quantification method. Ideally, we would write something along these lines: type T @a = Just (Nothing :: Maybe a) Related function: RnTypes.extractHsTyRdrTyVarsKindVars * Named wildcards in kinds are fixed (Trac #16334): x :: (Int :: _t) -- this compiles, infers (_t ~ Type) Related function: RnTypes.partition_nwcs Implementation notes -------------------- * One of the key changes is the removal of FKTV in RnTypes: - data FreeKiTyVars = FKTV { fktv_kis :: [Located RdrName] - , fktv_tys :: [Located RdrName] } + type FreeKiTyVars = [Located RdrName] We used to keep track of type and kind variables separately, but now that they are on equal footing when it comes to scoping, we can put them in the same list. * extract_lty and family are no longer parametrized by TypeOrKind, as we now do not distinguish kind variables from type variables. * PatSynExPE and the related Note [Pattern synonym existentials do not scope] have been removed (Trac #16315). With no implicit kind quantification, we can no longer trigger the error. * reportFloatingKvs and the related Note [Free-floating kind vars] have been removed. With no implicit kind quantification, we can no longer trigger the error.
* Implement -Wredundant-record-wildcards and -Wunused-record-wildcardsMatthew Pickering2019-02-141-0/+45
-Wredundant-record-wildcards warns when a .. pattern binds no variables. -Wunused-record-wildcards warns when none of the variables bound by a .. pattern are used. These flags are enabled by `-Wall`.
View Lorry Controller Status