| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The simplest way to do this seemed to be to persist the whole type in
the extension field from the typechecker so that the few relevant places
* Desugaring can work out the return type by splitting this type rather
than calling `dsExpr` (slightly more efficient).
* hsExprType can just return the correct type.
* Zonking has to now zonk the type as well
The other option we considered was wiring in StaticPtr but that is
actually quite tricky because StaticPtr refers to StaticPtrInfo which
has field selectors (which we can't easily wire in).
Fixes #20150
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The documentation states that the interactive flags should be use for
any interactive expressions. The interactive flags are used when
typechecking these expressions but not when printing. The session flags
(modified by :set) are only used when loading a module.
Fixes #20909
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reqlib modifer was supposed to indicate that a test needed a certain
library in order to work. If the library happened to be installed then
the test would run as normal.
However, CI has never run these tests as the packages have not been
installed and we don't want out tests to depend on things which might
get externally broken by updating the compiler.
The new strategy is to run these tests in head.hackage, where the tests
have been cabalised as well as possible. Some tests couldn't be
transferred into the normal style testsuite but it's better than never
running any of the reqlib tests. https://gitlab.haskell.org/ghc/head.hackage/-/merge_requests/169
A few submodules also had reqlib tests and have been updated to remove
it.
Closes #16264 #20032 #17764 #16561
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to providing stack traces, the scary HasCallStack will
hopefully make people think whether they want to use these functions,
i.e. act as a documentation hint that something weird might happen.
A single metric increased, which doesn't visibly
use any method with `HasCallStack`.
-------------------------
Metric Decrease:
T9630
Metric Decrease:
T19695
T9630
-------------------------
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
When instances overlap, we now include additional information
about why we weren't able to select an instance: perhaps
one instance overlapped another but was not strictly more specific,
so we aren't able to directly choose it.
Fixes #20542
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently in GHCi, when given a line of user input we:
1. Attempt to parse and handle it as a statement
2. Otherwise, attempt to parse and handle a single import
3. Otherwise, check if there are imports present (and if so display an error message)
4. Otherwise, attempt to parse a module and only handle the declarations
This patch simplifies the process to:
Attempt to parse and handle it as a statement
Otherwise, attempt to parse a module and handle the imports and declarations
This means that multiple imports in a multiline are now accepted, and a multiline containing both imports and declarations is now accepted (as well as when separated by semicolons).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #20541 by making mkTyConApp do more sharing of types.
In particular, replace
* BoxedRep Lifted ==> LiftedRep
* BoxedRep Unlifted ==> UnliftedRep
* TupleRep '[] ==> ZeroBitRep
* TYPE ZeroBitRep ==> ZeroBitType
In each case, the thing on the right is a type synonym
for the thing on the left, declared in ghc-prim:GHC.Types.
See Note [Using synonyms to compress types] in GHC.Core.Type.
The synonyms for ZeroBitRep and ZeroBitType are new, but absolutely
in the same spirit as the other ones. (These synonyms are mainly
for internal use, though the programmer can use them too.)
I also renamed GHC.Core.Ty.Rep.isVoidTy to isZeroBitTy, to be
compatible with the "zero-bit" nomenclature above. See discussion
on !6806.
There is a tricky wrinkle: see GHC.Core.Types
Note [Care using synonyms to compress types]
Compiler allocation decreases by up to 0.8%.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Type kind is printed unqualified:
ghci> :set -XNoStarIsType
ghci> :k (->)
(->) :: Type -> Type -> Type
This is the desired behavior unless the user has defined
their own Type:
ghci> data Type
Then we want to resolve the ambiguity by qualification:
ghci> :k (->)
(->) :: GHC.Types.Type -> GHC.Types.Type -> GHC.Types.Type
|
| |
|
|
|
|
|
|
| |
At some point in the past this started working. I noticed this when
working on multiple home units and couldn't load GHC's dependencies into
the interpreter.
Fixes #7388
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Users of `undefined` don’t want to see
```
files.hs: Prelude.undefined:
CallStack (from HasCallStack):
error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err
undefined, called at file.hs:151:19 in main:Main
```
but want to see
```
files.hs: Prelude.undefined:
CallStack (from HasCallStack):
undefined, called at file.hs:151:19 in main:Main
```
so let’s make that so.
The function for that is `withFrozenCallStack`, but that is not usable
here (module dependencies, and also not representation-polymorphic). And
even if it were, it could confuse GHC’s strictness analyzer, leading to
big regressions in some perf tests (T10421 in particular).
So after shuffling modules and definitions around, I eventually noticed
that the easiest way is to just not call `error` here.
Fixes #19886
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the old days the old HPT was used as an interface file cache when
using ghci. The HPT is a `ModuleEnv HomeModInfo` and so if you were
using hs-boot files then the interface file from compiling the .hs file
would be present in the cache but not the hi-boot file. This used to be
ok, because the .hi file used to just be a better version of the
.hi-boot file, with more information so it was fine to reuse it. Now the
source hash of a module is kept track of in the interface file and the
source hash for the .hs and .hs-boot file are correspondingly different
so it's no longer safe to reuse an interface file.
I took the decision to move the cache management of interface files to
GHCi itself, and provide an API where `load` can be provided with a list
of interface files which can be used as a cache. An alternative would be
to manage this cache somewhere in the HscEnv but it seemed that an API
user should be responsible for populating and suppling the cache rather
than having it managed implicitly.
Fixes #20217
|
| |
|
|
|
|
| |
else the output may depend on the input order, which seems it may depend
on the concrete Uniques, which is causing headaches when including test
cases about that.
|
| |
|
|
|
|
|
|
| |
The ghci scripts for T9293 and ghci057 used `:set` to print the
currently-set options. However, in neither case was this necessary to
the correctness of the test and moreover it would introduce spurious
platform-dependence (e.g. since `-fexternal-dynamic-refs` is set by
default only on platforms that support dynamic linking).
|
| |
|
|
|
|
|
|
|
| |
commit 98c7749 has reverted commit 59d7ee53, including the test that
that file added. That test case is still valuable, so I am re-adding it.
I add it with it’s current (broken) behavior so that whoever fixes it
intentionally or accidentially will notice and then commit the actual
desired behavior (which is kinda unspecified, see
https://gitlab.haskell.org/ghc/ghc/-/issues/20455#note_382030)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were two problems around `mkDictErr`:
1. An outdated call to `flattenTys` meant that we missed out on some
instances. As we no longer flatten type-family applications,
the logic is obsolete and can be removed.
2. We reported "out of scope" errors in a poly-kinded situation
because `BoxedRep` and `Lifted` were considered out of scope.
We fix this by using `pretendNameIsInScope`.
fixes #20465
|
| |
|
|
| |
Fixes #20009
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add 19 new messages. Update test outputs accordingly.
- Pretty print suggest-extensions hints: remove space before
interspersed commas.
- Refactor Rank's MonoType constructors. Each MonoType constructor
should represent a specific case. With the Doc suggestion belonging
to the TcRnMessage diagnostics instead.
- Move Rank from Validity to its own `GHC.Tc.Types.Rank` module.
- Remove the outdated `check_irred_pred` check.
- Remove the outdated duplication check in `check_valid_theta`, which
was subsumed by `redundant-constraints`.
- Add missing test cases for quantified-constraints/T16474 & th/T12387a.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We desugar a recursive Stmt to somethign like
(a,_,c) <- mfix (\(a,b,_) -> do { ... ; return (a,b,c) })
...stuff after the rec...
The knot-tied tuple must contain
* All the variables that are used before they are bound in the `rec` block
* All the variables that are used after the entire `rec` block
In the case of GHCi, however, we don't know what variables will be used
after the `rec` (#20206). For example, we might have
ghci> rec { x <- e1; y <- e2 }
ghci> print x
ghci> print y
So we have to assume that *all* the variables bound in the `rec` are used
afterwards. We use `Nothing` in the argument to segmentRecStmts to signal
that all the variables are used.
Fixes #20206
|
| |
|
|
| |
Updates haskeline submodule
|
| |
|
|
|
|
|
|
|
| |
Fix #17669
`hostIsDynamic` is basically a compile-time constant embedded
in the RTS. Therefore, GHCi didn't unload object files
properly when used with an external interpreter built in a
different way.
|
| |
|
|
| |
(generic Functor, Applicative, Alternative, Eq1, Ord1 instances) to GHC.Generics.
|
| |
|
|
|
|
| |
This test was fixed by 25977ab542a30df4ae71d9699d015bcdd1ab7cfb
Fixes #18330
|
| |
|
|
| |
Fixes #20019
|
| |
|
|
|
|
|
|
|
|
|
| |
This commit converts a bunch of HsToCore (Ds) messages to use the new
GHC's diagnostic message infrastructure. In particular the DsMessage
type has been expanded with a lot of type constructors, each
encapsulating a particular error and warning emitted during desugaring.
Due to the fact that levity polymorphism checking can happen both at the
Ds and at the TcRn level, a new `TcLevityCheckDsMessage` constructor has
been added to the `TcRnMessage` type.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch comprises of four different but closely related ideas. The
net result is fixing a large number of open issues with the driver
whilst making it simpler to understand.
1. Use the hash of the source file to determine whether the source file
has changed or not. This makes the recompilation checking more robust to
modern build systems which are liable to copy files around changing
their modification times.
2. Remove the concept of a "stable module", a stable module was one
where the object file was older than the source file, and all transitive
dependencies were also stable. Now we don't rely on the modification
time of the source file, the notion of stability is moot.
3. Fix TH/plugin recompilation after the removal of stable modules. The
TH recompilation check used to rely on stable modules. Now there is a
uniform and simple way, we directly track the linkables which were
loaded into the interpreter whilst compiling a module. This is an
over-approximation but more robust wrt package dependencies changing.
4. Fix recompilation checking for dynamic object files. Now we actually
check if the dynamic object file exists when compiling with -dynamic-too
Fixes #19774 #19771 #19758 #17434 #11556 #9121 #8211 #16495 #7277 #16093
|
| |
|
|
|
|
|
|
|
|
|
| |
This also demotes the error message about -fkeep-going to a trace
message which matches the behaviour of other build systems (such as
cabal-install and nix) which don't print any message like this on a
failure.
We want to remove the stable module check in a future patch, which is an
approximation of `-fkeep-going`. At the moment this change shouldn't do
very much.
|
| |
|
|
|
|
|
|
| |
In the GHCi debugger use the function `pprSigmaType` to print out
Suspension Terms. The function `pprSigmaType` respect the flag
`-f(no-)print-explicit-foralls` and so it fixes #19355.
Switch back output of existing tests to default mode (no explicit foralls).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
In function `compiler/GHC/Runtime/Heap/Inspect.hs:quantifyType` replace
`tcSplitForAllInvisTyVars` by `tcSplitNestedSigmaTys`. This will properly split
off the nested foralls in examples like `:print fmap`.
Do not remove the `forall`s from the `snd` part of the tuple returned
by `quantifyType`. It's not necessary and the reason for the bug in #12449.
Some code simplifications at the calling sites of `quantifyTypes`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives a more precise type signature to `magicDict` as proposed in #16646.
In addition, this replaces the constant-folding rule for `magicDict` in
`GHC.Core.Opt.ConstantFold` with a special case in the desugarer in
`GHC.HsToCore.Expr.dsHsWrapped`. I have also renamed `magicDict` to `withDict`
in light of the discussion in
https://mail.haskell.org/pipermail/ghc-devs/2021-April/019833.html.
All of this has the following benefits:
* `withDict` is now more type safe than before. Moreover, if a user applies
`withDict` at an incorrect type, the special-casing in `dsHsWrapped` will
now throw an error message indicating what the user did incorrectly.
* `withDict` can now work with classes that have multiple type arguments, such
as `Typeable @k a`. This means that `Data.Typeable.Internal.withTypeable` can
now be implemented in terms of `withDict`.
* Since the special-casing for `withDict` no longer needs to match on the
structure of the expression passed as an argument to `withDict`, it no
longer cares about the presence or absence of `Tick`s. In effect, this
obsoletes the fix for #19667.
The new `T16646` test case demonstrates the new version of `withDict` in
action, both in terms of `base` functions defined in terms of `withDict`
as well as in terms of functions from the `reflection` and `singletons`
libraries. The `T16646Fail` test case demonstrates the error message that GHC
throws when `withDict` is applied incorrectly.
This fixes #16646. By adding more tests for `withDict`, this also
fixes #19673 as a side effect.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since d880d6b2e48268f5ed4d3eb751fe24cc833e9221 the parsing of the
environment files was moved to `parseDynamicFlags`, under the assumption
it was typically only called once. It turns out not to be true in GHCi
and this led to continually reparsing the environment file whenever a
new option was set, the options were appended to the package state and
hence all packages reloaded, as it looked like the options were changed.
The simplest fix seems to be a clearer specification:
> Package environment files are only loaded in GHCi during initialisation.
Fixes #19650
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This vastly reduces memory usage when compiling with `--make` mode, from
about 900M when compiling Cabal to about 300M.
As a matter of uniformity, it also ensures that reading from an
interface performs the same as using the in-memory cache. We can also
delete all the horrible knot-tying in updateIdInfos.
Goes some way to fixing #13586
Accept new output of tests fixing some bugs along the way
-------------------------
Metric Decrease:
T12545
-------------------------
|
| |
|
|
| |
Fixes #19688.
|
| |
|
|
|
|
|
|
|
|
|
| |
The problem was that ghci inserts some ticks around the crucial bit of
the expression. Just like in some of the other rules we now strip the
ticks so that the rule fires more reliably.
It was possible to defeat magicDict by using -fhpc as well, so not just an
issue in ghci.
Fixes #19667 and related to #19673
|
| |
|
|
| |
This reverts commit 0cbdba2768d84a0f6832ae5cf9ea1e98efd739da.
|
| |
|
|
|
|
|
|
|
|
| |
Fixes #19616.
This commit changes the `GHC.Driver.Errors.handleFlagWarnings` function
to rely on the newly introduced `DiagnosticReason`. This allows us to
correctly pretty-print the flags which triggered some warnings and in
turn remove the cruft around this function (like the extra filtering
and the `shouldPrintWarning` function.
|
| |
|
|
|
|
|
| |
- Remove GHC.OldList
- Remove Data.OldList
- compat-unqualified-imports is no-op
- update haddock submodule
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a set of forward ports (cherry-picks) from 8.10
- a7d22795ed [ci] Add support for building on aarch64-darwin
- 5109e87e13 [testlib/driver] denoise
- 307d34945b [ci] default value for CONFIGURE_ARGS
- 10a18cb4e0 [testsuite] mark ghci056 as fragile
- 16c13d5acf [ci] Default value for MAKE_ARGS
- ab571457b9 [ci/build] Copy config.sub around
- 251892b98f [ci/darwin] bump nixpkgs rev
- 5a6c36ecb4 [testsuite/darwin] fix conc059
- aae95ef0c9 [ci] add timing info
- 3592d1104c [Aarch64] No div-by-zero; disable test.
- 57671071ad [Darwin] mark stdc++ tests as broken
- 33c4d49754 [testsuite] filter out superfluous dylib warnings
- 4bea83afec [ci/nix-shell] Add Foundation and Security
- 6345530062 [testsuite/json2] Fix failure with LLVM backends
- c3944bc89d [ci/nix-shell] [Darwin] Stop the ld warnings about libiconv.
- b821fcc714 [testsuite] static001 is not broken anymore.
- f7062e1b0c [testsuite/arm64] fix section_alignment
- 820b076698 [darwin] stop the DYLD_LIBRARY_PATH madness
- 07b1af0362 [ci/nix-shell] uniquify NIX_LDFLAGS{_FOR_TARGET}
As well as a few additional fixups needed to make this block compile:
- Fixup all.T
- Set CROSS_TARGET, BROKEN_TESTS, XZ, RUNTEST_ARGS, default value.
- [ci] shell.nix bump happy
|
| |
|
|
|
| |
Co-authored-by: Daniel Rogozin <daniel.rogozin@serokell.io>
Co-authored-by: Rinat Stryungis <rinat.stryungis@serokell.io>
|
| |
|
|
| |
Fixes the Windows CI jobs. Requires update of the Win32 submodule.
|
| | |
|
| | |
|
