- Jun 05, 2024
-
-
This commit removes 32-bit darwin/ios targets from llvm-targets given we no longer support them (#24921).
-
This commit removes all 32-bit darwin logic from the compiler, given we no longer support 32-bit apple systems (#24921). Also contains a bit more cleanup of obsolete i386 windows logic.
-
- Jun 04, 2024
-
-
This commit removes stdcall related legacy logic in libraries and utils. ccall should be used uniformly for all supported windows hosts from now on.
-
This commit removes i386 windows from llvm-targets and the script to generate it.
-
This commit introduces a new language extension, `-XOrPatterns`, as described in GHC Proposal 522. An or-pattern `pat1; ...; patk` succeeds iff one of the patterns `pat1`, ..., `patk` succeed, in this order. See also the summary `Note [Implmentation of OrPatterns]`. Co-Authored-By:Sebastian Graf <sgraf1337@gmail.com>
-
- Jun 03, 2024
-
-
For each module in a GHCi session, we keep alive one `ModLocation`. A `ModLocation` is fairly inefficiently packed, as `String`s are expensive in memory usage. While benchmarking the agda codebase, we concluded that we keep alive around 11MB of `FilePath`'s, solely retained by `ModLocation`. We provide a more densely packed encoding of `ModLocation`, by moving from `FilePath` to `OsPath`. Further, we migrate the full `Finder` component to `OsPath` to avoid unnecessary transformations. As the `Finder` component is well-encapsulated, this requires only a minimal amount of changes in other modules. We introduce pattern synonym for 'ModLocation' which maintains backwards compatibility and avoids breaking consumers of 'ModLocation'.
-
- May 31, 2024
-
-
Deriving `Typeable` does nothing, and it hasn't done for a long while. There has also been a warning for a long while which warns you about uselessly deriving it but it wasn't enabled in -Wall. Fixes #24784
-
- May 28, 2024
-
-
Thus we make `template-haskell` reinstallable and keep it as the public API for Template Haskell. All of the wired-in identifiers are moved to `ghc-internal`. This necessitates also moving much of `ghc-boot-th` into `ghc-internal`. These modules are then re-exported from `ghc-boot-th` and `template-haskell`. To avoid a dependency on `template-haskell` from `lib:ghc`, we instead depend on the TH ASTs via `ghc-boot-th`. As `template-haskell` no longer has special status, we can drop the logic adding an implicit dependency on `template-haskell` when using TH. We can also drop the `template-haskell-next` package, which was previously used when bootstrapping. When bootstrapping, we need to vendor the TH AST modules from `ghc-internal` into `ghc-boot-th`. This is controlled by the `bootstrap` cabal flag as before. See Note [Bootstrapping Template Haskell]. We split out a GHC.Internal.TH.Lift module resolving #24752. This module is only built when not bootstrapping. Resolves #24703 ------------------------- Metric Increase: ghc_boot_th_dir ghc_boot_th_so -------------------------
-
- May 24, 2024
-
-
-
-
(cherry picked from commit 994989ed3d535177e57b778629726aeabe8c7602)
-
(cherry picked from commit 7f3a5c4da0023ae47b4c376c9b1ea2d706c94d8c)
-
Previously this didn't include the `%M` token which manifested as broken links to the hyperlinked sources of reexports of declarations defined in other packages. Fixes haddock#1628. (cherry picked from commit 1432bcc943d41736eca491ecec4eb9a6304dab36)
-
-
-
- May 23, 2024
-
-
- May 22, 2024
-
-
-
-
-
-
The testsuite contained tests for annotations of the form `@since foo-bar-0.5.0`, but the parser was written incorrectly.
-
- Apply all the metadata revisions from Hackage to the cabal file. - Fix the `ParserSpec.hs` file in the `spec` testsuite of haddock-library. - Make `CHANGES.md` an extra-doc-file instead of an extra-source-file.
-
- May 19, 2024
-
-
- May 18, 2024
-
-
Jade authored
-
- May 17, 2024
-
-
Ben Gamari authored
In preparation for merge into the GHC, as proposed in #23178.
-
This patch fixes I/O manager compilation errors for win32 target discovered when cross-compiling to win32 using recent clang: ``` rts/win32/ThrIOManager.c:117:7: error: error: call to undeclared function 'is_io_mng_native_p'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 117 | if (is_io_mng_native_p ()) { | ^ | 117 | if (is_io_mng_native_p ()) { | ^ 1 error generated. `x86_64-w64-mingw32-clang' failed in phase `C Compiler'. (Exit code: 1) rts/fs.c:143:28: error: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 143 | int setErrNoFromWin32Error () { | ^ | void | 143 | int setErrNoFromWin32Error () { | ^ 1 error generated. `x86_64-w64-mingw32-clang' failed in phase `C Compiler'. (Exit code: 1) rts/win32/ConsoleHandler.c:227:9: error: error: call to undeclared function 'interruptIOManagerEvent'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 227 | interruptIOManagerEvent (); | ^ | 227 | interruptIOManagerEvent (); | ^ rts/win32/ConsoleHandler.c:227:9: error: note: did you mean 'getIOManagerEvent'? | 227 | interruptIOManagerEvent (); | ^ rts/include/rts/IOInterface.h:27:10: error: note: 'getIOManagerEvent' declared here 27 | void * getIOManagerEvent (void); | ^ | 27 | void * getIOManagerEvent (void); | ^ 1 error generated. `x86_64-w64-mingw32-clang' failed in phase `C Compiler'. (Exit code: 1) rts/win32/ConsoleHandler.c:196:9: error: error: call to undeclared function 'setThreadLabel'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 196 | setThreadLabel(cap, t, "signal handler thread"); | ^ | 196 | setThreadLabel(cap, t, "signal handler thread"); | ^ rts/win32/ConsoleHandler.c:196:9: error: note: did you mean 'postThreadLabel'? | 196 | setThreadLabel(cap, t, "signal handler thread"); | ^ rts/eventlog/EventLog.h:118:6: error: note: 'postThreadLabel' declared here 118 | void postThreadLabel(Capability *cap, | ^ | 118 | void postThreadLabel(Capability *cap, | ^ 1 error generated. `x86_64-w64-mingw32-clang' failed in phase `C Compiler'. (Exit code: 1) ```
-
- May 15, 2024
-
-
Co-Authored-By:romes <rodrigo.m.mesquita@gmail.com>
-
The type `IfaceType` is a highly redundant, tree-like data structure. While benchmarking, we realised that the high redundancy of `IfaceType` causes high memory consumption in GHCi sessions when byte code is embedded into the `.hi` file via `-fwrite-if-simplified-core` or `-fbyte-code-and-object-code`. Loading such `.hi` files from disk introduces many duplicates of memory expensive values in `IfaceType`, such as `IfaceTyCon`, `IfaceTyConApp`, `IA_Arg` and many more. We improve the memory behaviour of GHCi by adding an additional deduplication table for `IfaceType` to the serialisation of `ModIface`, similar to how we deduplicate `Name`s and `FastString`s. When reading the interface file back, the table allows us to automatically share identical values of `IfaceType`. To provide some numbers, we evaluated this patch on the agda code base. We loaded the full library from the `.hi` files, which contained the embedded core expressions (`-fwrite-if-simplified-core`). Before this patch: * Load time: 11.7 s, 2.5 GB maximum residency. After this patch: * Load time: 7.3 s, 1.7 GB maximum residency. This deduplication has the beneficial side effect to additionally reduce the size of the on-disk interface files tremendously. For example, on agda, we reduce the size of `.hi` files (with `-fwrite-if-simplified-core`): * Before: 101 MB on disk * Now: 24 MB on disk This has even a beneficial side effect on the cabal store. We reduce the size of the store on disk: * Before: 341 MB on disk * Now: 310 MB on disk Note, none of the dependencies have been compiled with `-fwrite-if-simplified-core`, but `IfaceType` occurs in multiple locations in a `ModIface`. We also add IfaceType deduplication table to .hie serialisation and refactor .hie file serialisation to use the same infrastrucutre as `putWithTables`. Bump haddock submodule to accomodate for changes to the deduplication table layout and binary interface.
-
We add an `Ord` instance so that we can store `IfaceType` in a `Data.Map` container. This is required to deduplicate `IfaceType` while writing `.hi` files to disk. Deduplication has many beneficial consequences to both file size and memory usage, as the deduplication enables implicit sharing of values. See issue #24540 for more motivation. The `Ord` instance would be unnecessary if we used a `TrieMap` instead of `Data.Map` for the deduplication process. While in theory this is clerarly the better option, experiments on the agda code base showed that a `TrieMap` implementation has worse run-time performance characteristics. To the change itself, we mostly derive `Eq` and `Ord`. This requires us to change occurrences of `FastString` with `LexicalFastString`, since `FastString` has no `Ord` instance. We change the definition of `IfLclName` to a newtype of `LexicalFastString`, to make such changes in the future easier. Bump haddock submodule for IfLclName changes
-
- May 14, 2024
-
-
GHCi only needs the `mi_globals` field for modules imported with :module +*SomeModule. It uses this field to make the top level environment in `SomeModule` available to the repl. By default, only the first target in the command line parameters is "star" loaded into GHCi. Other modules have to be manually "star" loaded into the repl. Storing the top level GlobalRdrEnv for each module is very wasteful, especially given that we will most likely never need most of these environments. Instead we store only the information needed to reconstruct the top level environment in a module, which is the `IfaceTopEnv` data structure, consisting of all import statements as well as all top level symbols defined in the module (not taking export lists into account) When a particular module is "star-loaded" into GHCi (as the first commandline target, or via an explicit `:module +*SomeModule`, we reconstruct the top level environment on demand using the `IfaceTopEnv`.
-
- May 07, 2024
-
-
Previously, C-- was processed with the C preprocessor program. This means that it inherited flags passed via -optc. A flag that is somewhat often passed through -optc is -g. At certain -g levels (>=2), GCC starts emitting defines *after* preprocessing, for the purposes of debug info generation. This is not useful for the C-- compiler, and, in fact, causes lexer errors. We can suppress this effect (safely, if supported) via -g0. As a workaround, in older versions of GCC (<=10), GCC only emitted defines if a certain set of -g*3 flags was passed. Newer versions check the debug level. For the former, we filter out those -g*3 flags and, for the latter, we specify -g0 on top of that. As a compatible and effective solution, this change adds a C-- preprocessor distinct from the C compiler and preprocessor, but that keeps its flags. The command line produced for C-- preprocessing now looks like: $pgmCmmP $optCs_without_g3 $g0_if_supported $optCmmP Closes: #24474
-
- May 04, 2024
-
-
This patch makes use of scheduler.postTask() for JSFFI context switch when it's available. It's a more principled approach than our MessageChannel based setImmediate() implementation, and it's available in latest version of Chromium based browsers.
-
- May 01, 2024
-
-
- Apr 30, 2024
-
-
Vagrantfile has long been removed in !5288. This commit further removes the obsolete vagrant scripts in the tree.
-
Closes #24708 Closes #24715 Closes #24734
-
- Apr 26, 2024
-
-
Closes #24670
-
A `BinHandle` contains too much information for reading data. For example, it needs to keep a `FastMutInt` and a `IORef BinData`, when the non-mutable variants would suffice. Additionally, this change has the benefit that anyone can immediately tell whether the `BinHandle` is used for reading or writing. Bump haddock submodule BinHandle split.
-
The goal is simplifiy adding deduplication tables to `ModIface` interface serialisation. We identify two main points of interest that make this difficult: 1. UserData hardcodes what `Binary` instances can have deduplication tables. Moreover, it heavily uses partial functions. 2. GHC.Iface.Binary hardcodes the deduplication tables for 'Name' and 'FastString', making it difficult to add more deduplication. Instead of having a single `UserData` record with fields for all the types that can have deduplication tables, we allow to provide custom serialisers for any `Typeable`. These are wrapped in existentials and stored in a `Map` indexed by their respective `TypeRep`. The `Binary` instance of the type to deduplicate still needs to explicitly look up the decoder via `findUserDataReader` and `findUserDataWriter`, which is no worse than the status-quo. `Map` was chosen as microbenchmarks indicate it is the fastest for a small number of keys (< 10). To generalise the deduplication table serialisation mechanism, we introduce the types `ReaderTable` and `WriterTable` which provide a simple interface that is sufficient to implement a general purpose deduplication mechanism for `writeBinIface` and `readBinIface`. This allows us to provide a list of deduplication tables for serialisation that can be extended more easily, for example for `IfaceTyCon`, see the issue ghc/ghc#24540 for more motivation. In addition to this refactoring, we split `UserData` into `ReaderUserData` and `WriterUserData`, to avoid partial functions and reduce overall memory usage, as we need fewer mutable variables. Bump haddock submodule to accomodate for `UserData` split. ------------------------- Metric Increase: MultiLayerModulesTH_Make MultiLayerModulesRecomp T21839c -------------------------
-
- Apr 21, 2024
-
-
Serge S. Gulin authored
Our js files have defined google closure compiler types at jsdoc entries but these jsdoc entries are removed by cpp preprocessor. I considered that reusing them in javascript-backend would be a nice thing. Right now haskell processor uses `-traditional` option to deal with comments and `//` operators. But now there are following compiler options: `-C` and `-CC`. You can read about them at GCC (see https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#index-CC) and CLang (see https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-CC). It seems that `-CC` works better for javascript jsdoc than `-traditional`. At least it leaves `/* ... */` comments w/o changes.
-
