#246: Wrong pat-match order for records
----------------------------------------+-----------------------------------
Reporter: simonpj | Owner: simonpj
Type: bug | Status: closed
Priority: low | Milestone: _|_
Component: Compiler | Version: 6.4.1
Severity: minor | Resolution: fixed
Keywords: | Difficulty: Unknown
Testcase: deSugar/should_run/T246 | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
----------------------------------------+-----------------------------------
Changes (by simonpj):
* testcase: => deSugar/should_run/T246
* status: assigned => closed
* resolution: None => fixed
Comment:
Finally fixed!
{{{
Mon Mar 30 09:37:36 BST 2009 [email protected]
* Fix Trac #246: order of matching in record patterns
While I was looking at the desugaring of pattern matching (fixing
Trac #3126) I finally got around to fixing another long-standing bug:
when matching in a record pattern, GHC should match left-to-right in
the programmer-specfied order, *not* left-to-right positionally in
the original record declaration.
Needless to say, that requires a little more code.
See Note [Record patterns] in MatchCon.lhs
}}}
Changing the pattern-match order tickled a bug in GHC itself, so you must
take this patch too
{{{
Mon Mar 30 09:49:12 BST 2009 [email protected]
* Fix an nasty black hole, concerning computation of isRecursiveTyCon
Fixing #246 (pattern-match order in record patterns) made GHC go into
a black hole, by changing the order of patterm matching in
TyCon.isProductTyCon! It turned out that GHC had been avoiding the
black hole only by the narrowest of margins up to now!
The black hole concerned the computation of which type constructors
are recursive, in TcTyDecls.calcRecFlags. We now refrain from using
isProductTyCon there, since it triggers the black hole (very
indirectly). See the "YUK YUK" comment in the body of calcRecFlags.
As it turns out, the fact that TyCon.isProductTyCon matched on the
algTcRec field was quite redundant, so I removed that too. However,
without the fix to calcRecFlags, this wouldn't fix the black hole
because of the use of isRecursiveTyCon in BuildTyCl.mkNewTyConRhs.
Anyway, it's fine now.
}}}
Probably don't merge to 6.10. It's a change in semantics (albeit fixing
wrong semantics). If it broke GHC, it might break someone else's code.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/246#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
