| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
Now that Outputable is independent of DynFlags, we can put tracing
functions using SDocs into their own module that doesn't transitively
depend on any GHC.Driver.* module.
A few modules needed to be moved to avoid loops in DEBUG mode.
|
|
|
|
|
|
|
|
| |
Upstream environment variables take precedance over downstream
variables. It is more consistent (and easier to modify) if the variables are all set in the
head.hackage CI file rather than setting this here.
[skip ci]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The specification is now simple
* On linux, use `-Xlinker -rpath -Xlinker` to set the rpath of the
executable
* On darwin, never use `-Xlinker -rpath -Xlinker`, always inject
the rpath afterwards, see `runInjectRPaths`.
* If `-fno-use-rpaths` is passed then *never* inject anything into the
rpath.
Fixes #20004
|
|
|
|
|
|
|
| |
bound.
We use a non-inclusive upper bound so that setting the upper bound to 13 for
example means that all 12.x versions are accepted.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note [fd_set_overflow]
~~~~~~~~~~~~~~~~~~~~~~
In this note is the very sad tale of __darwin_fd_set_overflow.
The 8.10.5 release was broken because it was built in an environment
where the libraries were provided by XCode 12.*, these libraries introduced
a reference to __darwin_fd_set_overflow via the FD_SET macro which is used in
Select.c. Unfortunately, this symbol is not available with XCode 11.* which
led to a linker error when trying to link anything. This is almost certainly
a bug in XCode but we still have to work around it.
Undefined symbols for architecture x86_64:
"___darwin_check_fd_set_overflow", referenced from:
_awaitEvent in libHSrts.a(Select.o)
ld: symbol(s) not found for architecture x86_64
One way to fix this is to upgrade your version of xcode, but this would
force the upgrade on users prematurely. Fortunately it also seems safe to pass
the linker option "-Wl,-U,___darwin_check_fd_set_overflow" because the usage of
the symbol is guarded by a guard to check if it's defined.
__header_always_inline int
__darwin_check_fd_set(int _a, const void *_b)
{
if ((uintptr_t)&__darwin_check_fd_set_overflow != (uintptr_t) 0) {
return __darwin_check_fd_set_overflow(_a, _b, 1);
return __darwin_check_fd_set_overflow(_a, _b, 0);
} else {
return 1;
}
Across the internet there are many other reports of this issue
See: https://github.com/mono/mono/issues/19393
, https://github.com/sitsofe/fio/commit/b6a1e63a1ff607692a3caf3c2db2c3d575ba2320
The issue was originally reported in #19950
Fixes #19950
|
|
|
|
|
|
|
|
|
|
| |
Passing --with-ncurses-libraries means the path which gets backed in
progagate into the built binaries. This is incorrect when we want to
distribute the binaries because the user might not have the library in
that specific place. It's the user's reponsibility to direct the dynamic
linker to the right place.
Fixes #19968
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now have two darwin flavours. AArch64-Darwin, and
x86_64-darwin, the latter one which has proper custom
adjustor support, the former though relies on libffi.
Mixing both leads to odd crashes, as the closures might
not fit the size of the libffi closures. Hence this
needs to be guarded by the USE_LBFFI_FOR_ADJUSTORS guard.
Original patch by Hamish Mackenzie
|
|
|
|
|
|
|
|
|
| |
This removes an _ad hoc_ special case for empty `LHsContext`s in
`pprLHsContext`, fixing #20011. To avoid regressions in
pretty-printing data types and classes constructed via TH, we now
apply a heuristic where we convert empty datatype contexts and superclasses
to a `Nothing` (rather than `Just` an empty context). This will, for instance,
avoid pretty-printing every TH-constructed data type as `data () => Blah ...`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* move naturalToFloat/Double from ghc-bignum to base:GHC.Float and make
them wired-in (as their integerToFloat/Double counterparts)
* use the same rounding method as integerToFloat/Double. This is an
oversight of 540fa6b2cff3802877ff56a47ab3611e33a9ac86
* add passthrough rules for intToFloat, intToDouble, wordToFloat,
wordToDouble.
|
|
|
|
|
| |
Also document deprecation of Wnoncanonical-monadfail-instances
and -Wimplicit-kind-vars
|
|
|
|
|
|
|
|
|
|
|
| |
When working eta-expansion and reduction, I found that fork# had a
weaker strictness signature than it should have (#19992). In
particular, it didn't record that it applies its argument exactly
once. To this I needed to give it a proper type (its first argument is
always a function, which in turn entailed a small change to the call
in GHC.Conc.Sync
This patch fixes it.
|
|
|
|
| |
Fixes #20006
|
|
|
|
| |
To append 2 FastString we don't need to convert them into ByteString: use ShortByteString's Semigroup instance instead.
|
| |
|
| |
|
|
|
|
|
| |
I realised that the suggestion in #19833 doesn't work, and
documented why in Note [Zapping Used Once info in WorkWrap]
|
|
|
|
| |
This fixes the performance test tracking for all darwin environments.
|
|
|
|
|
|
|
|
|
|
|
| |
If libiconv is installed from packages on the build machine, there is a high
chance that the build system will pick up /usr/local/include/iconv.h instead
of base /usr/include/iconv.h
This additional preprocessor define makes package's libiconv header compatible
with system one, fixing the build.
Closes issue #19958
|
|
|
|
|
|
| |
With -dsuppress-coercions, it's still good to be able to see the
type of the coercion. This patch prints the type. Maybe we should
have a flag to control this too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When floating a binding out past some type-variable binders,
don't gratuitiously change the order of the binders.
This small change gives code that is simpler, has less risk of
non-determinism, and does not gratuitiously change type-variable
order.
See Note [Which type variables to abstract over] in
GHC.Core.Opt.Simplify.Utils.
This is really just refactoring; no change in behaviour.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #19890 we realised that cast worker/wrapper didn't really work
properly for functions with an INLINABLE pragma, and hence a stable
unfolding. This patch fixes the problem.
Instead of disabling cast w/w when there is a stable unfolding (as
we did before), we now tranfer the stable unfolding to the worker.
It turned out that it was easier to do that if I moved the cast
w/w stuff from prepareBinding to completeBind.
No chnages at all in nofib results:
--------------------------------------------------------------------------------
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
Min -0.0% 0.0% -63.8% -78.2% 0.0%
Max -0.0% 0.0% +11.8% +11.7% 0.0%
Geometric Mean -0.0% -0.0% -26.6% -33.4% -0.0%
Small decreases in compile-time allocation for two tests (below)
of around 2%.
T12545 increased in compile-time alloc by 4%, but it's not
reproducible on my machine, and is a known-wobbly test.
Metric Increase:
T12545
Metric Decrease:
T18698a
T18698b
|
|
|
|
|
|
|
|
|
| |
This increases the critical path length but in practice will reduce
pressure on runners because less jobs overall will be spawned.
See #20003
[skip ci]
|
|
|
|
| |
Fix found by Adam Gundry.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are some obscure situations where the RHS of a rule can contain a
tick which is not mentioned anywhere else in the program. If this
happens you end up with an obscure linker error. The solution is quite
simple, traverse the RHS of rules to also look for ticks. It turned out
to be easier to implement if the traversal was moved into CoreTidy
rather than at the start of code generation because there we still had
easy access to the rules.
./StreamD.o(.text+0x1b9f2): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc'
./MArray.o(.text+0xbe83): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc'
Main.o(.text+0x6fdb): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc'
|
|
|
|
|
|
| |
Another step towards a simpler design for exact printing.
Updates the haddock submodule.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #19969 we discovered that GHC has has a bug *forever* that means it
sometimes essentially discarded INLINE pragams. This happened when you have
* Two more more mutually recursive functions
* Some of which (presumably not all!) have an INLINE pragma
* Completely monomorphic.
This hits a particular case in GHC.HsToCore.Binds.dsAbsBinds, which was
simply wrong -- it put the INLINE pragma on the wrong binder.
This patch fixes the bug, rather easily, by adjusting the
no-tyvar, no-dict case of GHC.HsToCore.Binds.dsAbsBinds.
I also discovered that the GHC.Core.Opt.Pipeline.shortOutIndirections
was not doing a good job for
{-# INLINE lcl_id #-}
lcl_id = BIG
gbl_id = lcl_id
Here we want to transfer the stable unfolding to gbl_id (we do), but
we also want to remove it from lcl_id (we were not doing that).
Otherwise both Ids have large stable unfoldings. Easily fixed.
Note [Transferring IdInfo] explains.
|
|
|
|
| |
fixes #19756, updates haddock submodule
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For reasons described in GHC.Core.Opt.Simplify
Historical Note [Case binders and join points],
we used to keep a Core unfolding in one of the lambda-binders
for a join point. But this was always a gross hack -- it's
very odd to have an unfolding in a lambda binder, that refers to
earlier lambda binders.
The hack bit us in various ways:
* Most seriously, it is incompatible with linear types in Core.
* It complicated demand analysis, and could worsen results
* It required extra care in the simplifier (simplLamBinder)
* It complicated !5641 (look for "join binder unfoldings")
So this patch just removes the hack. Happily, doind so turned out to
have no effect on performance.
|
|
|
|
|
|
|
|
|
|
| |
Now that we hash object files to decide when to recompile due to TH,
this can make a big difference as each interface file in a project will
contain reference to the object files of all package dependencies.
Especially when these are statically linked, hashing them can add up.
The cache is invalidated when `depanalPartial` is called, like the
normal finder cache.
|
| |
|
|
|
|
| |
asynchronous.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`GHC.Hs.Syn.Type`
The existing `hsPatType`, `hsLPatType` and `hsLitType` functions have also been
moved to this module
This is a less ambitious take on the same problem that !2182 and !3866
attempt to solve. Rather than have the `hsExprType` function attempt to
efficiently compute the `Type` of every subexpression in an `HsExpr`, this
simply computes the overall `Type` of a single `HsExpr`.
- Explicitly forbids the `SplicePat` `HsIPVar`, `HsBracket`, `HsRnBracketOut`
and `HsTcBracketOut` constructors during the typechecking phase by using
`Void` as the TTG extension field
- Also introduces `dataConCantHappen` as a domain specific alternative to `absurd`
to handle cases where the TTG extension points forbid a constructor.
- Turns HIE file generation into a pure function that doesn't need access to the
`DsM` monad to compute types, but uses `hsExprType` instead.
- Computes a few more types during HIE file generation
- Makes GHCi's `:set +c` command also use `hsExprType` instead of going through
the desugarer to compute types.
Updates haddock submodule
Co-authored-by: Zubin Duggal <zubin.duggal@gmail.com>
|
|
|
|
|
|
|
|
| |
In (<|>) for ZipList, avoid processing the first argument twice (both as first
argument of (++) and for its length in drop count of the second argument).
Previously, the entire first argument was forced into memory, now (<|>) can run
in constant space even with long inputs.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is an attempt at reducing the number of dependencies of the Parser
(as reported by CountParserDeps). Modules in GHC.Parser.* don't import
GHC.Driver.Session directly anymore.
Sadly some GHC.Driver.* modules are still transitively imported and the
number of dependencies didn't decrease. But it's a step in the right
direction.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce LogFlags as a independent subset of DynFlags used for logging.
As a consequence in many places we don't have to pass both Logger and
DynFlags anymore.
The main reason for this refactoring is that I want to refactor the
systools interfaces: for now many systools functions use DynFlags both
to use the Logger and to fetch their parameters (e.g. ldInputs for the
linker). I'm interested in refactoring the way they fetch their
parameters (i.e. use dedicated XxxOpts data types instead of DynFlags)
for #19877. But if I did this refactoring before refactoring the Logger,
we would have duplicate parameters (e.g. ldInputs from DynFlags and
linkerInputs from LinkerOpts). Hence this patch first.
Some flags don't really belong to LogFlags because they are subsystem
specific (e.g. most DumpFlags). For example -ddump-asm should better be
passed in NCGConfig somehow. This patch doesn't fix this tight coupling:
the dump flags are part of the UI but they are passed all the way down
for example to infer the file name for the dumps.
Because LogFlags are a subset of the DynFlags, we must update the former
when the latter changes (not so often). As a consequence we now use
accessors to read/write DynFlags in HscEnv instead of using `hsc_dflags`
directly.
In the process I've also made some subsystems less dependent on DynFlags:
- CmmToAsm: by passing some missing flags via NCGConfig (see new fields
in GHC.CmmToAsm.Config)
- Core.Opt.*:
- by passing -dinline-check value into UnfoldingOpts
- by fixing some Core passes interfaces (e.g. CallArity, FloatIn)
that took DynFlags argument for no good reason.
- as a side-effect GHC.Core.Opt.Pipeline.doCorePass is much less
convoluted.
|
| |
|
|
|
|
|
|
|
| |
As noted in #10037, the `ioprof` test would change its stderr output
(specifically the stacktrace produced by `error`) depending upon
optimisation level. As the `error` backtrace is not the point of this
test, we now ignore the `stderr` output.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider this (from #19824)
let t = ...big...
in ...(f t x)...
were `f` ignores its first argument. With luck f's wrapper will inline
thereby dropping `t`, but maybe not: the arguments to f all look boring.
So we pre-empt the problem by replacing t's RHS with an absent filler
during w/w. Simple and effective.
The main payload is the new `isAbsDmd` case in `tryWw`, but there are
some other minor refactorings:
* To implment this I had to refactor `mk_absent_let` to
`mkAbsentFiller`, which can be called from `tryWW`.
* wwExpr took both WwOpts and DynFlags which seems silly. I combined
them into one.
* I renamed the historical mkInineRule to mkWrapperUnfolding
|
|
|
|
|
|
|
|
|
|
| |
As #19882 pointed out, we were simply doing rubbish literals wrong.
(I'll refrain from explaining the wrong-ness here -- see the ticket.)
This patch fixes it by adding a Type (of kind RuntimeRep) as field of
LitRubbish, rather than [PrimRep].
The Note [Rubbish literals] in GHC.Types.Literal explains the details.
|