- Apr 05, 2019
-
-
Ara Adkins authored[skip ci] Update the CI badge in the readme. See merge request !3
-
Ara Adkins authored
-
- Apr 04, 2019
-
-
A simple oversight. Fixes #16527.
-
This patch corrects two simple oversights that led to #16518: 1. `HsUtils.typeToLHsType` was taking visibility into account in the `TyConApp` case, but not the `AppTy` case. I've factored out the visibility-related logic into its own `go_app` function and now invoke `go_app` from both the `TyConApp` and `AppTy` cases. 2. `Type.fun_kind_arg_flags` did not properly split kinds with nested `forall`s, such as `(forall k. k -> Type) -> (forall k. k -> Type)`. This was simply because `fun_kind_arg_flags`'s `FunTy` case always bailed out and assumed all subsequent arguments were `Required`, which clearly isn't the case for nested `forall`s. I tweaked the `FunTy` case to recur on the result kind.
-
-
- Apr 03, 2019
-
-
Ben Gamari authored
-
Ben Gamari authored
Fixes #16445.
-
Issues #16289 and #15713 are proof that the pattern match checker did an unsound job of estimating the value set abstraction corresponding to the uncovered set. The reason is that the fix from #11303 introducing `NLit` was incomplete: The `LitCon` case desugared to `Var` rather than `LitVar`, which would have done the necessary case splitting analogous to the `ConVar` case. This patch rectifies that by introducing the fresh unification variable in `LitCon` in value abstraction position rather than pattern postition, recording a constraint equating it to the constructor expression rather than the literal. Fixes #16289 and #15713.
-
This fixes #16440, where the build system incorrectly concluded that the `.subsections_via_symbols` assembler directive was supported on a Linux system. This was caused by the fact that gcc was invoked with `-flto`; when so-configured gcc does not call the assembler but rather simply serialises its AST for compilation during the final link. This is described in Note [autoconf assembler checks and -flto].
-
The law as it is currently written is meaningless, because nowhere have we defined the implementation of 'ap'. The reader of the Control.Monad documentation is provided with only a type signature, > ap :: Monad m => m (a -> b) -> m a -> m b an informal description, > In many situations, the liftM operations can be replaced by uses of > ap, which promotes function application. and a relationship between 'ap' and the 'liftM' functions > return f `ap` x1 `ap` ... `ap` xn > is equivalent to > liftMn f x1 x2 ... xn Without knowing how 'ap' is defined, a law involving 'ap' cannot provide any guidance for how to write a lawful Monad instance, nor can we conclude anything from the law. I suspect that a reader equipped with the understanding that 'ap' was defined prior to the invention of the Applicative class could deduce that 'ap' must be defined in terms of (>>=), but nowhere as far as I can tell have we written this down explicitly for readers without the benefit of historical context. If the law is meant to express a relationship among (<*>), (>>=), and 'return', it seems that it is better off making this statement directly, sidestepping 'ap' altogether.
-
-
-
-
-
-
-
`substBndr` should rename bindings which shadow existing ids. However while it was renaming the bindings it was not adding proper substitutions for renamed bindings. Instead of adding a substitution of the form `old -> new` for renamed bindings it mistakenly added `old -> old` if no replacement had taken place while adding none if `old` had been renamed. As a byproduct this should improve performance, as we no longer add useless substitutions for unshadowed bindings.
-
- Apr 02, 2019
-
-
-
-
-
-
Previously, when needing ghc as a builder, the ghcDeps (Files the GHC binary depends on) for the current stage were needed. This is incorrect as the previous stage's ghc is used for building. This commit fixes the issue, needing the previous stage's ghcDeps.
-
This: - Hoists part of the condition outside of the initialization loop in `stg_newSmallArrayzh`. - Annotates one of the unlikely branches as unlikely, also in `stg_newSmallArrayzh`. - Adds a couple of annotations to `allocateMightFail` indicating which branches are likely to be taken. Together this gives about 5% improvement. Signed-off-by:Michal Terepeta <michal.terepeta@gmail.com>
-
This bumps `array` to version 0.5.4.0 so that we can distinguish it with `MIN_VERSION_array` (as it introduces some changes to the `Show` instance for `UArray`).
-
- Apr 01, 2019
-
-
Ben Gamari authored
-
Ben Gamari authored
Whoops.
-
Ben Gamari authored
-
-
This moves URL references to old Trac to their corresponding GitLab counterparts. This patch does not update the submodule library, such as libraries/Cabal. See also !539, !606, !618 [ci skip]
-
-
-
Using this feature requires fsatrace (e.g. https://github.com/jacereda/fsatrace). Simply use the `--lint-fsatrace` option when running hadrian. Shake version >= 0.17.7 is required to support linting out of tree build dirs.
-
Also removes a couple unnecessary MagicHash pragmas
-
-
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.
-
- Mar 30, 2019
-
-
Ben Gamari authored
-
- Mar 29, 2019
-
-
See #16199.
-
This ensures that the release dates in the library changelogs are properly set.
-
-
Fixes #16228. The included test case is adapted from the reproduction in the issue, and fails without this patch. ------ We compute an initial visilibity mapping for units based on what is present in the package databases. To seed this, we compute a set of all the package configs to add visibilities for. However, this set was keyed off the unit's *package name*. This is correct, since we compare packages across databases by version. However, we would only ever consider a single, most-preferable unit from the database in which it was found. The effect of this was that only one of the libraries in a Cabal package would be added to this initial set. This would cause attempts to use modules from the omitted libraries to fail, claiming that the package was hidden (even though `ghc-pkg` would correctly show it as visible). A solution is to do the selection of the most preferable packages separately, and then be sure to consider exposing all units in the same package in the same package db. We can do this by picking a most-preferable unit for each package name, and then considering exposing all units that are equi-preferable with that unit. ------ Why wasn't this bug apparent to all people trying to use sub-libraries in Cabal? The answer is that Cabal explicitly passes `-package` and `-package-id` flags for all the packages it wants to use, rather than relying on the state of the package database. So this bug only really affects people who are trying to use package databases produced by Cabal outside of Cabal itself. One particular example of this is the way that the Nixpkgs Haskell infrastructure provides wrapped GHCs: typically these are equipped with a package database containing all the needed package dependencies, and the user is not expected to pass `-package` flags explicitly.
-
