- Mar 23, 2024
-
-
-
When checking if a jump has more than one destination account for the possibility of some jumps not being representable by a BlockId. We do so by having isJumpishInstr return a `Maybe BlockId` where Nothing represents non-BlockId jump destinations. Fixes #24507
-
This hint is outdated, ``Complex Float`` are now specialised, and the heap space suggestion needs more nuance so it should be explained in the unboxed/storable array documentation.
-
This fixes #24553, where GHC unhelpfully said error: [GHC-83865] • Expected kind ‘* -> * -> *’, but ‘Foo’ has kind ‘* -> * -> *’ See Note [Showing invisible bits of types in error messages] -
Fixes for a bug in desugaring pattern synonyms matches, introduced while working on on expanding `do`-blocks in #18324 The `matchWrapper` unecessarily (and incorrectly) filtered out the default wild patterns in a match. Now the wild pattern alternative is simply ignored by the pm check as its origin is `Generated`. The current code now matches the expected semantics according to the language spec.
-
On 64-bit platforms, every Word32 fits in an Int, so we can convert to Int# without having to perform the overflow check integerFromWord# uses internally.
-
- Mar 22, 2024
-
-
In #24551, we abstracted a string literal binding over a type variable, triggering a CoreLint error when that binding floated to top-level. The solution implemented in this patch fixes this by re-doing dependency analysis on a simplified recursive let binding that is about to be type abstracted, in order to find the minimal set of type variables to abstract over. See wrinkle (AB5) of Note [Floating and type abstraction] for more details. Fixes #24551
-
-
- Use unsafeChr because we know our values to be valid - Remove some unnecessary use of `ord` (return Word8 values directly)
-
See added Note and #24566. Default declarations must be type-checked before deriving clauses.
-
- Mar 21, 2024
-
-
There was missing case for `SplicePat` in `pat_to_type_at` function, hence patterns with splicing that checked against `forall->` doesn't work properly because they fall into the "illegal pattern" case. Code example that is now accepted: g :: forall a -> () g $([p| a |]) = ()
-
The documentation for Data.Complex says that the Ord instance for Complex Float is deficient, but there is no Ord instance for Complex a. The Eq instance for Complex Float is similarly deficient, so we use that as an example instead.
-
Type operators differ from term operators in that they are lexically classified as (type) constructors, not as (type) variables. Prior to this change, promoteOccName did not account for this difference, causing a scoping issue that affected RequiredTypeArguments. type (!@#) = Bool f = idee (!@#) -- Not in scope: ‘!@#’ (BUG) Now we have a special case in promoteOccName to account for this.
-
- Introduce a helper lens to compose on `EpAnn a` vs `a` versions - Rename some prime versions of functions back to non-prime They were renamed during the rework
-
- Mar 20, 2024
-
-
Simon Peyton Jones authored
Fixes #24559
-
In #24563, we identified that IfaceAppArgs serialisation tags each cons cell element with a discriminator byte. These bytes add up quickly, blowing up interface files considerably when '-fwrite-if-simplified-core' is enabled. We compact the serialisation by writing out the length of 'IfaceAppArgs', followed by serialising the elements directly without any discriminator byte. This improvement can decrease the size of some interface files by up to 35%.
-
This reverts commit c82770f5. The shellcheck suggestion is spurious and results in SUBST_TOOLDIR being a no-op. `set` sets positional arguments for bash, but we want to set the variable given as the first autoconf argument. Fixes #24542 Metric decreases because the paths in the settings file are now shorter, so we allocate less when we read the settings file. ------------------------- Metric Decrease: T12425 T13035 T9198 -------------------------
-
ghcup can apparently infer the output name of an artifact from its URL. Consequently, we should only include the `dlOutput` field when it would differ from the filename of `dlUri`. Fixes #24547.
-
As reported in #24546, the `dlTest` artifact should be extracted into the `testsuite` directory.
-
Previously we would rather compress the xz *again*, before in addition compressing it with the desired scheme. Fixes #24545.
-
-
-
This fixes #24525, a regression due to 41cbaf44. Specifically, GHC expects to find the mingw32 toolchain in the binary distribution root. However, after this patch it was packaged in the `lib/` directory.
-
Previously we would call `dirname` twice per installed library file. We now instead reuse this result. This helps appreciably on Windows, where processes are quite expensive.
-
- Mar 19, 2024
-
-
-
Previously there were two instances in this script which lacked proper quoting. This resulted in `relpath` invocations in the binary distribution Makefile producing incorrect results on Windows, leading to confusing failures from `sed` and the production of empty package registrations. Fixes #24538.
-
- GHC.HsToCore.Foreign.JavaScript: remove dropRuntimeRepArgs; boxed tuples don't take RuntimeRep args - GHC.HsToCore.Foreign.Call: avoid partial pattern matching - GHC.Stg.Unarise: strengthen the assertion; we can assert that non-rubbish literals are unary rather than just non-void - GHC.Tc.Gen.HsType: make sure the fsLit "literal" rule fires - users_guide/using-warnings.rst: remove -Wforall-identifier, now deprecated and does nothing - users_guide/using.rst: fix formatting - andy_cherry/test.T: remove expect_broken_for(23272...), 23272 is fixed The rest are simple cleanups.
-
Heap analysis showed that `IfaceTyCon` retains a thunk to `IfaceTyConInfo`, defeating the sharing of the most common instances of `IfaceTyConInfo`. We make sure the indirection is removed by adding bang patterns to `IfaceTyCon`. Experimental results on the agda code base, where the `mi_extra_decls` were read from disk: Before this change, we observe around 8654045 instances of: `IfaceTyCon[Name,THUNK_1_0]` But these thunks almost exclusively point to a shared value! Forcing the thunk a little bit more, leads to `ghc-debug` reporting: `IfaceTyCon[Name:Name,IfaceTyConInfo]` and a noticeable reduction of live bytes (on agda ~10%).
-
Don't use bigNatFromWord#, because that's terrible: * We shouldn't have to traverse a linked list at run-time to build a BigNat# literal. That's just silly! * The static List object we have to create is much larger than the actual BigNat#'s contents, bloating code size. * We have to read the corresponding interface file, which causes un-tracked implicit dependencies. (#23942) Instead, encode them into the appropriate platform-dependent sequence of bytes, and generate code that copies these bytes at run-time from an Addr# literal into a new ByteArray#. A ByteArray# literal would be the correct thing to generate, but these are not yet supported; see also #17747. Somewhat surprisingly, this change results in a slight reduction in compiler allocations, averaging around 0.5% on ghc's compiler performance tests, including when compiling programs that contain no bignum literals to begin with. The specific cause of this has not been investigated. Since this lowering no longer reads the interface file for GHC.Num.BigNat, the reasoning in Note [Depend on GHC.Num.Integer] is obsoleted. But the story of un-tracked built-in dependencies remains complex, and Note [Tracking dependencies on primitives] now exists to explain this complexity. Additionally, many empty imports have been modified to refer to this new note and comply with its guidance. Several empty imports necessary for other reasons have also been given brief explanations. Metric Decrease: MultiLayerModulesTH_OneShot -
-
Now instead of producing wrappers which pass the global package database argument to ghc and ghc-pkg, we write the location of the correct package database into the settings file so you can just use the intree compiler directly.
-
Before this patch, the global package database was always assumed to be in libdir </> package.conf.d. This causes issues in GHC's build system because there are sometimes situations where the package database you need to use is not located in the same place as the settings file. * The stage1 compiler needs to use stage1 libraries, so we should set "Global Package DB" for the stage1 compiler to the stage1 package database. * Stage 2 cross compilers need to use stage2 libraries, so likewise, we should set the package database path to `_build/stage2/lib/` * The normal situation is where the stage2 compiler uses stage1 libraries. Then everything lines up. * When installing we have rearranged everything so that the settings file and package database line up properly, so then everything should continue to work as before. In this case we set the relative package db path to `package.conf.d`, so it resolves the same as before. * ghc-pkg needs to be modified as well to look in the settings file fo the package database rather than assuming the global package database location relative to the lib folder. * Cabal/cabal-install will work correctly because they query the global package database using `--print-global-package-db`. A reasonable question is why not generate the "right" settings files in the right places in GHC's build system. In order to do this you would need to engineer wrappers for all executables to point to a specific libdir. There are also situations where the same package db is used by two different compilers with two different settings files (think stage2 cross compiler and stage3 compiler). In short, this 10 line patch allows for some reasonable simplifications in Hadrian at very little cost to anything else. Fixes #24502
-
Uses responseFile syntax. The issue arises when GHC is installed on windows into a location that has a space, for example the user name is 'Fake User'. The $topdir will also contain a space, consequentially. When we resolve the top dir in the string `-I$topdir/mingw/include`, then `words` will turn this single argument into `-I/C/Users/Fake` and `User/.../mingw/include` which trips up the flag argument parser of various tools such as gcc or clang. We avoid this by escaping the $topdir before replacing it in `initSettngs`. Additionally, we allow to escape spaces and quotation marks for arguments in `settings` file. Add regression test case to count the number of options after variable expansion and argument escaping took place. Additionally, we check that escaped spaces and double quotation marks are correctly parsed.
-
Closes #24533 Hopefully for good this time
-
During heap analysis, we noticed that during generation of 'mi_extra_decls' we have lots of duplicates for the instances: * `IfaceTyConInfo NotPromoted IfaceNormalTyCon` * `IfaceTyConInfo IsPromoted IfaceNormalTyCon` which should be shared instead of duplicated. This duplication increased the number of live bytes by around 200MB while loading the agda codebase into GHCi. These instances are created during `CoreToIface` translation, in particular `toIfaceTyCon`. The generated core looks like: toIfaceTyCon = \ tc_sjJw -> case $wtoIfaceTyCon tc_sjJw of { (# ww_sjJz, ww1_sjNL, ww2_sjNM #) -> IfaceTyCon ww_sjJz (IfaceTyConInfo ww1_sjNL ww2_sjNM) } whichs removes causes the sharing to work propery. Adding explicit sharing, with NOINLINE annotations, changes the core to: toIfaceTyCon = \ tc_sjJq -> case $wtoIfaceTyCon tc_sjJq of { (# ww_sjNB, ww1_sjNC #) -> IfaceTyCon ww_sjNB ww1_sjNC } which looks much more like sharing is happening. We confirmed via ghc-debug that all duplications were eliminated and the number of live bytes are noticeably reduced.
-
- Mar 14, 2024
-
-
Closes #24533
-
Without an understanding of immutable vs. mutable memory, the index primop family have a potentially non-intuitive type signature: indexOffAddr :: Addr# -> Int# -> a readOffAddr :: Addr# -> Int# -> State# d -> (# State# d, a #) indexOffAddr# might seem like a free generality improvement, which it certainly is not! This change adds a brief note on mutability expectations for most index/read/write access primops.
-
- Mar 12, 2024
-
-
This commit fixes an unnoticed out-of-bound memory access of genSym on 32-bit. ghc_unique_inc is 32-bit sized/aligned on 32-bit platforms, but we mistakenly treat it as a Word64 pointer in genSym, and therefore will accidentally load 2 garbage higher bytes, or with a small but non-zero chance, overwrite something else in the data section depends on how the linker places the data segments. This regression was introduced in !11802 and fixed here.
-
This reverts commit 615eb855. It was originally intended to fix #24449, but it was merely sweeping the bug under the rug. 3836a110 has properly fixed the fragile test, and we no longer need the C version of genSym. Furthermore, the C implementation causes trouble when compiling with clang that targets i386 due to alignment warning and libatomic linking issue, so it makes sense to revert it.
-
-
