"Non-exhaustive patterns" failure

[slimey]

With hasktags 0.70.1 and the http-types package ver 0.12.1:

$ hasktags http-types-0.12.1/
hasktags: src/Hasktags.hs:418:47-63: Non-exhaustive patterns in lambda

(More specifically, this occurs on both the QueryLike.hs and Version.hs modules in that package.)

[jhenahan]

Well, that's certainly a bug! Thanks for the module references, too! I'll write some testcases and see what the heck is going on.

[lyokha]

The following patch must fix this:

diff --git a/src/Hasktags.hs b/src/Hasktags.hs
index 3456428..d8792c2 100644
--- a/src/Hasktags.hs
+++ b/src/Hasktags.hs
@@ -416,7 +416,9 @@ findFuncTypeDefs found xs@(Token "(" _ :_) scope =
           case break myBreakF xs of
             (inner@(Token _ p : _), rp : xs') ->
               let merged = Token ( concatMap (\(Token x _) -> x) $ inner ++ [rp] ) p
-              in findFuncTypeDefs found (merged : xs') scope
+              in if any (isNewLine Nothing) inner
+                   then []
+                   else findFuncTypeDefs found (merged : xs') scope
             _ -> []
     where myBreakF (Token ")" _) = True
           myBreakF _             = False

The problematic piece was (let's take Network/HTTP/Types/Version.hs for example)

module Network.HTTP.Types.Version
(
  HttpVersion(..)

where the first paren (start of the module's import declarations) and the last paren (end of HttpVersion's constructor list) were erroneously parsed as delimiters for a weird function-operator. As soon as operator names do not expect NewLine tokens, the program failed with non-exhaustive pattern error. The patch checks that operator names do not contain new lines before making decision to regard them as such.

[jhenahan]

Doing some repo restructuring this weekend due to #52, so I'll work on this then. Thanks again for the quick fix, @lyokha.

[jhenahan]

Fixed by #55