Many new validate failures, "Synonym in TyConAppCo"-related

[Christiaan Baaij]

I see that the core-lint patch calls:

> -- | Is this a 'TyCon' representing a type synonym (@type@)?
> isSynTyCon :: TyCon -> Bool
> isSynTyCon (SynTyCon {}) = True
> isSynTyCon _             = False

And from simon's comments it seems like he only wanted to check for "normal" type synonyms.
'isSynTyCon' asserts to 'True' for many more tycons though, which include, aside from normal type synonyms:
- type family tycons
- dictionary tycons

Most of the core lint errors seem to be due to the fact that 'TyConAppCo' is applied to a type family tycon.

-- Christiaan

p.s. Regardless, I feel that the documentation for 'isSynTyCon' in misleading as to what it actually asserts.

On May 13, 2014, at 4:16 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:

> Hi,
> 
> I suddenly get
> 
>        Unexpected failures:
>           gadt                          T7294 [exit code non-0] (normal)
>           indexed-types/should_compile  GADT1 [exit code non-0] (normal)
>           indexed-types/should_compile  GADT11 [exit code non-0] (normal)
>           indexed-types/should_compile  GADT3 [exit code non-0] (normal)
>           indexed-types/should_compile  IndTypesPerf [bad exit code] (normal)
>           indexed-types/should_compile  NonLinearLHS [exit code non-0] (normal)
>           indexed-types/should_compile  Numerals [exit code non-0] (normal)
>           indexed-types/should_compile  Roman1 [exit code non-0] (normal)
>           indexed-types/should_compile  Simple9 [exit code non-0] (normal)
>           indexed-types/should_compile  T2219 [exit code non-0] (normal)
>           indexed-types/should_compile  T2627 [exit code non-0] (normal)
>           indexed-types/should_compile  T3484 [exit code non-0] (normal)
>           indexed-types/should_compile  T4935 [exit code non-0] (normal)
>           indexed-types/should_compile  T7585 [exit code non-0] (normal)
>           indexed-types/should_fail     T2664a [exit code non-0] (normal)
>           polykinds                     PolyKinds10 [exit code non-0] (normal)
>           polykinds                     PolyKinds12 [exit code non-0] (normal)
>           polykinds                     T6002 [exit code non-0] (normal)
>           simplCore/should_compile      T5329 [exit code non-0] (normal)
>           simplCore/should_run          T5315 [exit code non-0] (optasm)
>           typecheck/should_compile      T5490 [exit code non-0] (normal)
>           typecheck/should_compile      T7196 [exit code non-0] (normal)
> 
> after these three changes were pushed:
> 
>        Changes to ghc:
>        commit 214ad2d24cda4aaef541df3e213d5c4845f95c71
>        Author: Peter Trommler <ptrommler at scm.org>
>        Date:   Wed Apr 30 11:41:51 2014 +0200
> 
>            Fix globalRegMaybe for unregisterised build.
> 
>            In commit 83a003f globalRegMaybe will be called but panics
>            for unregisterised compilers.
> 
>            In an unregisterised compiler there are no global registers
>            so always return `Nothing`.
> 
>            Fixes #9055.
> 
>        commit 21f17d06aa5c33e639f1b0d37b4bf888b494c441
>        Author: Simon Peyton Jones <simonpj at microsoft.com>
>        Date:   Tue May 13 13:17:19 2014 +0100
> 
>            Fix invariant in mkAppCoFlexible
> 
>            mkAppCoFlexible was breaking the invariant that the head of a TyConAppCo cannot
>            be a type synonym.  This small patch fixes it.
> 
>        commit 4cfc1fae11ec9a5c4b34ac747f0ce50f52423eba
>        Author: Simon Peyton Jones <simonpj at microsoft.com>
>        Date:   Tue May 13 13:15:45 2014 +0100
> 
>            Lint should check that TyConAppCo doesn't have a synonym in the tycon position
> 
>            That is why Lint didn't nail Trac #9102
> 
> Full log at
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/25063931/log.txt. It
> seems that most, if not all, fail with a "Synonym in TyConAppCo" lint
> error.
> 
> 
> If Lint is correct here, then this may indicate further bugs are around.
> But in that case the correct thing would be to have a ticket number for
> that problem and mark all failing test cases as expect_broken – it’s the
> only sensible way of having an always succeeding test suite in master.
> 
> So is the Lint check correct and this uncovered one or more bugs here,
> or is the Lint check actually too restrictive?
> 
> Greetings,
> Joachim
> 
> 
> Greetings,
> Joachim
> 
> 
> 
> -- 
> Joachim “nomeata” Breitner
>  mail at joachim-breitner.de • http://www.joachim-breitner.de/
>  Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>  Debian Developer: nomeata at debian.org
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs