- Aug 07, 2023
-
-
-
-
This fixes some missing local variable declarations that were found by running the testsuite in strict mode. Fixes #23775
-
- Aug 05, 2023
-
-
Luite Stegeman authored
The JavaScript code in libraries/base/jsbits/base.js had some hardcoded offsets for fields in structs, because we expected the layout of the data structures to remain unchanged. Emsdk 3.1.42 changed the layout of the stat struct, breaking this assumption, and causing code in .hsc files accessing the stat struct to fail. This patch improves compatibility with recent emsdk by removing the assumption that data layouts stay unchanged: 1. offsets of fields in structs used by JavaScript code are now computed by the configure script, so both the .js and .hsc files will automatically use the new layout if anything changes. 2. the distrib/configure script checks that the emsdk version on a user's system is the same version that a bindist was booted with, to avoid data layout inconsistencies See #23641 -
Ensuring that nofib can be build using the same range of bootstrap compilers as GHC itself.
-
This removes the zonk in GHC.Tc.Gen.App.tc_inst_forall_arg and its accompanying Note [Visible type application zonk]. Indeed, this zonk is no longer necessary, as we no longer maintain the invariant that types are well-kinded without zonking; only that typeKind does not crash; see Note [The Purely Kinded Type Invariant (PKTI)]. This commit removes this zonking step (as well as a secondary zonk), and replaces the aforementioned Note with the explanatory Note [Type application substitution], which justifies why the substitution performed in tc_inst_forall_arg remains valid without this zonking step. Fixes #23661
-
This Note attempts to summarize the treatment of thunks, thunk update, and indirections. This fell out of work on #23185.
-
-
- Aug 04, 2023
-
-
When adding an implicit parameter dictionary to the inert set, we must make sure that it replaces any previous implicit parameter dictionaries that overlap, in order to get the appropriate shadowing behaviour, as in let ?x = 1 in let ?x = 2 in ?x We were already doing this for inert_cans, but we weren't doing the same thing for inert_solved_dicts, which lead to the bug reported in #23761. The fix is thus to make sure that, when handling an implicit parameter dictionary in updInertDicts, we update **both** inert_cans and inert_solved_dicts to ensure a new implicit parameter dictionary correctly shadows old ones. Fixes #23761
-
Fixes #17900; fixes #20195. The existing "can_fail" and "has_side_effects" primop attributes that previously governed this were used in inconsistent and confusingly-documented ways, especially with regard to raising exceptions. This patch replaces them with a single "effect" attribute, which has four possible values: NoEffect, CanFail, ThrowsException, and ReadWriteEffect. These are described in Note [Classifying primop effects]. A substantial amount of related documentation has been re-drafted for clarity and accuracy. In the process of making this attribute format change for literally every primop, several existing mis-classifications were detected and corrected. One of these mis-classifications was tagToEnum#, which is now considered CanFail; this particular fix is known to cause a regression in performance for derived Enum instances. (See #23782.) Fixing this is left as future work. New primop attributes "cheap" and "work_free" were also added, and used in the corresponding parts of GHC.Core.Utils. In view of their actual meaning and uses, `primOpOkForSideEffects` and `exprOkForSideEffects` have been renamed to `primOpOkToDiscard` and `exprOkToDiscard`, respectively. Metric Increase: T21839c -
Hackage upload requires this.
-
This is basically a no-op change, but allows us to make future changes that can rely on the HasLoc instances And I presume this means we can use more precise functions based on class resolution, so the Windows CI build reports Metric Decrease: T12234 T13035 -
Fixes the layout of the ghc-toolchain validation warning produced by configure.
-
Makes suggestions when using `:set` in GHCi with a misspelled flag. This mirrors how invalid flags are handled when passed to GHC directly. Logic for producing flag suggestions was moved to GHC.Driver.Sesssion so it can be shared. resolves #23663
-
8168b42a "Whitespace-sensitive bang patterns" allows GHC to accept the following infix operators: a ~ b = () a @ b = () But not if TH is used to generate those declarations: $([d| a ~ b = () a @ b = () |]) -- Test.hs:5:2: error: [GHC-55017] -- Illegal variable name: ‘~’ -- When splicing a TH declaration: (~_0) a_1 b_2 = GHC.Tuple.Prim.() This is easily fixed by modifying `reservedOps` in GHC.Utils.Lexeme
-
-
Previously the 32-bit implementations of MulMayOflo would use the a non-sensical sign-extension mode. Rewrite these to reflect what gcc 11 produces. Also similarly rework the 16- and 8-bit cases. This now passes the MulMayOflo tests in ghc/test-primops> in all four widths, including the precision tests. Fixes #23721.
-
To ensure that we don't accidentally fix it. See #23742.
-
Previously we incorrectly interpreted PE section numbers as signed values. However, this isn't the case; rather, it's an unsigned 16-bit number with a few special bit-patterns (0xffff and 0xfffe). This resulted in #22941 as the linker would conclude that the sections were invalid. Fixing this required quite a bit of refactoring. Closes #22941.
-
This eliminates spurious changes from version bumps.
-
-
This test passes on dynamically-linked Alpine. (cherry picked from commit f356a7e8)
-
Due to spurious output changes described in #23648. (cherry picked from commit c046a238)
-
In backpack hashes can contain `+` characters. (cherry picked from commit 024861af)
-
Updates all boot library submodules. (cherry picked from commit 433d99a3)
-
Bumps exceptions submodule. (cherry picked from commit bf57fc9a)
-
(cherry picked from commit d3ffdaf9)
-
And bump bounds (cherry picked from commit 1228d3a4)
-
This modifies `splitHsApps` (a key function used in typechecking function applications) to look through untyped TH splices and quasiquotes. Not doing so was the cause of #21077. This builds on !7821 by making `splitHsApps` match on `HsUntypedSpliceTop`, which contains the `ThModFinalizers` that must be run as part of invoking the TH splice. See the new `Note [Looking through Template Haskell splices in splitHsApps]` in `GHC.Tc.Gen.Head`. Along the way, I needed to make the type of `splitHsApps.set` slightly more general to accommodate the fact that the location attached to a quasiquote is a `SrcAnn NoEpAnns` rather than a `SrcSpanAnnA`. Fixes #21077.
-
When the Win32 threaded IO manager shuts down, `ioManagerDie` sends an `IO_MANAGER_DIE` event to the IO manager thread using the `io_manager_event` event object. Finally, it will closes the event object, and invalidate `io_manager_event`. Previously, `readIOManagerEvent` would see that `io_manager_event` is invalid and return `0`, suggesting that everything is right with the world. This meant that if `ioManagerDie` invalidated the handle before the event manager was blocked on the event we would end up in a situation where the event manager would never realize it was asked to shut down. Fix this by ensuring that `readIOManagerEvent` instead returns `IO_MANAGER_DIE` when we detect that the event object has been invalidated by `ioManagerDie`. Fixes #23691.
-
-
- Aug 03, 2023
-
-
Gergő Érdi authored
incoherent instances Fixes #23287
-
Gergő Érdi authored
Closes #23172
-
- Aug 02, 2023
-
-
-
-
This reverts commit 522bd584. And takes care of the case that I missed in my previous attempt. Namely the case of an AbsBinds with no type variables and no dictionary variable. Ironically, the comment explaining why non-recursive lets were desugared to recursive lets were pointing specifically at this case as the reason. I just failed to understand that it was until Simon PJ pointed it out to me. See #23550 for more discussion.
-
-
This was the cause of #23541.
-
By using a proper release store instead of a fence.
-
Warnings when building Hadrian can end up cluttering the output of HLS, and we've had bug reports in the past about these warnings when building Hadrian. It would be nice to turn on -Werror on at least one build of Hadrian in CI to avoid a patch introducing warnings when building Hadrian. Fixes #23638
-
