- Apr 23, 2024
-
-
- Apr 22, 2024
-
-
It seems that our local Gitlab no longer has documentation for the `CODEOWNERS` file, but the master documentation still does. Use that instead.
-
- 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.
-
Serge S. Gulin authored
JS: Disable js linker warning for empty symbol table to make js tests running consistent across environments
-
Serge S. Gulin authored
By some reason MacOS builds add to stderr messages like: Ignoring unexpected archive entry: __.SYMDEF ... However I left stderr to `/dev/null` for compatibility with linux CI builds. -
Serge S. Gulin authored
After enabling jsdoc and built-in google closure compiler types I was needed to deal with the following: 1. Define NodeJS-environment types. I've just copied minimal set of externs from semi-official repo (see https://github.com/externs/nodejs/blob/6c6882c73efcdceecf42e7ba11f1e3e5c9c041f0/v8/nodejs.js#L8). 2. Define Emscripten-environment types: `HEAP8`. Emscripten already provides some externs in our code but it supposed to be run in some module system. And its definitions do not work well in plain bundle. 3. We have some functions which purpose is to add to functions some contextual information via function properties. These functions should be marked as `modifies` to let google closure compiler remove calls if these functions are not used actually by call graph. Such functions are: `h$o`, `h$sti`, `h$init_closure`, `h$setObjInfo`. 4. STG primitives such as registries and stuff from `GHC.StgToJS`. `dXX` properties were already present at externs generator function but they are started from `7`, not from `1`. This message is related: `// fixme does closure compiler bite us here?`
-
Serge S. Gulin authored
These errors were fixed just by introducing stubbed functions with throw for further implementation.
-
Serge S. Gulin authored
These errors were treated as a hard failure for browser application. The fix is trivial: just throw error.
-
Serge S. Gulin authored
code copied from GHCJS (fixes #24602) I've just copied some old pieces of GHCJS from publicly available sources (See https://github.com/Taneb/shims/blob/a6dd0202dcdb86ad63201495b8b5d9763483eb35/src/io.js#L607). Also I didn't put details to h$fds. I took minimal and left only its object initialization: `var h$fds = {};`
-
Serge S. Gulin authored
in a closure to prevent conflict with emscripten (fixes #24602) Better solution is to use some JavaScript module system like AMD, CommonJS or even UMD. It will be investigated at other issues. At first glance we should try UMD (See https://github.com/umdjs/umd)
-
Serge S. Gulin authored
-
Serge S. Gulin authored
You may noted that I've also changed term of ``` , global "h$vt_double" ||= toJExpr IntV ``` See "IntV" and ``` WaitReadOp -> \[] [fd] -> pure $ PRPrimCall $ returnS (app "h$waidRead" [fd]) ``` See "h$waidRead"
-
- Apr 20, 2024
-
-
Contributes to #24669
-
Historically quite a few packages had to be stage0 as they depended on `template-haskell` and that was stage0. In #23536 we made it so that was no longer the case. This allows us to remove a bunch of packages from this list. A few still remain. A new version of `Win32` is required by `semaphore-compat`. Including `Win32` in the stage0 set requires also including `filepath` because otherwise Hadrian's dependency logic gets confused. Once our boot compiler has a newer version of `Win32` all of these will be able to be dropped. Resolves #24652
-
-
We can save much code and explanation in Tag Inference and StgToCmm by making `seq#` a known-key Magic Id in `GHC.Internal.IO` and inline this definition in CorePrep. See the updated `Note [seq# magic]`. I also implemented a new `Note [Flatten case-bind]` to get better code for otherwise nested case scrutinees. I renamed the contructors of `ArgInfo` to use an `AI` prefix in order to resolve the clash between `type CpeApp = CoreExpr` and the data constructor of `ArgInfo`, as well as fixed typos in `Note [CorePrep invariants]`. Fixes #24252 and #24124.
-
Fixes #23764 Implements https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0640-tyop-quantification-order.rst Updates haddock submodule.
-
- Apr 19, 2024
-
-
-
Include the location of the prefix @ in the span for InVisPat. Also removes unnecessary annotations from HsTP. Contributes to #24669
-
And remove unused parameter in checkPatBind Contributes to #24669
-
-
Also extend the test to confirm. Addresses #24669, 1 of 4
-
This MR adjusts SetLevels so that it is less eager to float a HNF (lambda or constructor application) out of a lambda, unless it gets to top level. Data suggests that this change is a small net win: * nofib bytes-allocated falls by -0.09% (but a couple go up) * perf/should_compile bytes-allocated falls by -0.5% * perf/should_run bytes-allocated falls by -0.1% See !12410 for more detail. When fiddling elsewhere, I also found that this patch had a huge positive effect on the (very delicate) test perf/should_run/T21839r But that improvement doesn't show up in this MR by itself. Metric Decrease: MultiLayerModulesRecomp T15703 parsing001 -
isCross() was a misnamed because it assumed that all cross targets would provide a target wrapper, but the two most common cross targets (javascript, wasm) don't need a target wrapper. Therefore we rename this predicate to `needsTargetWrapper()` so situations in the testsuite where we can check whether running executables requires a target wrapper or not.
-
- Apr 17, 2024
-
-
Rather than `hide`. Closes #24659.
-
This was missing part of the unit ID meaning it would 404. Resolves #24674
-
We need a temporary directory, not a file.
-
-
This is used in exact printing to store comments coming after the `where` keyword but before any comments allocated to imports or decls. It is used in ghc-exactprint, see https://github.com/alanz/ghc-exactprint/commit/44bbed311fd8f0d053053fef195bf47c17d34fa7
-
While the RTS does attempt to mask signals, it may be that a foreign library unmasks them. This previously caused benign warnings which we now ignore. See #24610.
-
- Include all the .html files and assets in the job artefacts - Include all the .pdf files in the job artefacts - Mark the artefact as an "exposed" artefact meaning it turns up in the UI. Resolves #24651
-
Add a new method to the Instruction class to check if we can eliminate a jump in favour of fallthrough control flow. Fixes #24507
-
This MR addresses #24463. It's all explained in the new Note [Cloning CoVars and TyVars]
-
-
Promoting template-haskell from a stage0 to a stage1 package means that we can much more easily refactor template-haskell. We implement this by duplicating the in-tree `template-haskell`. A new `template-haskell-next` library is autogenerated to mirror `template-haskell` `stage1:ghc` to depend on the new interface of the library including the `Binary` instances without adding an explicit dependency on `template-haskell`. This is controlled by the `bootstrap-th` cabal flag When building `template-haskell` modules as part of this vendoring we do not have access to quote syntax, so we cannot use variable quote notation (`'Just`). So we either replace these with hand-written `Name`s or hide the code behind CPP. We can remove the `th_hack` from hadrian, which was required when building stage0 packages using the in-tree `template-haskell` library. For more details see Note [Bootstrapping Template Haskell]. Resolves #23536 Co-Authored-By:
Sebastian Graf <sgraf1337@gmail.com> Co-Authored-By:
Matthew Craven <5086-clyring@users.noreply.gitlab.haskell.org>
-
- Apr 15, 2024
-
-
Alex Mason authored
Also adds a test for MO_S_Mul2
-
- Apr 12, 2024
-
-
Previously, the logic for checking if a data constructor needs a wrapper or not would take into account whether the constructor's fields have explicit strictness (e.g., `data T = MkT !Int`), but the logic would _not_ take into account whether `StrictData` was enabled. This meant that something like `type data T = MkT Int` would incorrectly generate a wrapper for `MkT` if `StrictData` was enabled, leading to the horrible errors seen in #24620. To fix this, we disable generating wrappers for `type data` constructors altogether. Fixes #24620. Co-authored-by:Ryan Scott <ryan.gl.scott@gmail.com>
-
It is sometimes more useful to know how much bigger or smaller the nursery got when it is resized. In particular I am trying to investigate situations where we end up with fragmentation due to the nursery (#24577)
-
-
-
