- Apr 06, 2021
-
-
-
-
This reverts commit 0cbdba27.
-
Previously we used this non-portable function unconditionally, breaking FreeBSD. Fixes #19637.
-
-
Not only does this eliminate some code duplication but we also add a maximum core count to HLint's command-line, hopefully avoiding issue #19600.
-
-
-
See #17018.
-
It is incorrectly displayed in hackage as: `m1 <*> m2 = m1 >>= (x1 -> m2 >>= (x2 -> return (x1 x2)))` which isn't correct Haskell
-
In version 0.12.2.0 of vector when used with GHC-9.0 we rebox values from storeable mutable vectors. This should catch such a change in the future.
-
-
-
and not just the name on the binary on the `$PATH`.
-
Fixes #19616. This commit changes the `GHC.Driver.Errors.handleFlagWarnings` function to rely on the newly introduced `DiagnosticReason`. This allows us to correctly pretty-print the flags which triggered some warnings and in turn remove the cruft around this function (like the extra filtering and the `shouldPrintWarning` function.
-
This commit introduces a new `Severity` type constructor called `SevIgnore`, which can be used to classify diagnostic messages which are not meant to be displayed to the user, for example suppressed warnings. This extra constructor allows us to get rid of a bunch of redundant checks when emitting diagnostics, typically in the form of the pattern: ``` when (optM Opt_XXX) $ addDiagnosticTc (WarningWithFlag Opt_XXX) ... ``` Fair warning! Not all checks should be omitted/skipped, as evaluating some data structures used to produce a diagnostic might still be expensive (e.g. zonking, etc). Therefore, a case-by-case analysis must be conducted when deciding if a check can be removed or not. Last but not least, we remove the unnecessary `CmdLine.WarnReason` type, which is now redundant with `DiagnosticReason`.
-
-
In the common case where the list of ticks is empty, building a thunk just applies 'reverse' to '[]' which is quite wasteful.
-
This allows Other Numbers to be used in identifiers, and also documents other, already existing lexer divergence from Haskell Report
-
To support proper parsing of arm64 targets, we needed to adjust the GHC_LLVM_TARGET function to allow parsing arm64-apple-darwin into aarch64. This however discared the proper os detection. To rectify this, we'll pull the os detection into separate block. Fixes #19173.
-
- Apr 02, 2021
-
-
It appears that the issue has already been fixed. Judging by the use of a pattern synonym with a provided constraint, my bet is on 1793ca9d. Fixes #19622.
-
-
Ticket #19576 noted that a test that failed in correctness (e.g. due to stderr mismatch) *and* failed due to a metrics change would report misleading stats. This was due to the testsuite driver *first* checking stats, before checking for correctness. Fix this. Closes #19576.
-
-
-
We don't want these failing merely due to performance metrics
-
Ensure that deb10-dwarf artifacts are preserved.
-
These now live in the ghc-tarballs/mingw-w64 directory. Fixes #19316.
-
- Apr 01, 2021
-
-
-
-
This commit further expand on the design for #18516 by getting rid of the `defaultReasonSeverity` in favour of a function called `diagReasonSeverity` which correctly takes the `DynFlags` as input. The idea is to compute the `Severity` and the `DiagnosticReason` of each message "at birth", without doing any later re-classifications, which are potentially error prone, as the `DynFlags` might evolve during the course of the program. In preparation for a proper refactoring, now `pprWarning` from the Parser.Ppr module has been renamed to `mkParserWarn`, which now takes a `DynFlags` as input. We also get rid of the reclassification we were performing inside `printOrThrowWarnings`. Last but not least, this commit removes the need for reclassify inside GHC.Tc.Errors, and also simplifies the implementation of `maybeReportError`. Update Haddock submodule
-
When the CharToNat and NatToChar type families were added, the corresponding axioms were not exported. This led to a failure much like #14934
-
-
As noted in my comment on #19058, this comment was previously a bit misleading in the case of stable branches.
-
-
-
-
-
-
-
