| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
And fix the resulting type errors.
Co-authored-by: Krzysztof Gogolewski <krz.gogolewski@gmail.com>
Metric Decrease:
parsing001
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we pretty-print a UnitId for the user, we try to map it back to its
origin package name, version and component to print
"package-version:component" instead of some hash.
The UnitId type doesn't carry these information, so we have to look into
a UnitState to find them. This is why the Outputable instance of
UnitId used `sdocWithDynFlags` in order to access the `unitState` field
of DynFlags.
This is wrong for several reasons:
1. The DynFlags are accessed when the message is printed, not when it is
generated. So we could imagine that the unitState may have changed
in-between. Especially if we want to allow unit unloading.
2. We want GHC to support several independent sessions at once, hence
several UnitState. The current approach supposes there is a unique
UnitState as a UnitId doesn't indicate which UnitState to use.
See the Note [Pretty-printing UnitId] in GHC.Unit for the new approach
implemented by this patch.
One step closer to remove `sdocDynFlags` field from `SDocContext`
(#10143).
Fix #18124.
Also fix some Backpack code to use SDoc instead of String.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since Backpack the "home unit" is much more involved than what it was
before (just an identifier obtained with `-this-unit-id`). Now it is
used in conjunction with `-component-id` and `-instantiated-with` to
configure module instantiations and to detect if we are type-checking an
indefinite unit or compiling a definite one.
This patch introduces a new HomeUnit datatype which is much easier to
understand. Moreover to make GHC support several packages in the same
instances, we will need to handle several HomeUnits so having a
dedicated (documented) type is helpful.
Finally in #14335 we will also need to handle the case where we have no
HomeUnit at all because we are only loading existing interfaces for
plugins which live in a different space compared to units used to
produce target code. Several functions will have to be refactored to
accept "Maybe HomeUnit" parameters instead of implicitly querying the
HomeUnit fields in DynFlags. Having a dedicated type will make this
easier.
Bump haddock submodule
|
|
|
|
|
|
|
|
|
| |
- put panic related functions into GHC.Utils.Panic
- put trace related functions using DynFlags in GHC.Driver.Ppr
One step closer making Outputable fully independent of DynFlags.
Bump haddock submodule
|
|
|
|
|
| |
Adds commentary on the rationale for the changes made in merge request
!3689.
|
|
|
|
|
|
|
|
|
|
| |
Platform constant wrappers took a DynFlags parameter, hence implicitly
used the target platform constants. We removed them to allow support
for several platforms at once (#14335) and to avoid having to pass
the full DynFlags to every function (#17957).
Metric Decrease:
T4801
|
| |
|
|
|
|
|
|
|
|
| |
* for consistency, try to always use UnitPprInfo to display units to
users
* remove some uses of `unitPackageIdString` as it doesn't show the
component name and it uses String
|
|
|
|
|
|
|
|
|
| |
They both have the same role and Backend name is more explicit.
Metric Decrease:
T3064
Update Haddock submodule
|
|
|
|
|
|
|
|
|
| |
With the recent change away from first finding and then loading a
framework, loadFramework had no way of communicating the real reason
why loadDLL failed if it was any reason other than the framework
missing from the file system. It now collects all loading attempt
errors into a list and concatenates them into a string to return to
the caller.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
macOS Big Sur makes the following change to how frameworks are shipped
with the OS:
> New in macOS Big Sur 11 beta, the system ships with a built-in
> dynamic linker cache of all system-provided libraries. As part of
> this change, copies of dynamic libraries are no longer present on
> the filesystem. Code that attempts to check for dynamic library
> presence by looking for a file at a path or enumerating a directory
> will fail. Instead, check for library presence by attempting to
> dlopen() the path, which will correctly check for the library in the
> cache. (62986286)
https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-beta-release-notes/
Therefore, the previous method of checking whether a library exists
before attempting to load it makes GHC.Runtime.Linker.loadFramework
fail to find frameworks installed at /System/Library/Frameworks.
GHC.Runtime.Linker.loadFramework now opportunistically loads the
framework libraries without checking for their existence first,
failing only if all attempts to load a given framework from any of the
various possible locations fail.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes #17667 and should help to avoid such issues going forward.
The changes are mostly mechanical in nature. With two notable
exceptions.
* The register allocator.
The register allocator references registers by distinct uniques.
However they come from the types of VirtualReg, Reg or Unique in
various places. As a result we sometimes cast the key type of the
map and use functions which operate on the now typed map but take
a raw Unique as actual key. The logic itself has not changed it
just becomes obvious where we do so now.
* <Type>Env Modules.
As an example a ClassEnv is currently queried using the types `Class`,
`Name`, and `TyCon`. This is safe since for a distinct class value all
these expressions give the same unique.
getUnique cls
getUnique (classTyCon cls)
getUnique (className cls)
getUnique (tcName $ classTyCon cls)
This is for the most part contained within the modules defining the
interface. However it requires us to play dirty when we are given a
`Name` to lookup in a `UniqFM Class a` map. But again the logic did
not change and it's for the most part hidden behind the Env Module.
Some of these cases could be avoided by refactoring but this is left
for future work.
We also bump the haddock submodule as it uses UniqFM.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On big-endian platforms executing
import GHC.Exts
data Foo = Foo Float# deriving Show
foo = Foo 42.0#
foo
:print foo
results in an arithmetic overflow exception which is caused by function
index where moveBytes equals
word_size - (r + item_size_b) * 8
Here we have a mixture of units. Both, word_size and item_size_b have
unit bytes whereas r has unit bits. On 64-bit platforms moveBytes
equals then
8 - (0 + 4) * 8
which results in a negative and therefore invalid second parameter for a
shiftL operation.
In order to make things more clear the expression
(word .&. (mask `shiftL` moveBytes)) `shiftR` moveBytes
is equivalent to
(word `shiftR` moveBytes) .&. mask
On big-endian platforms the shift must be a left shift instead of a
right shift. For symmetry reasons not a mask is used but two shifts in
order to zero out bits. Thus the fixed version equals
case endian of
BigEndian -> (word `shiftL` moveBits) `shiftR` zeroOutBits `shiftL` zeroOutBits
LittleEndian -> (word `shiftR` moveBits) `shiftL` zeroOutBits `shiftR` zeroOutBits
Fixes #16548 and #14455
|
|
|
|
|
|
|
|
|
|
|
| |
SCC profiling was enabled in a convoluted way: if WayProf was enabled,
Opt_SccProfilingOn general flag was set (in
`GHC.Driver.Ways.wayGeneralFlags`), and then this flag was queried in
various places.
There is no need to go via general flags, so this patch defines a
`sccProfilingEnabled :: DynFlags -> Bool` helper function that just
checks whether WayProf is enabled.
|
|
|
|
|
|
|
|
|
|
|
|
| |
`DynFlags.buildTag` was a field created from the set of Ways in
`DynFlags.ways`. It had to be kept in sync with `DynFlags.ways` which
was fragile. We want to avoid global state like this (#17957).
Moreover in #14335 we also want to support loading units with different
ways: target units would still use `DynFlags.ways` but plugins would use
`GHC.Driver.Ways.hostFullWays`. To avoid having to deal both with build
tag and with ways, we recompute the buildTag on-the-fly (should be
pretty cheap) and we remove `DynFlags.buildTag` field.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This updates haddock comments only.
This patch focuses to update for hyperlinks in GHC API's haddock comments,
because broken links especially discourage newcomers.
This includes the following hierarchies:
- GHC.Iface.*
- GHC.Llvm.*
- GHC.Rename.*
- GHC.Tc.*
- GHC.HsToCore.*
- GHC.StgToCmm.*
- GHC.CmmToAsm.*
- GHC.Runtime.*
- GHC.Unit.*
- GHC.Utils.*
- GHC.SysTools.*
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Zonk residual constraints in checkForExistence to reveal user type
errors.
Previously when `:instances` was used with instances that have TypeError
constraints the result would look something like:
instance [safe] s0 => Err 'A -- Defined at ../Bug2.hs:8:10
whereas after zonking, `:instances` now sees the `TypeError` and
properly eliminates the constraint from the results.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to ghc-bignum, the compiler can be simplified:
* Types and constructors of Integer and Natural can be wired-in. It
means that we don't have to query them from interfaces. It also means
that numeric literals don't have to carry their type with them.
* The same code is used whatever ghc-bignum backend is enabled. In
particular, conversion of bignum literals into final Core expressions
is now much more straightforward. Bignum closure inspection too.
* GHC itself doesn't depend on any integer-* package anymore
* The `integerLibrary` setting is gone.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements several general performance improvements to GHC,
to offset the effect of the linear types change.
General optimisations:
- Add a `coreFullView` function which iterates `coreView` on the
head. This avoids making function recursive solely because the
iterate `coreView` themselves. As a consequence, this functions can
be inlined, and trigger case-of-known constructor (_e.g._
`kindRep_maybe`, `isLiftedRuntimeRep`, `isMultiplicityTy`,
`getTyVar_maybe`, `splitAppTy_maybe`, `splitFunType_maybe`,
`tyConAppTyCon_maybe`). The common pattern about all these functions
is that they are almost always used as views, and immediately
consumed by a case expression. This commit also mark them asx `INLINE`.
- In `subst_ty` add a special case for nullary `TyConApp`, which avoid
allocations altogether.
- Use `mkTyConApp` in `subst_ty` for the general `TyConApp`. This
required quite a bit of module shuffling.
case. `myTyConApp` enforces crucial sharing, which was lost during
substitution. See also !2952 .
- Make `subst_ty` stricter.
- In `eqType` (specifically, in `nonDetCmpType`), add a special case,
tested first, for the very common case of nullary `TyConApp`.
`nonDetCmpType` has been made `INLINE` otherwise it is actually a
regression. This is similar to the optimisations in !2952.
Linear-type specific optimisations:
- Use `tyConAppTyCon_maybe` instead of the more complex `eqType` in
the definition of the pattern synonyms `One` and `Many`.
- Break the `hs-boot` cycles between `Multiplicity.hs` and `Type.hs`:
`Multiplicity` now import `Type` normally, rather than from the
`hs-boot`. This way `tyConAppTyCon_maybe` can inline properly in the
`One` and `Many` pattern synonyms.
- Make `updateIdTypeAndMult` strict in its type and multiplicity
- The `scaleIdBy` gets a specialised definition rather than being an
alias to `scaleVarBy`
- `splitFunTy_maybe` is given the type `Type -> Maybe (Mult, Type,
Type)` instead of `Type -> Maybe (Scaled Type, Type)`
- Remove the `MultMul` pattern synonym in favour of a view `isMultMul`
because pattern synonyms appear not to inline well.
- in `eqType`, in a `FunTy`, compare multiplicities last: they are
almost always both `Many`, so it helps failing faster.
- Cache `manyDataConTy` in `mkTyConApp`, to make sure that all the
instances of `TyConApp ManyDataConTy []` are physically the same.
This commit has been authored by
* Richard Eisenberg
* Krzysztof Gogolewski
* Arnaud Spiwack
Metric Decrease:
haddock.base
T12227
T12545
T12990
T1969
T3064
T5030
T9872b
Metric Increase:
haddock.base
haddock.Cabal
haddock.compiler
T12150
T12234
T12425
T12707
T13035
T13056
T15164
T16190
T18304
T1969
T3064
T3294
T5631
T5642
T5837
T6048
T9020
T9233
T9675
T9872a
T9961
WWRec
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first step towards implementation of the linear types proposal
(https://github.com/ghc-proposals/ghc-proposals/pull/111).
It features
* A language extension -XLinearTypes
* Syntax for linear functions in the surface language
* Linearity checking in Core Lint, enabled with -dlinear-core-lint
* Core-to-core passes are mostly compatible with linearity
* Fields in a data type can be linear or unrestricted; linear fields
have multiplicity-polymorphic constructors.
If -XLinearTypes is disabled, the GADT syntax defaults to linear fields
The following items are not yet supported:
* a # m -> b syntax (only prefix FUN is supported for now)
* Full multiplicity inference (multiplicities are really only checked)
* Decent linearity error messages
* Linear let, where, and case expressions in the surface language
(each of these currently introduce the unrestricted variant)
* Multiplicity-parametric fields
* Syntax for annotating lambda-bound or let-bound with a multiplicity
* Syntax for non-linear/multiple-field-multiplicity records
* Linear projections for records with a single linear field
* Linear pattern synonyms
* Multiplicity coercions (test LinearPolyType)
A high-level description can be found at
https://ghc.haskell.org/trac/ghc/wiki/LinearTypes/Implementation
Following the link above you will find a description of the changes made to Core.
This commit has been authored by
* Richard Eisenberg
* Krzysztof Gogolewski
* Matthew Pickering
* Arnaud Spiwack
With contributions from:
* Mark Barbone
* Alexander Vershilov
Updates haddock submodule.
|
|
|
|
| |
Preload units can be retrieved in UnitState when needed (i.e. in GHCi)
|
|
|
|
|
|
|
| |
* rename PackageState into UnitState
* rename findWiredInPackages into findWiredInUnits
* rename lookupModuleInAll[Packages,Units]
* etc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The terminology changed over time and now package databases contain
"units" (there can be several units compiled from a single Cabal
package: one per-component, one for each option set, one per
instantiation, etc.). We should try to be consistent internally and use
"units": that's what this renaming does. Maybe one day we'll fix the UI
too (e.g. replace -package-id with -unit-id, we already have
-this-unit-id and ghc-pkg has -unit-id...) but it's not done in this
patch.
* rename getPkgFrameworkOpts into getUnitFrameworkOpts
* rename UnitInfoMap into ClosureUnitInfoMap
* rename InstalledPackageIndex into UnitInfoMap
* rename UnusablePackages into UnusableUnits
* rename PackagePrecedenceIndex into UnitPrecedenceMap
* rename PackageDatabase into UnitDatabase
* rename pkgDatabase into unitDatabases
* rename pkgState into unitState
* rename initPackages into initUnits
* rename renamePackage into renameUnitInfo
* rename UnusablePackageReason into UnusableUnitReason
* rename getPackage* into getUnit*
* etc.
|
| |
|
|
|
|
|
|
|
|
| |
* use UnitId instead of String to identify wired-in units
* use UnitId instead of Unit in the backend (Unit are only use by
Backpack to produce type-checked interfaces, not real code)
* rename lookup functions for consistency
* documentation
|
|
|
|
|
| |
* rename thisPackage into homeUnit
* document and refactor several Backpack things
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Store LambdaFormInfos of exported Ids in interface files
- Use them in importing modules
This is for optimization purposes: if we know LambdaFormInfo of imported
Ids we can generate more efficient calling code, see `getCallMethod`.
Exporting (putting them in interface files or in ModDetails) and
importing (reading them from interface files) are both optional. We
don't assume known LambdaFormInfos anywhere and do not change how we
call Ids with unknown LambdaFormInfos.
Runtime, allocation, and residency numbers when building
Cabal-the-library (commit 0d4ee7ba3):
(Log and .hp files are in the MR: !2842)
| | GHC HEAD | This patch | Diff |
|-----|----------|------------|----------------|
| -O0 | 0:35.89 | 0:34.10 | -1.78s, -4.98% |
| -O1 | 2:24.01 | 2:23.62 | -0.39s, -0.27% |
| -O2 | 2:52.23 | 2:51.35 | -0.88s, -0.51% |
| | GHC HEAD | This patch | Diff |
|-----|-----------------|-----------------|----------------------------|
| -O0 | 54,843,608,416 | 54,878,769,544 | +35,161,128 bytes, +0.06% |
| -O1 | 227,136,076,400 | 227,569,045,168 | +432,968,768 bytes, +0.19% |
| -O2 | 266,147,063,296 | 266,749,643,440 | +602,580,144 bytes, +0.22% |
NOTE: Residency is measured with extra runtime args: `-i0 -h` which effectively
turn all GCs into major GCs, and do GC more often.
| | GHC HEAD | This patch | Diff |
|-----|----------------------------|------------------------------|----------------------------|
| -O0 | 410,284,000 (910 samples) | 411,745,008 (906 samples) | +1,461,008 bytes, +0.35% |
| -O1 | 928,580,856 (2109 samples) | 943,506,552 (2103 samples) | +14,925,696 bytes, +1.60% |
| -O2 | 993,951,352 (2549 samples) | 1,010,156,328 (2545 samples) | +16,204,9760 bytes, +1.63% |
NoFib results:
--------------------------------------------------------------------------------
Program Size Allocs Instrs Reads Writes
--------------------------------------------------------------------------------
CS 0.0% 0.0% +0.0% +0.0% +0.0%
CSD 0.0% 0.0% 0.0% +0.0% +0.0%
FS 0.0% 0.0% +0.0% +0.0% +0.0%
S 0.0% 0.0% +0.0% +0.0% +0.0%
VS 0.0% 0.0% +0.0% +0.0% +0.0%
VSD 0.0% 0.0% +0.0% +0.0% +0.1%
VSM 0.0% 0.0% +0.0% +0.0% +0.0%
anna 0.0% 0.0% -0.3% -0.8% -0.0%
ansi 0.0% 0.0% -0.0% -0.0% 0.0%
atom 0.0% 0.0% -0.0% -0.0% 0.0%
awards 0.0% 0.0% -0.1% -0.3% 0.0%
banner 0.0% 0.0% -0.0% -0.0% -0.0%
bernouilli 0.0% 0.0% -0.0% -0.0% -0.0%
binary-trees 0.0% 0.0% -0.0% -0.0% +0.0%
boyer 0.0% 0.0% -0.0% -0.0% 0.0%
boyer2 0.0% 0.0% -0.0% -0.0% 0.0%
bspt 0.0% 0.0% -0.0% -0.2% 0.0%
cacheprof 0.0% 0.0% -0.1% -0.4% +0.0%
calendar 0.0% 0.0% -0.0% -0.0% 0.0%
cichelli 0.0% 0.0% -0.9% -2.4% 0.0%
circsim 0.0% 0.0% -0.0% -0.0% 0.0%
clausify 0.0% 0.0% -0.1% -0.3% 0.0%
comp_lab_zift 0.0% 0.0% -0.0% -0.0% +0.0%
compress 0.0% 0.0% -0.0% -0.0% -0.0%
compress2 0.0% 0.0% -0.0% -0.0% 0.0%
constraints 0.0% 0.0% -0.1% -0.2% -0.0%
cryptarithm1 0.0% 0.0% -0.0% -0.0% 0.0%
cryptarithm2 0.0% 0.0% -1.4% -4.1% -0.0%
cse 0.0% 0.0% -0.0% -0.0% -0.0%
digits-of-e1 0.0% 0.0% -0.0% -0.0% -0.0%
digits-of-e2 0.0% 0.0% -0.0% -0.0% -0.0%
dom-lt 0.0% 0.0% -0.1% -0.2% 0.0%
eliza 0.0% 0.0% -0.5% -1.5% 0.0%
event 0.0% 0.0% -0.0% -0.0% -0.0%
exact-reals 0.0% 0.0% -0.1% -0.3% +0.0%
exp3_8 0.0% 0.0% -0.0% -0.0% -0.0%
expert 0.0% 0.0% -0.3% -1.0% -0.0%
fannkuch-redux 0.0% 0.0% +0.0% +0.0% +0.0%
fasta 0.0% 0.0% -0.0% -0.0% +0.0%
fem 0.0% 0.0% -0.0% -0.0% 0.0%
fft 0.0% 0.0% -0.0% -0.0% 0.0%
fft2 0.0% 0.0% -0.0% -0.0% 0.0%
fibheaps 0.0% 0.0% -0.0% -0.0% +0.0%
fish 0.0% 0.0% 0.0% -0.0% +0.0%
fluid 0.0% 0.0% -0.4% -1.2% +0.0%
fulsom 0.0% 0.0% -0.0% -0.0% 0.0%
gamteb 0.0% 0.0% -0.1% -0.3% 0.0%
gcd 0.0% 0.0% -0.0% -0.0% 0.0%
gen_regexps 0.0% 0.0% -0.0% -0.0% -0.0%
genfft 0.0% 0.0% -0.0% -0.0% 0.0%
gg 0.0% 0.0% -0.0% -0.0% +0.0%
grep 0.0% 0.0% -0.0% -0.0% -0.0%
hidden 0.0% 0.0% -0.1% -0.4% -0.0%
hpg 0.0% 0.0% -0.2% -0.5% +0.0%
ida 0.0% 0.0% -0.0% -0.0% +0.0%
infer 0.0% 0.0% -0.3% -0.8% -0.0%
integer 0.0% 0.0% -0.0% -0.0% +0.0%
integrate 0.0% 0.0% -0.0% -0.0% 0.0%
k-nucleotide 0.0% 0.0% -0.0% -0.0% +0.0%
kahan 0.0% 0.0% -0.0% -0.0% +0.0%
knights 0.0% 0.0% -2.2% -5.4% 0.0%
lambda 0.0% 0.0% -0.6% -1.8% 0.0%
last-piece 0.0% 0.0% -0.0% -0.0% 0.0%
lcss 0.0% 0.0% -0.0% -0.1% 0.0%
life 0.0% 0.0% -0.0% -0.1% 0.0%
lift 0.0% 0.0% -0.2% -0.6% +0.0%
linear 0.0% 0.0% -0.0% -0.0% -0.0%
listcompr 0.0% 0.0% -0.0% -0.0% 0.0%
listcopy 0.0% 0.0% -0.0% -0.0% 0.0%
maillist 0.0% 0.0% -0.1% -0.3% +0.0%
mandel 0.0% 0.0% -0.0% -0.0% 0.0%
mandel2 0.0% 0.0% -0.0% -0.0% -0.0%
mate +0.0% 0.0% -0.0% -0.0% -0.0%
minimax 0.0% 0.0% -0.2% -1.0% 0.0%
mkhprog 0.0% 0.0% -0.1% -0.2% -0.0%
multiplier 0.0% 0.0% -0.0% -0.0% -0.0%
n-body 0.0% 0.0% -0.0% -0.0% +0.0%
nucleic2 0.0% 0.0% -0.1% -0.2% 0.0%
para 0.0% 0.0% -0.0% -0.0% -0.0%
paraffins 0.0% 0.0% -0.0% -0.0% 0.0%
parser 0.0% 0.0% -0.2% -0.7% 0.0%
parstof 0.0% 0.0% -0.0% -0.0% +0.0%
pic 0.0% 0.0% -0.0% -0.0% 0.0%
pidigits 0.0% 0.0% +0.0% +0.0% +0.0%
power 0.0% 0.0% -0.2% -0.6% +0.0%
pretty 0.0% 0.0% -0.0% -0.0% -0.0%
primes 0.0% 0.0% -0.0% -0.0% 0.0%
primetest 0.0% 0.0% -0.0% -0.0% -0.0%
prolog 0.0% 0.0% -0.3% -1.1% 0.0%
puzzle 0.0% 0.0% -0.0% -0.0% 0.0%
queens 0.0% 0.0% -0.0% -0.0% +0.0%
reptile 0.0% 0.0% -0.0% -0.0% 0.0%
reverse-complem 0.0% 0.0% -0.0% -0.0% +0.0%
rewrite 0.0% 0.0% -0.7% -2.5% -0.0%
rfib 0.0% 0.0% -0.0% -0.0% 0.0%
rsa 0.0% 0.0% -0.0% -0.0% 0.0%
scc 0.0% 0.0% -0.1% -0.2% -0.0%
sched 0.0% 0.0% -0.0% -0.0% -0.0%
scs 0.0% 0.0% -1.0% -2.6% +0.0%
simple 0.0% 0.0% +0.0% -0.0% +0.0%
solid 0.0% 0.0% -0.0% -0.0% 0.0%
sorting 0.0% 0.0% -0.6% -1.6% 0.0%
spectral-norm 0.0% 0.0% +0.0% 0.0% +0.0%
sphere 0.0% 0.0% -0.0% -0.0% -0.0%
symalg 0.0% 0.0% -0.0% -0.0% +0.0%
tak 0.0% 0.0% -0.0% -0.0% 0.0%
transform 0.0% 0.0% -0.0% -0.0% 0.0%
treejoin 0.0% 0.0% -0.0% -0.0% 0.0%
typecheck 0.0% 0.0% -0.0% -0.0% +0.0%
veritas +0.0% 0.0% -0.2% -0.4% +0.0%
wang 0.0% 0.0% -0.0% -0.0% 0.0%
wave4main 0.0% 0.0% -0.0% -0.0% -0.0%
wheel-sieve1 0.0% 0.0% -0.0% -0.0% -0.0%
wheel-sieve2 0.0% 0.0% -0.0% -0.0% +0.0%
x2n1 0.0% 0.0% -0.0% -0.0% -0.0%
--------------------------------------------------------------------------------
Min 0.0% 0.0% -2.2% -5.4% -0.0%
Max +0.0% 0.0% +0.0% +0.0% +0.1%
Geometric Mean -0.0% -0.0% -0.1% -0.3% +0.0%
Metric increases micro benchmarks tracked in #17686:
Metric Increase:
T12150
T12234
T12425
T13035
T5837
T6048
T9233
Co-authored-by: Andreas Klebinger <klebinger.andreas@gmx.at>
|
|
|
|
|
|
|
|
|
|
| |
Some platforms (musl, aarch64) do not have a working dynamic linker
implemented in the libc, even though we might see dlopen. It will
ultimately just return that this is not supported. Hence we'll add
a flag to the compiler to flat our disable loading dlls. This is
needed as we will otherwise try to load the shared library even
if this will subsequently fail. At that point we have given up
looking for static options though.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We often have (ModuleName, Bool) or (Module, Bool) pairs for "extended"
module names (without or with a unit id) disambiguating boot and normal
modules. We think this is important enough across the compiler that it
deserves a new nominal product type. We do this with synnoyms and a
functor named with a `Gen` prefix, matching other newly created
definitions.
It was also requested that we keep custom `IsBoot` / `NotBoot` sum type.
So we have it too. This means changing many the many bools to use that
instead.
Updates `haddock` submodule.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This updates comments only.
This patch replaces module references according to new module
hierarchy [1][2].
For files under the `compiler/` directory, I replace them as
module paths instead of file paths. For instance,
`GHC.Unit.State` instead of `compiler/GHC/Unit/State.hs` [3].
For current and future haddock's markup, this patch encloses
the module name with "" [4].
[1]: https://gitlab.haskell.org/ghc/ghc/-/wikis/Make-GHC-codebase-more-modular
[2]: https://gitlab.haskell.org/ghc/ghc/issues/13009
[3]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3375#note_276613
[4]: https://haskell-haddock.readthedocs.io/en/latest/markup.html#linking-to-modules
|
|
|
|
|
|
|
|
|
| |
This updates comments only.
This patch replaces file references according to new module hierarchy.
See also:
* https://gitlab.haskell.org/ghc/ghc/-/wikis/Make-GHC-codebase-more-modular
* https://gitlab.haskell.org/ghc/ghc/issues/13009
|
|
|
|
|
|
|
|
| |
Run the core linter on candidate instances to ensure they are
well-kinded.
Better handle quantified constraints by using a CtWanted to avoid
having unsolved constraints thrown away at the end by the solver.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implementation for Ticket #16393.
Explicit specificity allows users to manually create inferred type variables,
by marking them with braces.
This way, the user determines which variables can be instantiated through
visible type application.
The additional syntax is included in the parser, allowing users to write
braces in type variable binders (type signatures, data constructors etc).
This information is passed along through the renamer and verified in the
type checker.
The AST for type variable binders, data constructors, pattern synonyms,
partial signatures and Template Haskell has been updated to include the
specificity of type variables.
Minor notes:
- Bumps haddock submodule
- Disables pattern match checking in GHC.Iface.Type with GHC 8.8
|
| |
|
|
|
|
| |
accordingly)
|
|
|
|
| |
Use `withPprStyle` instead to apply a specific style to a SDoc.
|
|
|
|
|
|
|
|
|
|
|
| |
If `-dppr-debug` is set, then PprUser and PprDump styles are silently
replaced with PprDebug style. This was done in `mkUserStyle` and
`mkDumpStyle` smart constructors. As a consequence they needed a
DynFlags parameter.
Now we keep the original PprUser and PprDump styles until they are used
to create an `SDocContext`. I.e. the substitution is only performed in
`initSDocContext`.
|
|
|
|
|
|
|
| |
Introduce GHC.Unit.* hierarchy for everything concerning units, packages
and modules.
Update Haddock submodule
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Over the years the unit management code has been modified a lot to keep
up with changes in Cabal (e.g. support for several library components in
the same package), to integrate BackPack, etc. I found it very hard to
understand as the terminology wasn't consistent, was referring to past
concepts, etc.
The terminology is now explained as clearly as I could in the Note
"About Units" and the code is refactored to reflect it.
-------------------
Many names were misleading: UnitId is not an Id but could be a virtual
unit (an indefinite one instantiated on the fly), IndefUnitId
constructor may contain a definite instantiated unit, etc.
* Rename IndefUnitId into InstantiatedUnit
* Rename IndefModule into InstantiatedModule
* Rename UnitId type into Unit
* Rename IndefiniteUnitId constructor into VirtUnit
* Rename DefiniteUnitId constructor into RealUnit
* Rename packageConfigId into mkUnit
* Rename getPackageDetails into unsafeGetUnitInfo
* Rename InstalledUnitId into UnitId
Remove references to misleading ComponentId: a ComponentId is just an
indefinite unit-id to be instantiated.
* Rename ComponentId into IndefUnitId
* Rename ComponentDetails into UnitPprInfo
* Fix display of UnitPprInfo with empty version: this is now used for
units dynamically generated by BackPack
Generalize several types (Module, Unit, etc.) so that they can be used
with different unit identifier types: UnitKey, UnitId, Unit, etc.
* GenModule: Module, InstantiatedModule and InstalledModule are now
instances of this type
* Generalize DefUnitId, IndefUnitId, Unit, InstantiatedUnit,
PackageDatabase
Replace BackPack fake "hole" UnitId by a proper HoleUnit constructor.
Add basic support for UnitKey. They should be used more in the future to
avoid mixing them up with UnitId as we do now.
Add many comments.
Update Haddock submodule
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Rename InstalledPackageInfo into GenericUnitInfo
The name InstalledPackageInfo is only kept for alleged backward
compatibility reason in Cabal. ghc-boot has its own stripped down copy
of this datatype but it doesn't need to keep the name. Internally we
already use type aliases (UnitInfo in GHC, PackageCacheFormat in
ghc-pkg).
* Rename UnitInfo fields: add "unit" prefix and fix misleading names
* Add comments on every UnitInfo field
* Rename SourcePackageId into PackageId
"Package" already indicates that it's a "source package". Installed
package components are called units.
Update Haddock submodule
|
|
|
|
|
|
|
| |
Update Haddock submodule
Metric Increase:
haddock.compiler
|
|
|
|
|
| |
* add `getPlatform :: TcM Platform` helper
* remove unused `DynFlags` parameter from `emptyPLS`
|
|
|
|
|
|
| |
Instead of passing `DynFlags` to functions such as `isStmt` and
`hasImport` in `GHC.Runtime.Eval` we pass `ParserFlags`. It's a much
simpler structure that can be created purely with `mkParserFlags'`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* SysTools
* Parser
* GHC.Builtin
* GHC.Iface.Recomp
* Settings
Update Haddock submodule
Metric Decrease:
Naperian
parsing001
|
| |
|
|
|
|
| |
Update Haddock submodule
|
|
|
|
|
|
| |
Metric Decrease:
T13035
T1969
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As far as GHC is concerned, installed package components ("units") are
identified by an opaque ComponentId string provided by Cabal. But we
don't want to display it to users (as it contains a hash) so GHC queries
the database to retrieve some infos about the original source package
(name, version, component name).
This patch caches these infos in the ComponentId itself so that we don't
need to provide DynFlags (which contains installed package informations)
to print a ComponentId.
In the future we want GHC to support several independent package states
(e.g. for plugins and for target code), hence we need to avoid
implicitly querying a single global package state.
|
|
|
|
|
|
|
| |
Update Haddock submodule
Metric Increase:
haddock.compiler
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use Platform instead of DynFlags when possible:
* `tARGET_MIN_INT` et al. replaced with `platformMinInt` et al.
* no more DynFlags in PreRules: added a new `RuleOpts` datatype
* don't use `wORD_SIZE` in the compiler
* make `wordAlignment` use `Platform`
* make `dOUBLE_SIZE` a constant
Metric Decrease:
T13035
T1969
|