| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Previously `isArchive` could leak a `FILE` handle if the `fread`
returned a short read.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the RTS linker would call initializers during the
"resolve" phase of linking. However, this is problematic in the
case of cyclic dependencies between objects. In particular, consider
the case where we have a situation where a static library
contains a set of recursive objects:
* object A has depends upon symbols in object B
* object B has an initializer that depends upon object A
* we try to load object A
The linker would previously:
1. start resolving object A
2. encounter the reference to object B, loading it resolve object B
3. run object B's initializer
4. the initializer will attempt to call into object A,
which hasn't been fully resolved (and therefore protected)
Fix this by moving constructor execution to a new linking
phase, which follows resolution.
Fix #21253.
|
| |
|
|
|
|
|
|
| |
swprintf deviates from usual `snprintf` semantics in that it does not
guarantee reasonable behavior when the buffer is NULL (that is,
returning the number of bytes that would have been emitted).
|
| |
|
| |
|
|
|
|
|
|
| |
We now preserve the address that we last mapped, allowing us to resume
our search and avoiding quadratic allocation costs. This fixes the
runtime of T10296a, which allocates many adjustors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a significant rework of the PEi386 linker, making the linker
compatible with high image base addresses. Specifically, we now use the
m32 allocator instead of `HeapAllocate`.
In addition I found a number of latent bugs in our handling of import
libraries and relocations. I've added quite a few comments describing
what I've learned about Windows import libraries while fixing these.
Thanks to Tamar Christina (@Phyx) for providing the address space search
logic, countless hours of help while debugging, and his boundless
Windows knowledge.
Co-Authored-By: Tamar Christina <tamar@zhox.com>
|
|
|
|
|
|
|
| |
Tables-next-to-code mandates that we treat symbols with info tables like
data since we cannot relocate them using a jump island.
See #20983.
|
|
|
|
|
|
|
|
| |
This fixes handling of overflowed relocations on PEi386 targets:
* Refuse to create jump islands for relocations of data symbols
* Correctly handle the `__imp___acrt_iob_func` symbol, which is an new
type of symbol: `SYM_TYPE_INDIRECT_DATA`
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As noted in #20978, the linker would previously handle overflowed
relocations by creating a jump island. While this is fine in the case of
code symbols, it's very much not okay in the case of data symbols. To
fix this we must keep track of whether each symbol is code or data and
relocate them appropriately. This patch takes the first step in this
direction, adding a symbol type field to the linker's symbol table. It
doesn't yet change relocation behavior to take advantage of this
knowledge.
Fixes #20978.
|
|
|
|
|
| |
Previously we would leak the section information of the `.bss`
section.
|
| |
|
|
|
|
|
| |
The matching on GhcPass introduced by 95275a5f25a is not necessary.
This patch reverts it to make the code simpler.
|
|
|
|
| |
Addresses #21295.
|
|
|
|
|
|
| |
This is necessary to build recent `text` commits.
Bumps Hackage index state for a hashable which builds with GHC 9.2.
|
|
|
|
|
| |
-Wuni-incomplete-patterns and apparent improvements in the pattern match
checker surfaced these.
|
|
|
|
| |
This makes it a bit easier to bump them.
|
| |
|
|
|
|
|
| |
Previously the `ipe` and `omit_pragmas` transformers were hackily
defined using the textual key-value syntax. Fix this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In !7511 (closed) I introduced a new allocator for adjustors,
AdjustorPool, which eliminates the address space fragmentation issues
which adjustors can introduce. In that work I focused on amd64 since
that was the platform where I observed issues.
However, in #21132 we noted that the size of adjustors is also a cause
of CI fragility on i386. In this MR I port i386 to use AdjustorPool.
Sadly the complexity of the i386 adjustor code does cause require a bit
of generalization which makes the code a bit more opaque but such is the
world.
Closes #21132.
|
|
|
|
| |
Unfortunately the i386 adjustor logic needs this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#20385)
Once we are done parsing the header of a module to obtain the options, we
look through the rest of the tokens in order to determine if they contain any
misplaced file header pragmas that would usually be ignored, potentially
resulting in bad error messages.
The warnings are reported immediately so that later errors don't shadow
over potentially helpful warnings.
Metric Increase:
T13719
|
|
|
|
| |
Since there may be .o files which are in fact archives.
|
|
|
|
| |
See #21068.
|
|
|
|
|
|
|
|
| |
Since object files may in fact be archive files, we must ensure that
their contents are merged rather than constructing an
archive-of-an-archive.
See #21068.
|
|
|
|
|
| |
Previously the setup was quite fragile as it had to assume which
arguments were file arguments and which were flags.
|
|
|
|
|
|
|
| |
On Windows we don't have a linker which supports object joining (i.e.
the `-r` flag). Consequently, `-pgmlm` is now a `Maybe`.
See #21068.
|
|
|
|
|
|
|
| |
Check the file's header to catch static archive bearing the `.o`
extension, as may happen on Windows after the Clang refactoring.
See #21068
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately, `lld`'s COFF backend does not currently support object
merging. With ld.bfd having broken support for high image-load base
addresses, it's necessary to find an alternative. Here I introduce
support in the driver for generating static archives, which we use on
Windows instead of object merging.
Closes #21068.
|
|
|
|
|
|
| |
Fixes #21335.
[ci skip]
|
|
|
|
|
|
|
| |
For reasons that remain a mystery, cabal-install seems to consistently
corrupt its cache on Windows. Disable caching for now.
Works around #21347.
|
|
|
|
|
|
|
|
| |
`tcExpr` typechecked implicit parameters by introducing a metavariable
of kind `TYPE kappa`, without enforcing that `kappa ~ LiftedRep`.
This patch instead creates a metavariable of kind `Type`.
Fixes #21327
|
| |
|
|
|
|
|
|
|
|
|
| |
It was previously not possible to use -XEmptyCase in Arrow notation,
since GHC would print "Exception: foldb of empty list".
This is now fixed.
Closes #21301
|
|
|
|
|
| |
This bug was fixed at some point between GHC 9.0 and GHC 9.2;
this patch simply adds a regression test.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit implements proposal 302: \cases - Multi-way lambda
expressions.
This adds a new expression heralded by \cases, which works exactly like
\case, but can match multiple apats instead of a single pat.
Updates submodule haddock to support the ITlcases token.
Closes #20768
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a PromotionFlag field to HsOpTy, which is used
in pretty-printing and when determining whether to emit warnings
with -fwarn-unticked-promoted-constructors.
This allows us to correctly report tick-related warnings for things
like:
type A = Int : '[]
type B = [Int, Bool]
Updates haddock submodule
Fixes #19984
|
|
|
|
|
|
|
|
|
| |
As noted in #20569 the documentation for search path was wrong because
it seemed to indicate that `-i` dirs were important when looking for
interface files in `-c` mode, but they are not important if `-hidir` is
set.
Fixes #20569
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
How things should work:
* -i is the search path for source files
* -hidir explicitly sets the search path for interface files and the output location for interface files.
* -odir sets the search path and output location for object files.
Before in one shot mode we would look for the interface file in the
search locations given by `-i`, but then set the path to be in the
`hidir`, so in unusual situations the finder could find an interface
file in the `-i` dir but later fail because it tried to read the
interface file from the `-hidir`.
A bug identified by #20569
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the past I improved the part of -Wunused-packages which found which
packages were used. Now I improve the part which detects which ones were
specified. The key innovation is to use the explicitUnits field from
UnitState which has the result of resolving the package flags, so we
don't need to mess about with the flag arguments from DynFlags anymore.
The output now always includes the package name and version (and the
flag which exposed it).
```
The following packages were specified via -package or -package-id flags,
but were not needed for compilation:
- bytestring-0.11.2.0 (exposed by flag -package bytestring)
- ghc-9.3 (exposed by flag -package ghc)
- process-1.6.13.2 (exposed by flag -package process)
```
Fixes #21307
|
|
|
|
|
| |
Users are supposed to import GHC.Exts rather than GHC.Prim.
Part of #18749.
|
|
|
|
|
|
|
|
| |
With the make build system this file ends up in the compiler/
subdirectory so is linted. With hadrian, the file ends up in _build so
it's not linted.
Fixes #21313
|
|
|
|
|
|
|
|
| |
There have been a few instances where this calculation was incorrect, so
we add a non-terminal assertion when now checks they the two
computations indeed compute the same thing.
Fixes #21285
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a small chance of a race occuring between the small window of
1. The first package (.conf) file get written into the database
2. hadrian calling "ghc-pkg recache" to refresh the package.conf file
In this window the package database would contain rts.conf but not a
package.cache file, and therefore if ghc was invoked it would error
because it was missing.
To solve this we call "ghc-pkg recache" at when the database is created
by shake by writing the stamp file into the database folder. This also
creates the package.cache file and so avoids the possibility of this
race.
|
|
|
|
| |
This has been dead code since 400ead81e80f66ad7b1260b11b2a92f25ccc3e5a.
|
|
|
|
|
|
|
| |
When pretty printing a HsCmdLam with more than one argument, GHC
panicked because of a missing case. This fixes that.
Closes #21300
|
| |
|
| |
|