- Jun 03, 2019
-
-
Ben Gamari authored
Previously we would pass flags intended for the C compiler to the C++ compiler (see #16738). This would cause, for instance, `-std=gnu99` to be passed to the C++ compiler, causing spurious test failures. Fix this by maintaining a separate set of flags for C++ compilation invocations.
-
-
To cover ci conditions from ghc8.6 to 8.9, I add `-haddock` option to `.circleci/prepare-system.sh` and .gitlab-ci.yml. after including `mk/flavours/*`.
-
To cover ci conditions from ghc8.6 to 8.9, I add `-haddock` option to `mk/flavours/perf.mk` rather than `.circleci/prepare-system.sh`. Because in windows condition of ghc-8.9, `mk/flavours/*` is included after `prepare-system.sh`. In addition, in linux condition of ghc-8.6, `mk/flavors/perf.mk` is used.
-
In order to use the `:doc` command in ghci, it is necessary to compile for core libraries with `-haddock` option. Especially, the `-haddock` option is essential for release building. Note: * The `-haddock` option may affect compile time and binary size. * But hadrian has already set `-haddock` as the default. * This patch affects the make-based building. This patch has been split from !532.
-
- Jun 01, 2019
-
-
-
Fixes #16449. 5341edf3 removed a code in rewrite rules for bit shifts, which broke the "silly shift guard", causing generating invalid bit shifts or heap overflow in compile time while trying to evaluate those invalid bit shifts. The "guard" is explained in Note [Guarding against silly shifts] in PrelRules.hs. More specifically, this was the breaking change: --- a/compiler/prelude/PrelRules.hs +++ b/compiler/prelude/PrelRules.hs @@ -474,12 +474,11 @@ shiftRule shift_op ; case e1 of _ | shift_len == 0 -> return e1 - | shift_len < 0 || wordSizeInBits dflags < shift_len - -> return (mkRuntimeErrorApp rUNTIME_ERROR_ID wordPrimTy - ("Bad shift length" ++ show shift_len)) This patch reverts this change. Two new tests added: - T16449_1: The original reproducer in #16449. This was previously casing a heap overflow in compile time when CmmOpt tries to evaluate the large (invalid) bit shift in compile time, using `Integer` as the result type. Now it builds as expected. We now generate an error for the shift as expected. - T16449_2: Tests code generator for large (invalid) bit shifts.
-
When running the test suite on a GHC built with the `quick` build flavour, `-fghci-leak-check` noticed some space leaks. Careful investigation led to `Linker.dynLoadObjs` being the culprit. Pattern-matching on `PeristentLinkerState` and a dash of `$!` were sufficient to fix the issue. (ht to mpickering for his suggestions, which were crucial to discovering a fix) Fixes #16708.
-
This replaces a panic observed in #16702 with a simple error message stating that nested `forall`s simply aren't allowed in the type signature of a `foreign import` (at least, not at present). Fixes #16702.
-
By making it include parens when a derived instance would. For example, this changes the (hypothetical) code `show (Just (ThreadId 3))` to produce `"Just (ThreadId 3)"` instead of the current `"Just ThreadId 3"`.
-
- May 31, 2019
-
-
Implements #16686 The files version is automatically generated from the current GHC version in the same manner as normal interface files. This means that clients can first read the version and then decide how to read the rest of the file.
-
This allows us to make use of the (<$) implementations of the underlying functors.
-
-
`mkBootModDetailsTc`, which creates a special `ModDetails` when `-fno-code` is enabled, was not properly filling in the `COMPLETE` signatures from the `TcGblEnv`, resulting in incorrect pattern-match coverage warnings. Easily fixed. Fixes #16682.
-
Previously if we had f |> co where `f` had arity type `ABot N` and `co` had arity M and M < N, `arityType` would return `ABot M` which is wrong, because `f` is only known to diverge when applied to `N` args, as described in Note [ArityType]: If at = ABot n, then (f x1..xn) definitely diverges. Partial applications to fewer than n args may *or may not* diverge. This caused incorrect eta expansion in the simplifier, causing #16066. We now return `ATop M` for the same expression so the simplifier can't assume partial applications of `f |> co` is divergent. A regression test T16066 is also added. -
-
-
-
These were meant to be added in !214 but for some reason wasn't included in the patch. Update Haddock submodule for new Types.hs hyperlinker output
-
When ghc was built for powerpc32 built failed as: It's a fallout of commit 3f46cffc ("PPC NCG: Refactor stack allocation code") where word size used to be II32/II64 and changed to II8/panic "no width for given number of bytes" widthFromBytes ((platformWordSize platform) `quot` 8) The change restores initial behaviour by removing extra division. Signed-off-by:
Sergei Trofimovich <slyfox@gentoo.org>
-
On powerpc32 64-bit comparison code generated dangling target labels. This caused ghc build failure as: $ ./configure --target=powerpc-unknown-linux-gnu && make ... SCCs aren't in reverse dependent order bad blockId n3U This happened because condIntCode' in PPC codegen generated label name but did not place the label into `cmp_lo` code block. The change adds the `cmp_lo` label into the case of negative comparison. Signed-off-by: -
I updated the top documents to the latest status: - HACKING.md: - Modify Phabricator to GitLab infomation - Remove old Trac information - Add link to GitLab activity - MAKEHELP.md: - Add link to hadrian wiki - Fix markdown format - INSTALL.md: - Modify boot command to remove python3 - Fix markdown format - README.md: - Modify tarball file suffix - Fix markdown format I checked the page display on the GitHub and GitLab web. [skip ci] -
[skip ci]
-
- May 30, 2019
-
-
For the reasons described in Note [residency] we run programs with -G1 when we care about the max_bytes_used metric.
-
-
As per @mpickering's suggestion on IRC this is to make the partial module-graph more easily accessible for API clients which don't intend to re-implementing depanal.
-
-
This changes the way preprocessor failures are presented to the user. Previously the user would simply get an unlocated message on stderr such as: `gcc' failed in phase `C pre-processor'. (Exit code: 1) Now at the problematic source file is mentioned: A.hs:1:1: error: `gcc' failed in phase `C pre-processor'. (Exit code: 1) This also makes live easier for GHC API clients as the preprocessor error is now thrown as a SourceError exception. -
This enables API clients to handle such errors instead of immideately crashing in the face of some kinds of user errors, which is arguably quite bad UX. Fixes #10887
-
This introduces a slight change of behaviour in the interrest of keeping the code simple: Previously summariseModule would not call addHomeModuleToFinder for summaries that are being re-used but now we do. We're forced to to do this in summariseFile because the file being summarised might not even be on the regular search path! So if GHC is to find it at all we have to pre-populate the cache with its location. For modules however the finder cache is really just a cache so we don't have to pre-populate it with the module's location. As straightforward as that seems I did almost manage to introduce a bug (or so I thought) because the call to addHomeModuleToFinder I copied from summariseFile used to use `ms_location old_summary` instead of the `location` argument to checkSummaryTimestamp. If this call were to overwrite the existing entry in the cache that would have resulted in us using the old location of any module even if it was, say, moved to a different directory between calls to 'depanal'. However it turns out the cache just ignores the location if the module is already in the cache. Since summariseModule has to search for the module, which has the side effect of populating the cache, everything would have been fine either way. Well I'm adding a test for this anyways: tests/depanal/OldModLocation.hs.
-
-
-
-
This is to enable #10887 as well as to make it possible to test downsweep on its own in the testsuite.
-
-
-
We are iterating through all object code for each heap objects when checking whether object code can be unloaded. For large projects in GHCi, this can be very expensive due to the large number of object code that needs to be loaded/unloaded. To speed it up, this arrangess all mapped sections of unloaded object code in a sorted array and use binary search to check if an address location fall on them.
-
As noted in #16701, it is possible that we will find that an object has no segments needing to be mapped. Previously this would result in mmap being called for a zero-length mapping, which would fail. We now simply skip the mmap call in this case; the rest of the logic just works.
-
In !980 Richard noted that he could not approve the MR. This mis-spelling was the reason. [skip ci]
-
Instead of trying to deduce which dynlibs are expected to be found (and then copied to the RTS's build dir) in libffi's build directory, with some OS specific logic, we now always just use `getDirectoryFilesIO` to look for those dynlibs and record their names in the manifest. The previous logic ended up causing problems on Windows, where we don't build dynlibs at all for now but the manifest file's logic didn't take that into account because it was only partially reproducing the criterions that determine whether or not we will be building shared libraries. This patch also re-enables the Hadrian/Windows CI job, which was failing to build GHC precisely because of libffi shared libraries and the aforementionned duplicated logic.
-
