| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit redefines the structure of Splices in the AST.
We get rid of `HsSplice` which used to represent typed and untyped
splices, quasi quotes, and the result of splicing either an expression,
a type or a pattern.
Instead we have `HsUntypedSplice` which models an untyped splice or a
quasi quoter, which works in practice just like untyped splices.
The `HsExpr` constructor `HsSpliceE` which used to be constructed with
an `HsSplice` is split into `HsTypedSplice` and `HsUntypedSplice`. The
former is directly constructed with an `HsExpr` and the latter now takes
an `HsUntypedSplice`.
Both `HsType` and `Pat` constructors `HsSpliceTy` and `SplicePat` now
take an `HsUntypedSplice` instead of a `HsSplice` (remember only
/untyped splices/ can be spliced as types or patterns).
The result of splicing an expression, type, or pattern is now
comfortably stored in the extension fields `XSpliceTy`, `XSplicePat`,
`XUntypedSplice` as, respectively, `HsUntypedSpliceResult (HsType
GhcRn)`, `HsUntypedSpliceResult (Pat GhcRn)`, and `HsUntypedSpliceResult
(HsExpr GhcRn)`
Overall the TTG extension points are now better used to
make invalid states unrepresentable and model the progression between
stages better.
See Note [Lifecycle of an untyped splice, and PendingRnSplice]
and Note [Lifecycle of an typed splice, and PendingTcSplice] for more
details.
Updates haddock submodule
Fixes #21263
-------------------------
Metric Decrease:
hard_hole_fits
-------------------------
|
|
|
----------------
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
|
