| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
failIO has useful information in its demand signature (specifically that
it bottoms) which is hidden if it is SOURCE imported, as noted
in #16588. Rejigger things such that we don't SOURCE import it.
Metric Increase:
T13701
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes #17395, a very subtle and hard-to-trigger
bug in tcMatchTy. It's all explained in
Note [Matching in the presence of casts (2)]
I have not added a regression test because it is very hard
to trigger it, until we have the upcoming mkAppTyM patch,
after which lacking this patch means you can't even compile
the libraries.
|
|
|
|
| |
This one came in a comment from James Payor
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I found in #17415 that Lint was printing out truly gigantic
warnings, unmanageably huge, with repeated copies of the
same thing.
This patch makes Lint less chatty, especially for warnings:
* For **warnings**, I don't print details of the location,
unless you add `-dppr-debug`.
* For **errors**, I still print all the info. They are fatal
and stop exection, whereas warnings appear repeatedly.
* I've made much less use of `AnExpr` in `LintLocInfo`;
the expression can be gigantic.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacOS Catalina is finally going to force our hand in forbidden writable
exeutable mappings. Unfortunately, this is quite incompatible with the
current global m32 allocator, which mixes symbols from various objects
in a single page. The problem here is that some of these symbols may not
yet be resolved (e.g. had relocations performed) as this happens lazily
(and therefore we can't yet make the section read-only and therefore
executable).
The easiest way around this is to simply create one m32 allocator per
ObjectCode. This may slightly increase fragmentation for short-running
programs but I suspect will actually improve fragmentation for programs
doing lots of loading/unloading since we can always free all of the
pages allocated to an object when it is unloaded (although this ability
will only be implemented in a later patch).
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Just a few things I found while looking at #17383.
|
| |
|
|
|
|
|
| |
As reported in #17414, Darwin throws EINVAL in response to large
writes.
|
|
|
|
|
|
|
|
|
| |
Before: 0x0000004200c86888
After: 0x42000224f8
This is more concise and consistent with the RTS's printer (which uses
%p formatter, and at least on Linux gcc prints the short form) and gdb's
pointer formatter.
|
|
|
|
|
|
|
|
|
|
| |
Previously we were configuring the ARMv7 builds with a host/target
triple of arm-linux-gnueabihf, which caused us to target ARMv6 and
consequently rely on the old CP15 memory barrier implementation. This
barrier has to be emulated on ARMv8 machines which is glacially slow.
Hopefully this should fix the ARMv7 builds which currently consistently
time out.
|
|
|
|
|
|
|
|
| |
GHC Proposal #229 changes the lexical rules of Haskell, which may
require slight whitespace adjustments in certain cases.
This patch changes formatting in a few places in GHC and its testsuite
in a way that enables it to compile under the proposed rules.
|
| |
|
|
|
|
|
|
| |
AP_NOUPD entry code doesn't use the arity field, but not initializing
this field confuses printers/debuggers, and also makes testing harder as
the field's value changes randomly.
|
| |
|
|
|
|
|
|
|
|
| |
The configuration in the installation environment (as determined by
`autoconf`) may differ from the build environment and therefore we
need to be sure to rebuild the settings file.
Fixes #17374.
|
| |
|
|
|
|
|
| |
This had silently regressed due to 81860281 and the variable renaming performed
in b55ee979, as noted in #17374.
|
|
|
|
|
| |
This reverts commit aa31ceaf7568802590f73a740ffbc8b800096342 as
suggested in #17392.
|
|
|
|
|
| |
Not only is it now unused but we generally can't assume that we are
compiling with GCC, so it really shouldn't be used.
|
|
|
|
| |
This makes the CPP significantly easier to follow.
|
|
|
|
|
|
|
|
|
| |
The OFD locking path introduced in
3b784d440d4b01b4c549df7c9a3ed2058edfc780 due to #13945 appears to have
never actually worked but we never noticed due to an oversight in the
autoconf check. Fix it.
Thanks to Oleg Grenrus for noticing this.
|
|
|
|
|
|
|
|
|
|
|
| |
Previously `hadrian` would pass `-optc-Werror=unused-but-set-variable`
to all GHC invocations. This was a difference from the make build system
and cause the unregisterised build to fail as the C that GHC produces
contains many unused functions. Drop it from the GHC flags.
Note, however, that the flag is still present in
`Settings.Builders.Common.cWarnings` and therefore will still be applied
during compilation of C sources.
|
|
|
|
|
| |
Some of these flags wanted to be passed to .cmm builds as well as C
builds.
|
|
|
|
|
|
|
|
| |
It seems that NOSMP was previously only defined when compiling the
compiler, not the RTS. Fix this.
In addition do some spring-cleaning and make the logic match that of the
Make build system.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ModIfaces
The compilation phases now optionally return ModIface (for phases that
generate an interface, currently only HscOut when (re)compiling a file).
The value is then used by compileOne' to return the generated interface
with HomeModInfo (which is then used by the batch mode compiler when
building rest of the tree).
hscIncrementalMode also returns a DynFlags with plugin info, to be used
in the rest of the pipeline.
Unfortunately this introduces a (perhaps less bad) hack in place of the
previous IORef: we now record the DynFlags used to generate the partial
infterface in HscRecomp and use the same DynFlags when generating the
full interface. I spent almost three days trying to understand what's
changing in DynFlags that causes a backpack test to fail, but I couldn't
figure it out. There's a FIXME added next to the field so hopefully
someone who understands this better than I do will fix it leter.
|
|
|
|
|
|
|
|
|
|
|
| |
Make it evident in the constructors that the final interface is only
available when HscStatus is not HscRecomp.
(When HscStatus == HscRecomp we need to finish the compilation to get
the final interface)
`Maybe ModIface` return value of hscIncrementalCompile and the partial
`expectIface` function are removed.
|
|
|
|
| |
I have no idea how this went unnoticed until now.
|
|
|
|
| |
This is a common bug that creeps into Makefiles (e.g. see T12674).
|
|
|
|
| |
This makes testing much easier.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This updates the following:
* Add description for ImportQualifiedPost extension
* Add description for ghci command name resolution
* Fix markdown warnings
[skip ci]
|
|
|
|
| |
[skip ci]
|
|
|
|
|
|
| |
A join point was getting too large an arity, leading to #17294.
I've tightened up the invariant: see
CoreSyn, Note [Invariants on join points], invariant 2b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with equality constraints
In #17304, Richard and Simon dicovered that using `-XFlexibleInstances`
for `Outputable` instances of AST data types means users can provide orphan
`Outputable` instances for passes other than `GhcPass`.
Type inference doesn't currently to suffer, and Richard gave an example
in #17304 that shows how rare a case would be where the slightly worse
type inference would matter.
So I went ahead with the refactoring, attempting to fix #17304.
|
|
|
|
|
|
|
| |
Attach the API annotations for the start and end locations of the
{-# SOURCE #-} pragma in an ImportDecl.
Closes #17388
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the way `DerivEnv` is currently structured, there is an
invariant that every derived instance must consist of a class applied
to a non-empty list of argument types, where the last argument *must*
be an application of a type constructor to some arguments. This works
for many cases, but there are also some design patterns in standalone
`anyclass`/`via` deriving that are made impossible due to enforcing
this invariant, as documented in #13154.
This fixes #13154 by refactoring `TcDeriv` and friends to perform
fewer validity checks when using the `anyclass` or `via` strategies.
The highlights are as followed:
* Five fields of `DerivEnv` have been factored out into a new
`DerivInstTys` data type. These fields only make sense for
instances that satisfy the invariant mentioned above, so
`DerivInstTys` is now only used in `stock` and `newtype` deriving,
but not in other deriving strategies.
* There is now a `Note [DerivEnv and DerivSpecMechanism]` describing
the bullet point above in more detail, as well as explaining the
exact requirements that each deriving strategy imposes.
* I've refactored `mkEqnHelp`'s call graph to be slightly less
complicated. Instead of the previous `mkDataTypeEqn`/`mkNewTypeEqn`
dichotomy, there is now a single entrypoint `mk_eqn`.
* Various bits of code were tweaked so as not to use fields that are
specific to `DerivInstTys` so that they may be used by all deriving
strategies, since not all deriving strategies use `DerivInstTys`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Applicative-do has a bug where it fails to use the monadic fail method
when desugaring patternmatches which can fail. See #15344.
This patch fixes that problem. It required more rewiring than I had expected.
Applicative-do happens mostly in the renamer; that's where decisions about
scheduling are made. This schedule is then carried through the typechecker and
into the desugarer which performs the actual translation. Fixing this bug
required sending information about the fail method from the renamer, through
the type checker and into the desugarer. Previously, the desugarer didn't
have enough information to actually desugar pattern matches correctly.
As a side effect, we also fix #16628, where GHC wouldn't catch missing
MonadFail instances with -XApplicativeDo.
|
|
|
|
|
|
|
| |
Previously we would allow the output from the check of SMP support
introduced by 83655b06e6d3e93b2d15bb0fa250fbb113d7fe68 leak to
stdout. Silence this.
See #16873.
|
|
|
|
|
|
|
|
|
| |
We were using `appPrec`, not `sigPrec`, as the precedence when
determining whether or not to parenthesize `() :: Constraint`,
which lead to the parentheses being omitted in function contexts
like `(() :: Constraint) => String`. Easily fixed.
Fixes #17403.
|