| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
This ensure that it blurts an error on missing references.
|
|
|
|
|
|
| |
Previously we had a hack to handle the case of multi-token SPECIALISE
pragmas. Now we use a slightly more general rule of using a prefix of
tokens containing only alphabetical characters.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Previously one could not easily link to the :reverse: flag of a
ghc-flag.
|
|
|
|
| |
Previously several were referred to via :ghc-flag:`-X...`.
|
|
|
|
|
|
|
|
|
|
| |
By introducing a `CoreMap Id` to the term oracle, we can represent
syntactically equivalent expressions by the same `Id`. Combine that with
`CoreOpt.simpleCoreExpr` and it might even catch non-trivial semantic
equalities.
Unfortunately due to scoping issues, this will not solve #17208 for
view patterns yet.
|
|
|
|
| |
This fixes #17060.
|
| |
|
| |
|
| |
|
|
|
|
| |
This should fix #16985.
|
|
|
|
|
| |
d679ca43e7477284d733b94ff542be5363be3353 meant to remove it but did not
finish the job.
|
|
|
|
|
| |
We no longer support booting from older GHC since
527bcc41630918977c73584d99125ff164400695.
|
|
|
|
| |
Unused outside it since b6be81b841e34ca45b3549c4c79e886a8761e59a.
|
|
|
|
|
| |
It looks like it's been unused since at least
34cc75e1a62638f2833815746ebce0a9114dc26b.
|
|
|
|
|
|
| |
* `foldBal` contains needless partiality that can easily be avoided.
* `mkProd_E` and `mkProd_P` both contain unique supply arguments that
are completely unused, which can be removed.
|
|
|
|
| |
This way, we can be sure we don't miss a case.
|
| |
|
| |
|
| |
|
|
|
|
| |
These are needed by the user guide documentation. Fixes #17260.
|
|
|
|
|
|
|
|
|
|
|
|
| |
As described in the new Note [LLVM Configuration] in SysTools, we now
load llvm-targets and llvm-passes lazily to avoid the overhead of doing
so when -fllvm isn't used (also known as "the common case").
Noticed in #17003.
Metric Decrease:
T12234
T12150
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Among other uses, `coreFlattenTyFamApp` is used by Core Lint as a
part of its check to ensure that each type family axiom reduces
according to the way it is defined in the source code. Unfortunately,
the logic that `coreFlattenTyFamApp` uses to flatten type family
applications disagreed with the logic in `TcFlatten`, which caused
it to spuriously complain this program:
```hs
type family Param :: Type -> Type
type family LookupParam (a :: Type) :: Type where
LookupParam (f Char) = Bool
LookupParam x = Int
foo :: LookupParam (Param ())
foo = 42
```
This is because `coreFlattenTyFamApp` tries to flatten the `Param ()`
in `LookupParam (Param ())` to `alpha` (where `alpha` is a flattening
skolem), and GHC is unable to conclude that `alpha` is apart from
`f Char`. This patch spruces up `coreFlattenTyFamApp` so that it
instead flattens `Param ()` to `alpha ()`, which GHC _can_ know for
sure is apart from `f Char`. See
`Note [Flatten], wrinkle 3` in `FamInstEnv`.
|
|
|
|
|
|
|
|
| |
Previously due to a silly implementation bug CNFs would never have their
dirty flag set, resulting in their being added again and again to the
`mut_list`. Fix this.
Fixes #17297.
|
|
|
|
|
|
|
|
| |
- Remove unneeded ones
- Use <..> for inter-package.
Besides general clean up, helps distinguish between the RTS we link
against vs the RTS we compile for.
|
|
|
|
|
|
| |
This was done in Nixpkgs, but never upstreamed. Musl is pretty much
the same as gnu, but with a different libc. I’ve used the same values
for everything.
|
|
|
|
|
| |
If a main module doesn't contain a header, we omit the check whether the main module is exported.
With this patch GHC, GHCi and runghc use the same code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Zero size sections are common even during regular build on MacOS. For
instance:
```
$ ar -xv libHSghc-prim-0.6.1.a longlong.o
$ otool -l longlong.o
longlong.o:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
0xfeedfacf 16777223 3 0x00 1 2 176 0x00002000
Load command 0
cmd LC_SEGMENT_64
cmdsize 152
segname
vmaddr 0x0000000000000000
vmsize 0x0000000000000000 <-- segment size = 0
fileoff 208
filesize 0
maxprot 0x00000007
initprot 0x00000007
nsects 1
flags 0x0
Section
sectname __text
segname __TEXT
addr 0x0000000000000000
size 0x0000000000000000 <-- section size = 0
offset 208
align 2^0 (1)
reloff 0
nreloc 0
flags 0x80000000
reserved1 0
reserved2 0
cmd LC_BUILD_VERSION
cmdsize 24
platform macos
sdk 10.14
minos 10.14
ntools 0
```
The issue of `mmap`ing 0 bytes was resolved in !1050, but the problem
remained. These 0 size segments and sections were still allocated in
object code, which lead to failed `ASSERT(size > 0)` in
`addProddableBlock` further down the road.
With this change zero size segments **and** sections are not
mapped/allocated at all.
Test plan:
1. Build statically linked GHC.
2. Run `ghc --interactive`. Observe that REPL loads
successfully (which was not the case before).
3. Load several more compiled hs files into repl. No failures.
|
|
|
|
|
|
| |
You can always just not use or even build `iserv`. I don't think the
maintenance cost of the CPP is worth...I can't even tell what the
benefit is.
|
|
|
|
| |
not found.
|
|
|
|
|
|
|
|
|
|
|
| |
This has two benefits:
1. One less hunk of code dependent on DynFlags
2. Add a little bit of error granularity to distrinugish between missing
data and bad data. This could someday be shared with ghc-pkg which
aims to work even with a missing file. I also am about to to make
--supported-extensions use this too.
|
| |
|
|
|
|
|
|
| |
not used.
This fixes #10913.
|
|
|
|
| |
They are only used in a file we construct directly, so just skip CPP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The generated headers are now generated per stage, which means we can
skip hacks like `ghc_boot_platform.h` and just have that be the stage 0
header as proper. In general, stages are to be embraced: freely generate
everything in each stage but then just build what you depend on, and
everything is symmetrical and efficient. Trying to avoid stages because
bootstrapping is a mind bender just creates tons of bespoke
mini-mind-benders that add up to something far crazier.
Hadrian was pretty close to this "stage-major" approach already, and so
was fairly easy to fix. Make needed more work, however: it did know
about stages so at least there was a scaffold, but few packages except
for the compiler cared, and the compiler used its own counting system.
That said, make and Hadrian now work more similarly, which is good for
the transition to Hadrian. The merits of embracing stage aside, the
change may be worthy for easing that transition alone.
|
| |
|
|
|
|
|
| |
It may not exist if the source tarball was extracted yet not the
testsuite tarball.
|
|
|
|
|
|
|
| |
Function createIOThread expects its second argument to be of size word.
The natural size of the second parameter is 32bits. Thus for some 64bit
architectures, where a write of the lower half of a register does not
clear the upper half, the value must be zero extended.
|
|
|
|
| |
Zeros heap memory after gc freed it.
|
| |
|
|
|
|
|
| |
Previously we would throw an error which seems a bit harsh. As reported
in #17283.
|
|
|
|
|
|
|
| |
This modifies both the Hadrian and make build systems to avoid included
the rts.cabal generated by autoconf in the source distribution.
Fixes #17265.
|
|
|
|
| |
See #16205.
|
|
|
|
| |
This makes it match the others
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch also changes the way we handle empty lists, simplifying
them somewhat. See Note [Empty lists]. Previously, we had to
special-case empty lists in the type-checker. Now no more!
Finally, this patch improves some documentation around the ir_inst
field used in the type-checker.
This breaks a test case, but I really think the problem is #17251,
not really related to this patch.
Test case: typecheck/should_compile/T13680
|
|
|
|
| |
This is a good convenience for testing.
|
|
|
|
|
|
|
|
|
|
|
| |
Add a reference to the documentation for Data.List in the description
for String.
On the generated Haddock for Data.String,
http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-String.html
there is curently no hyperlink to Data.List, which is where a reader will find most of the useful functions which can operate on Strings. I imagine this has confused beginners who came to this page looking for String operations.
|