| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
The user's guide failed to explicitly mention that GADTSyntax
can be used to declare newtypes, so we add an example and a couple
of explanations.
Also explains that `-XGADTs` generalises `-XExistentialQuantification`.
Fixes #20848 and #20865.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Multiple home units allows you to load different packages which may depend on
each other into one GHC session. This will allow both GHCi and HLS to support
multi component projects more naturally.
Public Interface
~~~~~~~~~~~~~~~~
In order to specify multiple units, the -unit @⟨filename⟩ flag
is given multiple times with a response file containing the arguments for each unit.
The response file contains a newline separated list of arguments.
```
ghc -unit @unitLibCore -unit @unitLib
```
where the `unitLibCore` response file contains the normal arguments that cabal would pass to `--make` mode.
```
-this-unit-id lib-core-0.1.0.0
-i
-isrc
LibCore.Utils
LibCore.Types
```
The response file for lib, can specify a dependency on lib-core, so then modules in lib can use modules from lib-core.
```
-this-unit-id lib-0.1.0.0
-package-id lib-core-0.1.0.0
-i
-isrc
Lib.Parse
Lib.Render
```
Then when the compiler starts in --make mode it will compile both units lib and lib-core.
There is also very basic support for multiple home units in GHCi, at the
moment you can start a GHCi session with multiple units but only the
:reload is supported. Most commands in GHCi assume a single home unit,
and so it is additional work to work out how to modify the interface to
support multiple loaded home units.
Options used when working with Multiple Home Units
There are a few extra flags which have been introduced specifically for
working with multiple home units. The flags allow a home unit to pretend
it’s more like an installed package, for example, specifying the package
name, module visibility and reexported modules.
-working-dir ⟨dir⟩
It is common to assume that a package is compiled in the directory
where its cabal file resides. Thus, all paths used in the compiler
are assumed to be relative to this directory. When there are
multiple home units the compiler is often not operating in the
standard directory and instead where the cabal.project file is
located. In this case the -working-dir option can be passed which
specifies the path from the current directory to the directory the
unit assumes to be it’s root, normally the directory which contains
the cabal file.
When the flag is passed, any relative paths used by the compiler are
offset by the working directory. Notably this includes -i and
-I⟨dir⟩ flags.
-this-package-name ⟨name⟩
This flag papers over the awkward interaction of the PackageImports
and multiple home units. When using PackageImports you can specify
the name of the package in an import to disambiguate between modules
which appear in multiple packages with the same name.
This flag allows a home unit to be given a package name so that you
can also disambiguate between multiple home units which provide
modules with the same name.
-hidden-module ⟨module name⟩
This flag can be supplied multiple times in order to specify which
modules in a home unit should not be visible outside of the unit it
belongs to.
The main use of this flag is to be able to recreate the difference
between an exposed and hidden module for installed packages.
-reexported-module ⟨module name⟩
This flag can be supplied multiple times in order to specify which
modules are not defined in a unit but should be reexported. The
effect is that other units will see this module as if it was defined
in this unit.
The use of this flag is to be able to replicate the reexported
modules feature of packages with multiple home units.
Offsetting Paths in Template Haskell splices
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When using Template Haskell to embed files into your program,
traditionally the paths have been interpreted relative to the directory
where the .cabal file resides. This causes problems for multiple home
units as we are compiling many different libraries at once which have
.cabal files in different directories.
For this purpose we have introduced a way to query the value of the
-working-dir flag to the Template Haskell API. By using this function we
can implement a makeRelativeToProject function which offsets a path
which is relative to the original project root by the value of
-working-dir.
```
import Language.Haskell.TH.Syntax ( makeRelativeToProject )
foo = $(makeRelativeToProject "./relative/path" >>= embedFile)
```
> If you write a relative path in a Template Haskell splice you should use the makeRelativeToProject function so that your library works correctly with multiple home units.
A similar function already exists in the file-embed library. The
function in template-haskell implements this function in a more robust
manner by honouring the -working-dir flag rather than searching the file
system.
Closure Property for Home Units
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For tools or libraries using the API there is one very important closure
property which must be adhered to:
> Any dependency which is not a home unit must not (transitively) depend
on a home unit.
For example, if you have three packages p, q and r, then if p depends on
q which depends on r then it is illegal to load both p and r as home
units but not q, because q is a dependency of the home unit p which
depends on another home unit r.
If you are using GHC by the command line then this property is checked,
but if you are using the API then you need to check this property
yourself. If you get it wrong you will probably get some very confusing
errors about overlapping instances.
Limitations of Multiple Home Units
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are a few limitations of the initial implementation which will be smoothed out on user demand.
* Package thinning/renaming syntax is not supported
* More complicated reexports/renaming are not yet supported.
* It’s more common to run into existing linker bugs when loading a
large number of packages in a session (for example #20674, #20689)
* Backpack is not yet supported when using multiple home units.
* Dependency chasing can be quite slow with a large number of
modules and packages.
* Loading wired-in packages as home units is currently not supported
(this only really affects GHC developers attempting to load
template-haskell).
* Barely any normal GHCi features are supported, it would be good to
support enough for ghcid to work correctly.
Despite these limitations, the implementation works already for nearly
all packages. It has been testing on large dependency closures,
including the whole of head.hackage which is a total of 4784 modules
from 452 packages.
Internal Changes
~~~~~~~~~~~~~~~~
* The biggest change is that the HomePackageTable is replaced with the
HomeUnitGraph. The HomeUnitGraph is a map from UnitId to HomeUnitEnv,
which contains information specific to each home unit.
* The HomeUnitEnv contains:
- A unit state, each home unit can have different package db flags
- A set of dynflags, each home unit can have different flags
- A HomePackageTable
* LinkNode: A new node type is added to the ModuleGraph, this is used to
place the linking step into the build plan so linking can proceed in
parralel with other packages being built.
* New invariant: Dependencies of a ModuleGraphNode can be completely
determined by looking at the value of the node. In order to achieve
this, downsweep now performs a more complete job of downsweeping and
then the dependenices are recorded forever in the node rather than
being computed again from the ModSummary.
* Some transitive module calculations are rewritten to use the
ModuleGraph which is more efficient.
* There is always an active home unit, which simplifies modifying a lot
of the existing API code which is unit agnostic (for example, in the
driver).
The road may be bumpy for a little while after this change but the
basics are well-tested.
One small metric increase, which we accept and also submodule update to
haddock which removes ExtendedModSummary.
Closes #10827
-------------------------
Metric Increase:
MultiLayerModules
-------------------------
Co-authored-by: Fendor <power.walross@gmail.com>
|
| | |
|
| |
|
|
|
|
| |
As suggested in #20601, this is a short-hand for enabling the usual
GHC-internal sanity checks one typically leans on when debugging runtime
crashes.
|
| |
|
|
| |
As noted in #20601, the previous name was rather misleading.
|
| |
|
|
|
|
|
| |
Here we introduce code generator support for instrument array primops
with bounds checking, enabled with the `-fcheck-prim-bounds` flag.
Introduced to debug #20769.
|
| |
|
|
|
|
|
| |
In the past the order was reversed because flags are consed onto a list.
No particular behavior was documented.
We now reverse the flags and document the behavior.
|
| |
|
|
|
|
|
|
|
|
| |
This adds a new mode, `--merge-objs`, which can be used to produce
merged GHCi library objects.
As future work we will rip out the object-merging logic in Hadrian and
Cabal and instead use this mode.
Closes #20712.
|
| |
|
|
|
|
| |
This flag was previously called `--mk-dll`. It was renamed to `-shared`
in b562cbe381d54e08dcafa11339e9a82e781ad557 but the documentation wasn't
updated to match.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Names defined earier but shadowed need to be kept around, e.g. for type
signatures:
```
ghci> data T = T
ghci> let t = T
ghci> data T = T
ghci> :t t
t :: Ghci1.T
```
and indeed they can be used:
```
ghci> let t2 = Ghci1.T :: Ghci1.T
ghci> :t t2
t2 :: Ghci1.T
```
However, previously this did not happen for ids (non-types), although they
are still around under the qualified name internally:
```
ghci> let t = "other t"
ghci> t'
<interactive>:8:1: error:
• Variable not in scope: t'
• Perhaps you meant one of these:
‘Ghci2.t’ (imported from Ghci2), ‘t’ (line 7), ‘t2’ (line 5)
ghci> Ghci2.t
<interactive>:9:1: error:
• GHC internal error: ‘Ghci2.t’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: []
• In the expression: Ghci2.t
In an equation for ‘it’: it = Ghci2.t
```
This fixes the problem by simply removing the code that tries to remove
shadowed ids from the environment. Now you can refer to shadowed ids using
`Ghci2.t`, just like you can do for data and type constructors. This
simplifies the code, makes terms and types more similar, and also
fixes #20455.
Now all names ever defined in GHCi are in `ic_tythings`, which is printed by
`:show bindings`. But for that commands, it seems to be more ergonomic
to only list those bindings that are not shadowed. Or, even if it is not
more ergonomic, it’s the current behavour. So let's restore that by filtering
in `icInScopeTTs`.
Of course a single `TyThing` can be associated with many names. We keep
it it in the bindings if _any_ of its names are still visible
unqualifiedly. It's a judgement call.
This commit also turns a rather old comment into a test files.
The comment is is rather stale and things are better explained
elsewhere. Fixes #925.
Two test cases are regressing:
T14052(ghci) ghc/alloc 2749444288.0 12192109912.0 +343.4% BAD
T14052Type(ghci) ghc/alloc 7365784616.0 10767078344.0 +46.2% BAD
This is not unexpected; the `ic_tythings list grows` a lot more if we
don’t remove shadowed Ids. I tried to alleviate it a bit with earlier
MRs, but couldn’t make up for it completely.
Metric Increase:
T14052
T14052Type
|
| |
|
|
| |
Closes #20786
|
| |
|
|
|
| |
Previously, `-O1` and `-O2`, by way of their effect on the compilation
pipeline, they implicitly turned on constant folding
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The parser now accepts implicit parameters with higher-rank
types, such as
`foo :: (?ip :: forall a. a -> a) => ...`
Before this patch, we instead insisted on parentheses like so:
`foo :: (?ip :: (forall a. a -> a)) => ...`
The rest of the logic surrounding implicit parameters is unchanged;
in particular, even with ImpredicativeTypes, this idiom is not
likely to be very useful.
Fixes #20654
|
| |
|
|
|
| |
Otherwise the user may be surprised by the missing context provided by
the latter.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit bddecda1a4c96da21e3f5211743ce5e4c78793a2.
This implements the first step in the plan formulated in #20025 to
improve the communication and migration strategy for the proposed
changes to Data.List.
Requires changing the haddock submodule to update the test output.
|
| |
|
|
| |
As requested in #20702
|
| |
|
|
| |
Closes #20504.
|
| |
|
|
|
|
|
|
|
| |
- Change the dumpPrefix to FilePath, and default to non-module
- Add dot to seperate dump-file-prefix and suffix
- Modify user guide to introduce how dump files are named
- This commit does not affect Ghci dump file naming.
See also #17500
|
| |
|
|
|
|
|
|
| |
It is either "slightly" || "significantly".
If it is "bogus" - then no quotes around "optimization" & overall using
word "bogus" or use quotes in that way in documentation is... Instead,
something like "hack" or "heuristic" can be used there.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two different ways of declaring a class in an hs-boot file:
- a full declaration, where everything is written as it is
in the .hs file,
- an abstract declaration, where class methods and superclasses
are left out.
However, a declaration with no methods and a trivial superclass,
such as:
class () => C a
was erroneously considered to be an abstract declaration, because
the superclass is trivial.
This is remedied by a one line fix in GHC.Tc.TyCl.tcClassDecl1.
This patch also further clarifies the documentation around
class declarations in hs-boot files.
Fixes #20661, #20588.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Remove `getTag_RDR` (unused), `tidyKind` and `tidyOpenKind`
(already available as `tidyType` and `tidyOpenType`)
* Remove Note [Explicit Case Statement for Specificity].
Since 0a709dd9876e40 we require GHC 8.10 for bootstrapping.
* Change the warning to `cmpAltCon` to a panic.
This shouldn't happen. If it ever does, the code was wrong anyway:
it shouldn't always return `LT`, but rather `LT` in one case
and `GT` in the other case.
* Rename `verifyLinearConstructors` to `verifyLinearFields`
* Fix `Note [Local record selectors]` which was not referenced
* Remove vestiges of `type +v`
* Minor fixes to StaticPointers documentation, part of #15603
|
| |
|
|
|
|
|
|
|
| |
Previously, it was an error to pattern match on a GADT
without GADTs or TypeFamilies.
This is now allowed. Instead, we check the flag MonoLocalBinds;
if it is not enabled, we issue a warning, controlled by -Wgadt-mono-local-binds.
Also fixes #20485: pattern synonyms are now checked too.
|
| |
|
|
|
|
|
|
|
|
| |
In accordance with GHC Proposal #281 "Visible forall in types of terms":
For three releases before this change takes place, include a new
warning -Wforall-identifier in -Wdefault. This warning will be triggered
at definition sites (but not use sites) of forall as an identifier.
Updates the haddock submodule.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, these flags were passed when both compiling and linking
code. However, `-pie` and `-no-pie` are link-time-only options. Usually,
this does not cause issues, but when using Clang with `-Werror` set
results in errors:
clang: error: argument unused during compilation: '-nopie' [-Werror,-Wunused-command-line-argument]
This is unused by Clang because this flag has no effect at compile time
(it’s called `-nopie` internally by Clang but called `-no-pie` in GHC
for compatibility with GCC). Just passing these flags at linking time
resolves this.
Additionally, update #15319 hack to look for `-pgml` instead.
Because of the main change, the value of `-pgmc` does not matter when
checking for the workaround of #15319. However, `-pgml` *does* still
matter as not all `-pgml` values support `-no-pie`.
To cover all potential values, we assume that no custom `-pgml` values
support `-no-pie`. This means that we run the risk of not using
`-no-pie` when it is otherwise necessary for in auto-hardened
toolchains! This could be a problem at some point, but this workaround
was already introduced in 8d008b71 and we might as well continue
supporting it.
Likewise, mark `-pgmc-supports-no-pie` as deprecated and create a new
`-pgml-supports-no-pie`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The user guide wrongly stated that default methods should not
be included in hs-boot files. In fact, if the class is not left
abstract (no methods, no superclass constraints, ...) then the
defaults must be provided and match with those given in the .hs
file.
We add some tests for this, as there were no tests in the testsuite
that gave rise to the "missing default methods" error.
Fixes #20588
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- rename the function f4 to h1 for consistency with
the naming convention
- be more explicit about the difference between
`Int -> (forall a. a -> a)`
and
`forall a. Int -> (a -> a)`
- reorder the section to make it flow better
Fixes #20585
|
| |
|
|
|
|
|
|
| |
Explain that the kind of a data family instance must now be
fully determined by the header of the instance, and how one
might migrate code to account for this change.
Fixes #20527
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes the following defaulting of type variables
in type and data families:
- type variables of kind RuntimeRep defaulting to LiftedRep
- type variables of kind Levity defaulting to Lifted
- type variables of kind Multiplicity defaulting to Many
It does this by passing "defaulting options" to the `defaultTyVars`
function; when calling from `tcTyFamInstEqnGuts` or
`tcDataFamInstHeader` we pass options that avoid defaulting.
This avoids wildcards being defaulted, which caused type families
to unexpectedly fail to reduce.
Note that kind defaulting, applicable only with -XNoPolyKinds,
is not changed by this patch.
Fixes #17536
-------------------------
Metric Increase:
T12227
-------------------------
|
| |
|
|
| |
(#20263)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes some abundant reboxing of `DynFlags` in
`GHC.HsToCore.Match.Literal.warnAboutOverflowedLit` (which was the topic
of #19407) by introducing a Boxity analysis to GHC, done as part of demand
analysis. This allows to accurately capture ad-hoc unboxing decisions previously
made in worker/wrapper in demand analysis now, where the boxity info can
propagate through demand signatures.
See the new `Note [Boxity analysis]`. The actual fix for #19407 is described in
`Note [No lazy, Unboxed demand in demand signature]`, but
`Note [Finalising boxity for demand signature]` is probably a better entry-point.
To support the fix for #19407, I had to change (what was)
`Note [Add demands for strict constructors]` a bit
(now `Note [Unboxing evaluated arguments]`). In particular, we now take care of
it in `finaliseBoxity` (which is only called from demand analaysis) instead of
`wantToUnboxArg`.
I also had to resurrect `Note [Product demands for function body]` and rename
it to `Note [Unboxed demand on function bodies returning small products]` to
avoid huge regressions in `join004` and `join007`, thereby fixing #4267 again.
See the updated Note for details.
A nice side-effect is that the worker/wrapper transformation no longer needs to
look at strictness info and other bits such as `InsideInlineableFun` flags
(needed for `Note [Do not unbox class dictionaries]`) at all. It simply collects
boxity info from argument demands and interprets them with a severely simplified
`wantToUnboxArg`. All the smartness is in `finaliseBoxity`, which could be moved
to DmdAnal completely, if it wasn't for the call to `dubiousDataConInstArgTys`
which would be awkward to export.
I spent some time figuring out the reason for why `T16197` failed prior to my
amendments to `Note [Unboxing evaluated arguments]`. After having it figured
out, I minimised it a bit and added `T16197b`, which simply compares computed
strictness signatures and thus should be far simpler to eyeball.
The 12% ghc/alloc regression in T11545 is because of the additional `Boxity`
field in `Poly` and `Prod` that results in more allocation during `lubSubDmd`
and `plusSubDmd`. I made sure in the ticky profiles that the number of calls
to those functions stayed the same. We can bear such an increase here, as we
recently improved it by -68% (in b760c1f).
T18698* regress slightly because there is more unboxing of dictionaries
happening and that causes Lint (mostly) to allocate more.
Fixes #19871, #19407, #4267, #16859, #18907 and #13331.
Metric Increase:
T11545
T18698a
T18698b
Metric Decrease:
T12425
T16577
T18223
T18282
T4267
T9961
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PHASE 1: we never rewrite Concrete# evidence.
This patch migrates all the representation polymorphism checks to
the typechecker, using a new constraint form
Concrete# :: forall k. k -> TupleRep '[]
Whenever a type `ty` must be representation-polymorphic
(e.g. it is the type of an argument to a function), we emit a new
`Concrete# ty` Wanted constraint. If this constraint goes
unsolved, we report a representation-polymorphism error to the user.
The 'FRROrigin' datatype keeps track of the context of the
representation-polymorphism check, for more informative error messages.
This paves the way for further improvements, such as
allowing type families in RuntimeReps and improving the soundness
of typed Template Haskell. This is left as future work (PHASE 2).
fixes #17907 #20277 #20330 #20423 #20426
updates haddock submodule
-------------------------
Metric Decrease:
T5642
-------------------------
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Tickets #20469 and #20470 showed that the current
implementation of arrows is not at all up to the task
of supporting GADTs: GHC produces ill-scoped Core programs
because it doesn't propagate the evidence introduced by a GADT
pattern match.
For the time being, we reject GADT pattern matches in arrow notation.
Hopefully we are able to add proper support for GADTs in arrows
in the future.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like the built-in type defaulting rules these plugins can propose candidates
to resolve ambiguous type variables.
Machine learning and other large APIs like those for game engines introduce
new numeric types and other complex typed APIs. The built-in defaulting
mechanism isn't powerful enough to resolve ambiguous types in these cases forcing
users to specify minutia that they might not even know how to do. There is
an example defaulting plugin linked in the documentation. Applications include
defaulting the device a computation executes on, if a gradient should be
computed for a tensor, or the size of a tensor.
See https://github.com/ghc-proposals/ghc-proposals/pull/396 for details.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Before if you passed both options then you would generate two identical
hi/dyn_hi and o/dyn_o files, both in the dynamic way. It's better to
warn this is happening rather than duplicating the work and causing
potential confusion.
-dynamic-too should only be used with -static.
Fixes #20436
|
| |
|
|
|
| |
In the multi-threaded RTS this can lead to hard to debug
performance issues.
|
| | |
|
| | |
|
| |
|
|
|
| |
This flag is used to remove the output of core stats per binding in Core
dumps.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This commit fixes the following bug: when `outputHi` is set, and
both `.dyn_hi` and `.hi` are needed, both would be written to
`outputHi`, causing `.dyn_hi` to overwrite `.hi`. This causes
subsequent `readIface` to fail - "mismatched interface file profile
tag (wanted "", got "dyn")" - triggering unnecessary rebuild.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC will trigger a warning similar to the following when a strictness
flag is applied to an unlifted type (primitive or defined with the
Unlifted* extensions) in the definition of a data constructor.
Test.hs:7:13: warning: [-Wredundant-strictness-flags]
• Strictness flag has no effect on unlifted type ‘Int#’
• In the definition of data constructor ‘TestCon’
In the data type declaration for ‘Test’
|
7 | data Test = TestCon !Int#
| ^^^^^^^^^^^^^
Fixes #20187
|
