Pass unknown syntactical constructs through instead of crashing #109
Labels
No Label
blocked: dependency
blocked: info-needed
bug
duplicate
enhancement
fixed in HEAD
help wanted
hs:arrows
hs:brackets
hs:classes
hs:comments
hs:do-notation
hs:guards
hs:lists
hs:operators
hs:patterns
hs:records
hs:types
invalid
language extension support
layouting
needs confirmation
priority: high
priority: low
question
revisit before next release
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: hexagoxel/brittany#109
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
With a file with pattern synonyms in it, for instance, Brittany throws errors. I'm fine with it supporting a subset of full GHC Haskell syntax, but could there be a switch or something to pass unknown syntactic forms through unmodified (like is done for data declarations at present)?
I wouldn't mind implementing this myself if someone points me to a source location or two.
@mrkgnao
brittany
does this in a number of places, but you'll generally be looking insrc/Language/Haskell/Brittany/Internal/Layouters/.
A quick fix, just for this extension, might be to modify
ppDecl
to just ignore thePatSynBind
node, along the lines ofthis is in
Language.Haskell.Brittany.Internal
.Regarding a more proper/general solution: It is true that the code currently assumes that there are "termination-worthy" errors, where we could just fall back on exactprint. We could wrap the whole
ppDecl
, run the writer-of-warnings/errors part of the transformer stack, check for termination-worthy errors, revert to exactprint and continue without aborting. This might turn bothErrorUnusedComment
andErrorUnknownNode
into warnings effectively.If we go that route, i'd consider throwing out the
PPM
transformer entirely (but notPPMLocal
) because it does not make sense to invent a specific transformer stack if we use the type for one function only (and then have to unwrap/switch to a different stack again anyways.) I.e. letppModule
have a transformer-free type.pull-requests for either solution welcome. I should probably do the PPM-related refactoring, as i started overusing MultiRWS - well the requirements changed over time, but whatever.