"Boespflug, Mathieu"
Depends how you look at it I guess. It's arguably a fix to addModFinalizer, which never really worked for the use case it was intended since it was first introduced. This function was added by the author of language-c-inline, who wanted things like
cos :: Double -> Double cos x = [c| cos($x) |]
to work by having a new C wrapper function for the quasiquote be generated and written to disk at the end of the type checking phase. Doing it at the end means all quasiquotes in the whole module can be dumped at once. Problem is, the type environment was not available by then, so the user was forced to provide an explicit type annotation to help with the code generation, as is done in inline-c:
cos :: Double -> Double cos x = [c| double { cos($double:x) } |]
From GHC 7.8, types for locally bound variables weren't even available at the quasiquotation site, for reasons. But it's perfectly safe to make them available by the time all type checking is finished.
We could wait of course, but in the meantime this is completely holding up the "inline" features of inline-java. Because for inline-java we decided that the (redundant) type annotations such as the above were really too verbose in the case of Java, and would require significant hacks to the language-java parser, so we don't support them. That's why I for one am keen to have addModFinalizer make into a release as soon as possible.
But I completely understand your risk aversion for a point release. Here's some data to help you evaluate the risk: the patch is specific to TH finalizers registered using addModFinalizer, a function that is currently used by only one package out there at the moment: expandth (based on github code search - short of being able to code search all of Hackage directly).
Fair enough; this is compelling enough a reason to me. I've gone ahead and merged it. However, would either you or Facundo be able to write a release notes entry? Thanks, - Ben