[commit: ghc] master: Explain linter optimization for StaticPtr checks. (94f2ee1)

[git at git.haskell.org]

Repository : ssh://git@git.haskell.org/ghc

On branch  : master
Link       : http://ghc.haskell.org/trac/ghc/changeset/94f2ee1e03d5a4baf29d2893b0efd2bd155b0bc2/ghc

>---------------------------------------------------------------

commit 94f2ee1e03d5a4baf29d2893b0efd2bd155b0bc2
Author: Facundo Domínguez <facundo.dominguez at tweag.io>
Date:   Thu May 5 21:32:49 2016 -0300

    Explain linter optimization for StaticPtr checks.


>---------------------------------------------------------------

94f2ee1e03d5a4baf29d2893b0efd2bd155b0bc2
 compiler/coreSyn/CoreLint.hs | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/compiler/coreSyn/CoreLint.hs b/compiler/coreSyn/CoreLint.hs
index 5ce4cee..b3cec5f 100644
--- a/compiler/coreSyn/CoreLint.hs
+++ b/compiler/coreSyn/CoreLint.hs
@@ -1641,6 +1641,14 @@ Every occurrence of the data constructor @StaticPtr@ should be moved to the top
 level by the FloatOut pass. The linter is checking that no occurrence is left
 nested within an expression.
 
+The check is enabled only if the module uses the StaticPointers language
+extension. This optimization arose from the need to compile "GHC.StaticPtr",
+which otherwise would be rejected because the following binding
+
+    StaticPtr = \a b1 b2 b3 b4 -> StaticPtr a b1 b2 b3 b4
+
+contains an application of `StaticPtr` nested within the lambda abstractions.
+
 Note [Type substitution]
 ~~~~~~~~~~~~~~~~~~~~~~~~
 Why do we need a type substitution?  Consider