More graceful error handling #11

New Issue

2017-02-28T00:06:12+01:00

ElvishJerricco commented

2017-02-28 00:06:12 +01:00

(Migrated from github.com)

I've opened two issues today about GHC features that Brittany doesn't support. When encountered, Brittany will error. Would it be possible to handle these cases more gracefully? Perhaps by simply ignoring them and giving back the original source for that line / code block?

lspitzner commented

2017-03-01 23:45:06 +01:00

(Migrated from github.com)

In general inserting the original source is problematic because it can create syntactically invalid code (imagine inside a do-block; brittany layouts it with more indentation; original source contains newlines with little indentation).

But I agree this can be improved; since brittany checks the output for synt. validity the user will get that error instead in the worst case. And for simple one-line cases it is unproblematic anyways. I have started implementing this, will finish in the next days.

In general inserting the original source is problematic because it can create syntactically invalid code (imagine inside a do-block; brittany layouts it with more indentation; original source contains newlines with little indentation). But I agree this can be improved; since brittany checks the output for synt. validity the user will get that error instead in the worst case. And for simple one-line cases it is unproblematic anyways. I have started implementing this, will finish in the next days.

lspitzner commented

2017-03-06 12:58:12 +01:00

(Migrated from github.com)

I noticed that, at least in theory, there can be cases where the syntactic validity check is not sufficient - if you are really unlucky, the exactprinted (i.e. original) source code may be valid haskell, syntactically and even semantically, but with different semantics than pre-transformation. I have not really explored which constructs would allow for that, but I'd rather be safe.
For that reason I have now added a flag, that defaults to "only use the original if it does not contain newlines" but otherwise error. If you want the theoretically risky behaviour (use original even with newlines), you can change your config to that behaviour as well.

There might be ways to make this safer, e.g. by inserting parentheses, but I don't want to spend too much time on this; it is all just a temporary fix until somebody finds time to implement all the syntactical constructs that brittany does not handle yet.

I noticed that, at least in theory, there can be cases where the syntactic validity check is not sufficient - if you are really unlucky, the exactprinted (i.e. original) source code may be valid haskell, syntactically and even semantically, but with different semantics than pre-transformation. I have not really explored which constructs would allow for that, but I'd rather be safe. For that reason I have now added a flag, that defaults to "only use the original if it does not contain newlines" but otherwise error. If you want the theoretically risky behaviour (use original even with newlines), you can change your config to that behaviour as well. There might be ways to make this safer, e.g. by inserting parentheses, but I don't want to spend too much time on this; it is all just a temporary fix until somebody finds time to implement all the syntactical constructs that brittany does not handle yet.

Sign in to join this conversation.

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: hexagoxel/brittany#11