| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Another step towards a simpler design for exact printing.
Updates the haddock submodule.
|
| |
|
|
|
| |
Another change in a series improving record syntax in the AST. The key
change in this commit is the renaming of `HsFieldLabel` to `DotFieldOcc`.
|
| |
|
|
| |
This patch is a first step towards a simpler design for exact printing.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- Change the names of the fields in in `data FieldOcc`
- Renames `HsRecFld` to `HsRecSel`
- Replace `AmbiguousFieldOcc p` in `HsRecSel` with `FieldOcc p`
- Contains a haddock submodule update
The primary motivation of this change is to remove
`AmbiguousFieldOcc`. This is one of a suite of changes improving how
record syntax (most notably record update syntax) is represented in
the AST.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch was driven by #18481, to allow visible type application
for levity-polymorphic newtypes. As so often, it started simple
but grew:
* Significant refactor: I removed HsConLikeOut from the
client-independent Language.Haskell.Syntax.Expr, and put it where it
belongs, as a new constructor `ConLikeTc` in the GHC-specific extension
data type for expressions, `GHC.Hs.Expr.XXExprGhcTc`.
That changed touched a lot of files in a very superficial way.
* Note [Typechecking data constructors] explains the main payload.
The eta-expansion part is no longer done by the typechecker, but
instead deferred to the desugarer, via `ConLikeTc`
* A little side benefit is that I was able to restore VTA for
data types with a "stupid theta": #19775. Not very important,
but the code in GHC.Tc.Gen.Head.tcInferDataCon is is much, much
more elegant now.
* I had to refactor the levity-polymorphism checking code in
GHC.HsToCore.Expr, see
Note [Checking for levity-polymorphic functions]
Note [Checking levity-polymorphic data constructors]
|
| |
|
|
|
|
| |
I tend to find Notes by (case-sensitive) grep, and I spent a surprisingly
long time looking for this Note, because it was referenced inconsistently
with different cases, and without the module name.
|
| |
|
|
|
|
| |
In comments, and notes.
Follow-up from !2418, see #19579
|
| |
|
|
|
|
|
|
| |
Metric Increase:
T10370
parsing001
Updates haddock submodule
|
| | |
|
|
|
----------------
What:
There are two splits.
The first spit is:
- `Language.Haskell.Syntax.Extension`
- `GHC.Hs.Extension`
where the former now just contains helpers like `NoExtCon` and all the
families, and the latter is everything having to do with `GhcPass`.
The second split is:
- `Language.Haskell.Syntax.<mod>`
- `GHC.Hs.<mod>`
Where the former contains all the data definitions, and the few helpers
that don't use `GhcPass`, and the latter contains everything else. The
second modules also reexport the former.
----------------
Why:
See the issue for more details, but in short answer is we're trying to
grasp at the modularity TTG is supposed to offer, after a long time of
mainly just getting the safety benefits of more complete pattern
matching on the AST.
Now, we have an AST datatype which, without `GhcPass` is decently
stripped of GHC-specific concerns. Whereas before, not was it
GHC-specific, it was aware of all the GHC phases despite the
parameterization, with the instances and parametric data structure
side-by-side.
For what it's worth there are also some smaller, imminent benefits:
- The latter change also splits a strongly connected component in two,
since none of the `Language.Haskell.Syntax.*` modules import the older
ones.
- A few TTG violations (Using GhcPass directly in the AST) in `Expr` are
now more explicitly accounted for with new type families to provide the
necessary indirection.
-----------------
Future work:
- I don't see why all the type families should live in
`Language.Haskell.Syntax.Extension`. That seems anti-modular for
little benefit. All the ones used just once can be moved next to the
AST type they serve as an extension point for.
- Decide what to do with the `Outputable` instances. Some of these are
no orphans because they referred to `GhcPass`, and had to be moved. I
think the types could be generalized so they don't refer to `GhcPass`
and therefore can be moved back, but having gotten flak for increasing
the size and complexity types when generalizing before, I did *not*
want to do this.
- We should triage the remaining contents of `GHC.Hs.<mod>`. The
renaming helpers are somewhat odd for needing `GhcPass`. We might
consider if they are a) in fact only needed by one phase b) can be
generalized to be non-GhcPass-specific (e.g. take a callback rather
than GADT-match with `IsPass`) and then they can live in
`Language.Haskell.Syntax.<mod>`.
For more details, see
https://gitlab.haskell.org/ghc/ghc/-/wikis/implementing-trees-that-grow
Bumps Haddock submodule
|
