Alternative to isTypeLevPoly

[Csaba Hruska]

As I see there is no bug at all. I just did not read the description
comment for `LitRubbish`. I have misunderstood the meaning of the `Type`
argument. According to the comment it is more like `RuntimeRepType` or even
`FRRType`.
https://github.com/ghc/ghc/blob/master/compiler/GHC/Types/Literal.hs#L134-L142
https://github.com/ghc/ghc/blob/master/compiler/GHC/Core/TyCo/Rep.hs#L116-L121

> LitRubbish Type -- ^ A nonsense value of the given
> -- representation. See Note [Rubbish literals].
> --
> -- The Type argument, rr, is of kind RuntimeRep.
> -- The type of the literal is forall (a:TYPE rr). a
>

Regards,
Csaba

On Thu, Sep 15, 2022 at 10:14 PM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> The type argument to LitRubbish should be a fixed RuntimeRep. If it is
>> not, you can file a bug
>>
>
> Yes!  Please file a bug if you find this.
>
> On Thu, 15 Sept 2022 at 16:36, Krzysztof Gogolewski <
> krz.gogolewski at gmail.com> wrote:
>
>> The type argument to LitRubbish should be a fixed RuntimeRep. If it is
>> not, you can file a bug. I have fixed a related bug in f435d55fe969e7.
>>
>> Krzysztof
>>
>> On Thu, Sep 15, 2022 at 1:12 PM Csaba Hruska <csaba.hruska at gmail.com>
>> wrote:
>> >
>> > I've investigated a bit more. You are right `typeHasFixedRuntimeRep`
>> works fine, the panic was caused by querying the representation type of
>> `LitRubbish` type argument. In some cases `getRuntimeRep` causes GHC panic
>> for `LitRubbish` type arguments.
>> > I did solve the issue with special casing the LitRubbish type argument
>> handling by using only the `runtimeRepPrimRep` function. In the general
>> case I tested the type with `isUnboxedTupleType` and `isUnboxedSumType`
>> which rely on `getRuntimeRep`.
>> > Thanks for the tips and feedback.
>> > Regards,
>> > Csaba
>> >
>> > On Wed, Sep 14, 2022 at 6:44 PM Sam Derbyshire <
>> sam.derbyshire at gmail.com> wrote:
>> >>
>> >> Hmm, that's strange, both isTypeLevPoly and typeHasFixedRuntimeRep
>> have the same precondition: the kind of the type is of the form TYPE rep.
>> So they should panic in the same circumstances. Can you give a bit more
>> information? What panics are you running into?
>> >>
>> >> On Wed, 14 Sept 2022 at 18:40, Csaba Hruska <csaba.hruska at gmail.com>
>> wrote:
>> >>>
>> >>> Hi,
>> >>> Thanks for the tip, I've tried it and it behaves differently than
>> isTypeLevPoly. I can get panic when querying the reptype for fixed
>> reptypes. That means isTypeLevPoly semantically is not the same as the
>> negated result of typeHasFixedRuntimeRep.
>> >>>
>> >>> On Wed, 14 Sep 2022, 18:19 Sam Derbyshire, <sam.derbyshire at gmail.com>
>> wrote:
>> >>>>
>> >>>> Hi Csaba,
>> >>>>
>> >>>> I think you want the function typeHasFixedRuntimeRep from
>> GHC.Core.Type.
>> >>>>
>> >>>> Best,
>> >>>>
>> >>>> Sam
>> >>>>
>> >>>> On Wed, 14 Sept 2022 at 18:12, Csaba Hruska <csaba.hruska at gmail.com>
>> wrote:
>> >>>>>
>> >>>>> Hello GHC Devs,
>> >>>>>
>> >>>>> I've noticed that the `isTypeLevPoly` function has been removed
>> from GHC since 9.4.
>> >>>>> I used it to decide the validity of querying the representation
>> type of every value in the STG IR.
>> >>>>> It was mandatory to prevent GHC panics, because there are a lot of
>> partial functions in GHC.
>> >>>>> Is there an alternative to `isTypeLevPoly` in GHC 9.4?
>> >>>>>
>> >>>>> Best regards,
>> >>>>> Csaba Hruska
>> >>>>> _______________________________________________
>> >>>>> ghc-devs mailing list
>> >>>>> ghc-devs at haskell.org
>> >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220916/d0be3eee/attachment.html>