| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This allows Other Numbers to be used in identifiers, and also documents
other, already existing lexer divergence from Haskell Report
|
|
|
|
|
|
| |
This adds support for -XGHC2021, as described in Proposal 0380 [1].
[1] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add missing :since: for NondecreasingIndentation and OverlappingInstances
- Remove duplicated descriptions for Safe Haskell flags and
UndecidableInstances. Instead, the sections contain a link.
- compare-flags: Also check for options supported by ghci.
This uncovered two more that are not documented.
The flag -smp was removed.
- Formatting fixes
- Remove the warning about -XNoImplicitPrelude - it was written in 1996,
the extension is no longer dangerous.
- Fix misspelled :reverse: flags
Fixes #18958.
|
| |
|
|
|
|
|
| |
The issue described in that section was fixed by
2b89ca5b850b4097447cc4908cbb0631011ce979
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch, we always parse f @t as a type application,
thereby producing better error messages.
This steals two syntactic forms:
* Prefix form of the @-operator in expressions. Since the @-operator is
a divergence from the Haskell Report anyway, this is not a major loss.
* Prefix form of @-patterns. Since we are stealing loose infix form
anyway, might as well sacrifice the prefix form for the sake of much
better error messages.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements a part of GHC Proposal #229 that covers five
operators:
* the bang operator (!)
* the tilde operator (~)
* the at operator (@)
* the dollar operator ($)
* the double dollar operator ($$)
Based on surrounding whitespace, these operators are disambiguated into
bang patterns, lazy patterns, strictness annotations, type
applications, splices, and typed splices.
This patch doesn't cover the (-) operator or the -Woperator-whitespace
warning, which are left as future work.
|
| |
|
|
|
|
| |
Previously several were referred to via :ghc-flag:`-X...`.
|
| |
|
| |
|
|
|
|
| |
Fixes #16644.
|
|
|
|
|
| |
This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The effect of this change is that -main-is changes the default
export list for the main module, but does not apply the same
change to non-main modules. This fixes some cases where -main-is
was used to wrap a module that expected that default behavior
(exporting `main`, even when that wasn't the main entry point
name).
Reviewers: mpickering, monoidal, bgamari
Subscribers: rwbarton, carter
GHC Trac Issues: #13704, #15702
Differential Revision: https://phabricator.haskell.org/D5322
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: allow -main-is to change export list for default module
header, allowing one to change the entry point to one's program.
Test Plan: ./validate
Reviewers: bgamari, nomeata, mpickering
Reviewed By: mpickering
Subscribers: mpickering, rwbarton, carter
GHC Trac Issues: #13704
Differential Revision: https://phabricator.haskell.org/D5189
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements the BlockArguments extension, as proposed at
https://github.com/ghc-proposals/ghc-proposals/pull/90. It also
fixes #10855 as a side-effect.
This patch adds a large number of shift-reduce conflicts to the parser.
All of them concern the ambiguity as to where constructs like `if` and
`let` end. Fortunately they are resolved correctly by preferring shift.
The patch is based on @gibiansky's ArgumentDo implementation (D1219).
Test Plan: ./validate
Reviewers: goldfire, bgamari, alanz, mpickering
Reviewed By: bgamari, mpickering
Subscribers: Wizek, dfeuer, gibiansky, rwbarton, thomie, mpickering, carter
GHC Trac Issues: #10843, #10855
Differential Revision: https://phabricator.haskell.org/D4260
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`MIN_VERSION_pkg` was documented backwards. An important caveat
about initializing the Haskell runtime was buried in a footnote.
The documentation of `-dynamic` was (even more) confusing.
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3582
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`Applicative` as a superclass of `Monad` is non-standard.
Fixes #13196.
[skip ci]
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D3185
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
D2917 added a change that will make paths on Windows response files
use DOS 8.3 shortnames to get around the fact that `libiberty` assumes
a one byte per character encoding.
This is actually not the problem, the actual problem is that GCC on
Windows doesn't seem to support Unicode at all.
This comes down to how unicode characters are handled between POSIX and
Windows. On Windows, Unicode is only supported using a multibyte character
encoding such as `wchar_t` with calls to the appropriate wide version of
APIs (name post-fixed with the `W` character). On Posix I believe the standard
`char` is used and based on the value it is decoded to the correct string.
GCC doesn't seem to make calls to the Wide version of the Windows APIs,
and even if it did, it's character representation would be wrong. So I
believe GCC just does not support utf-8 paths on Windows.
So the hack in D2917 is the only way to get Unicode support. The problem is
however that `GCC` is not the only tool with this issue and we don't use response
files for every invocation of the tools. Most of the tools probably don't support it.
Furthermore, DOS 8.1 shortnames only exist when the path or file physically exists on
disk. We pass lots of paths to GCC that don't exist yet, like the output file.
D2917 works around this by splitting the path from the file and try shortening that.
But this may not always work.
In short, even if we do Unicode correctly (which we don't atm, the GCC driver we build
uses `char` instead of `wchar_t`) we won't be able to compile using unicode paths that
need to be passed to `GCC`. So not sure about the point of D2917.
What we can do is support the most common non-ascii characters by writing the response
files out using the `latin1` code page.
Test Plan: compile + make test TEST=T12971
Reviewers: austin, bgamari, erikd
Reviewed By: bgamari
Subscribers: thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D2942
GHC Trac Issues: #12971
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Read it
Reviewers: dfeuer, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2515
GHC Trac Issues: #11691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds new methods `liftReadList(2)` and `liftReadListPrec(2)` to the
`Read1`/`Read2` classes which are defined in terms of `ReadPrec` instead
of `ReadS`. This also adds related combinators and changes existing
`Read1` and `Read2` instances to be defined in terms of the new methods.
Reviewers: hvr, austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2379
GHC Trac Issues: #12358
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes T11554
Reviewers: goldfire, thomie, simonpj, austin, bgamari
Reviewed By: thomie, simonpj, bgamari
Subscribers: simonpj, goldfire, thomie
Differential Revision: https://phabricator.haskell.org/D2283
GHC Trac Issues: #11554
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up of D2189. If fixes some comments, deletes a section
in the User's Guide about the bug, and updates .mailmap as suggested on
the WorkinConventions wiki page.
Test Plan: It compiles.
Reviewers: austin, simonmar, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2202
GHC Trac Issues: #11108
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Read it
Reviewers: austin
Reviewed By: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2052
GHC Trac Issues: #7411, #11197, #11554, #11715
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed in #2530 we are going to continue to produce parentheses
here in order to preserve compatibility with previous GHC releases. It
was found that dropped parentheses would break some testsuites which
compared against output from Show. This has been documented in the users
guide.
This reverts commit 5692643c9d17e746327588cd6157a923642b7975.
Test Plan: Validate
Reviewers: hvr, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2027
GHC Trac Issues: #2350
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Overhaul the Overhauled Pattern Match Checker
* Changed the representation of Value Set Abstractions. Instead of
using a prefix tree, we now use a list of Value Vector Abstractions.
The set of constraints Delta for every Value Vector Abstraction is the
oracle state so that we solve everything only once.
* Instead of doing everything lazily, we prune at once (and in general
everything is much stricter). Hence, an example written with pattern
guards is checked in almost the same time as the equivalent with
pattern matching.
* Do not store the covered and the divergent sets at all. Since what we
only need is a yes/no (does this clause cover anything? Does it force
any thunk?) We just keep a boolean for each.
* Removed flags `-Wtoo-many-guards` and `-ffull-guard-reasoning`.
Replaced with `fmax-pmcheck-iterations=n`. Still debatable what should
the default `n` be.
* When a guard is for sure not going to contribute anything, we treat
it as such: The oracle is not called and cases `CGuard`, `UGuard` and
`DGuard` from the paper are not happening at all (the generation of a
fresh variable, the unfolding of the pattern list etc.). his combined
with the above seems to be enough to drop the memory increase for test
T783 down to 18.7%.
* Do not export function `dsPmWarn` (it is now called directly from
within `checkSingle` and `checkMatches`).
* Make `PmExprVar` hold a `Name` instead of an `Id`. The term oracle
does not handle type information so using `Id` was a waste of
time/space.
* Added testcases T11195, T11303b (data families) and T11374
The patch addresses at least the following:
Trac #11195, #11276, #11303, #11374, #11162
Test Plan: validate
Reviewers: goldfire, bgamari, hvr, austin
Subscribers: simonpj, thomie
Differential Revision: https://phabricator.haskell.org/D1795
|
|
|
|
|
|
| |
And GHCi commands. This makes cross-referencing much easier.
Also normalize markup a bit and add some missing flags.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduction of two new flags, for more precise control over the new
pattern match checker's behaviour when reasoning about guards. This is
supposed to address #11195 (and maybe more performance bugs related to
the NP-Hardness of coverage checking).
Expected behaviour:
* When `-ffull-guard-reasoning` is on, run the new pattern match
checker in its full power
* When `-ffull-guard-reasoning` is off (the default), for every
match, check a metric to see whether pattern match checking for it
has high probability of being non performant (at the the moment we
check whether the number of guards is over 20 but I would like to
use a more precise measure in the future). If the probability is
high:
- Oversimplify the guards (less expressive but more performant)
and run the checker, and
- Issue a warning about the simplification that happened.
A new flag `-Wtoo-many-guards/-Wno-too-many-guards` suppresses the
warning about the simplification (useful when combined with -Werror).
Test Plan: validate
Reviewers: goldfire, austin, hvr, bgamari
Reviewed By: bgamari
Subscribers: mpickering, thomie
Differential Revision: https://phabricator.haskell.org/D1676
GHC Trac Issues: #11195
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Read it
Reviewers: austin, fryguybob
Reviewed By: austin
Subscribers: thomie, fryguybob
Differential Revision: https://phabricator.haskell.org/D1523
GHC Trac Issues: #10639, #367
|
|
|