Skip to content
This repository has been archived by the owner on Apr 25, 2020. It is now read-only.

Typed holes treated as exceptions #536

Closed
acowley opened this issue Aug 13, 2015 · 9 comments
Closed

Typed holes treated as exceptions #536

acowley opened this issue Aug 13, 2015 · 9 comments

Comments

@acowley
Copy link
Contributor

acowley commented Aug 13, 2015

If you try to get info (or doc) on an expression within a module that includes typed holes, ghc-mod is tripped up by an exception regarding the typed hole.

Expected result: typed holes shouldn't stop info or doc from working. I'm taking a quick look at this now; any guidance is appreciated.

@DanielG
Copy link
Owner

DanielG commented Aug 13, 2015

Probably just needs the same fix as this: #438 (comment)

@acowley
Copy link
Contributor Author

acowley commented Aug 13, 2015

Okay, I think I have this going now, but it obviously overlaps a lot with your link. Do you want to wait for that fix to come in, or should I open a PR for this bit?

Edit: Not sure how I forgot this: thank you! Tracking that down was turning into a very deep rabbit hole without any apparent satisfying conclusion.

@acowley
Copy link
Contributor Author

acowley commented Aug 13, 2015

Some additional commentary for the record, this is a tragic bit of the GHC API. Opt_DeferTypeErrors should imply Opt_DeferTypedHoles. This might even be important to the type checker, I don't know. Within GHC, there is an API for enforcing these implications (setGeneralFlag'). However it is not exported, so we use gopt_set, and deal with issues like this.

@DanielG
Copy link
Owner

DanielG commented Aug 14, 2015

I suppose we can always ask them to expose that? Then at least the workarounds can be removed in like 6 years? (3 major versions from now xD).

@DanielG
Copy link
Owner

DanielG commented Aug 14, 2015

What do you mean by overlap? Just rebase your stuff on top of serras' I was going to merge that anyways.

@acowley
Copy link
Contributor Author

acowley commented Aug 14, 2015

The simple patch is to replace the definition of deferErrors with @serras 's definition for deferErrorsAndHoles as this is what deferErrors should be doing anyway (if we had access to the right API, our deferErrors would be exactly deferErrorsAndHoles). We also don't need setWarnTypedHoles. I can rebase those simplifications on @serras's patch if you want, or you can do it after merging, or perhaps @serras can add it to his branch.

I talked to Austin a little about fixing this in GHC. He's still on vacation, but when he gets back he can help get these through since it really is a silly mistake in the GHC API.

@DanielG
Copy link
Owner

DanielG commented Aug 14, 2015

Just rebase on top of his branch he doesn't have time to work on this stuff ATM.

@DanielG
Copy link
Owner

DanielG commented Aug 14, 2015

Actually you can also just cherry-pick the commit if you like.

@acowley
Copy link
Contributor Author

acowley commented Aug 14, 2015

Done #539

@acowley acowley closed this as completed Aug 18, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants