Re: Warning about glomming
On Thu, 7 Apr 2022, Simon Peyton Jones wrote: Gergo might you offer a patch? https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7964 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Re: Shadowing in toIface* output
On Thu, 7 Apr 2022, Simon Peyton Jones wrote: If you can repro this with GHC, can you open a ticket for it. https://gitlab.haskell.org/ghc/ghc/-/issues/21363 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Release Updates - 9.4.1 and 9.2.3
Hi Sebastian, I don't think I understand the severity of #21229, is it an incorrect runtime result? If so, we should definitely fix it before 9.4.1. Thanks for bringing it to my attention. Matt On Wed, Apr 6, 2022 at 1:18 PM Sebastian Graf wrote: > > Hi Matthew, > > Depending on whether https://gitlab.haskell.org/ghc/ghc/-/issues/21229 is > deemed a blocker for 9.4 (I'd say it is, but YMMV), we should include > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7788 in the list. > Perhaps we should make it dependent on whether !7788 is ready to merge by May > or whether it ends up as the only patch that holds back the release. > > Sebastian > > Am Mi., 6. Apr. 2022 um 11:00 Uhr schrieb Matthew Pickering > : >> >> Hi all, >> >> We have now forked the 9.4 branch. >> >> There are a few outstanding patches which have not yet been finished >> but which are essential to the release. >> >> * (#21019) Windows Toolchain Updates - Ben >> * (#20405) Partial Register Stall - Ben/Andreas >> * (!7812) Syntactic Unification - Sam >> >> The target date for the first alpha for 9.4.1 is 1st May. >> >> We have started preparing the 9.2.3 release in order to fix issues >> discovered in the 9.2.2 release. I will post separately to the list >> shortly when the schedule for this release is confirmed. The release >> manager for this release is Zubin. >> >> Cheers, >> >> Matt >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Re: Shadowing in toIface* output
>
> OK, I must be doing something wrong then. I am now looking at Tidy (not
> Prep) output, and I see Core like this:
>
>
>
> showsPrec :: forall a. Show a => Int -> a -> ShowS
>
> [GblId[ClassOp],
>
>Arity=1,
>
>Caf=NoCafRefs,
>
>Str=,
>
>RULES: Built in rule for showsPrec: "Class op showsPrec"]
>
> showsPrec
>
> = \ (@a_a1G3) (v_B1 :: Show a_a1G3) ->
>
> case v_B1 of v_B1 { C:Show v_B2 v_B3 v_B4 -> v_B2 }
>
>
>
> so if I’m reading this right, these vs are still shadowing.
>
That looks very odd. If that gets serialised into a .hi file it won't work
at all.
If you can repro this with GHC, can you open a ticket for it.
It is true (as I discovered when spelunking as a result of this thread)
that Tidy does not tidy the "implicit bindings" See this code in
GHC.Iface.Tidy:
-- See Note [Injecting implicit bindings]
all_tidy_binds = implicit_binds ++ tidy_binds'
I think we must be assuming (without documenting it) that implicit_binds
already satisfies the (undocumented) output invariants of Tidy.
See https://gitlab.haskell.org/ghc/ghc/-/issues/21333, where I suggest
improving this documentation, incl this implicit_binds assumption. Zubin
may be doing this.
I can't account for what you are seeing though.
Simon
On Tue, 5 Apr 2022 at 05:08, Erdi, Gergo wrote:
> PUBLIC
>
>
>
> Ah, it seems Tidy doesn’t traverse the bindings that are created for
> typeclass methods. I guess the idea is that I should be able to recreate
> them from the typeclass declaration? So how do I know 1. which bindings
> exactly should be saved to reconstruct my original full desugared module
> and 2. How do I fill in these missing pieces during reconstruction?
>
>
>
>
>
>
>
> *From:* ghc-devs *On Behalf Of *Erdi,
> Gergo via ghc-devs
> *Sent:* Tuesday, April 5, 2022 11:09 AM
> *To:* Simon Peyton Jones ; Gergo Érdi <
> ge...@erdi.hu>
> *Cc:* GHC Devs
> *Subject:* [External] RE: Re: Shadowing in toIface* output
>
>
>
> OK, I must be doing something wrong then. I am now looking at Tidy (not
> Prep) output, and I see Core like this:
>
>
>
> showsPrec :: forall a. Show a => Int -> a -> ShowS
>
> [GblId[ClassOp],
>
>Arity=1,
>
>Caf=NoCafRefs,
>
>Str=,
>
>RULES: Built in rule for showsPrec: "Class op showsPrec"]
>
> showsPrec
>
> = \ (@a_a1G3) (v_B1 :: Show a_a1G3) ->
>
> case v_B1 of v_B1 { C:Show v_B2 v_B3 v_B4 -> v_B2 }
>
>
>
> so if I’m reading this right, these vs are still shadowing.
>
>
>
> I am using tidyProgram on the output of hscSimplify, and then taking the
> cg_binds of its result. What else should I do to get tidy (heh) Tidy
> output?
>
>
>
>
>
> *From:* ghc-devs *On Behalf Of *Simon
> Peyton Jones
> *Sent:* Monday, April 4, 2022 4:28 PM
> *To:* Gergő Érdi
> *Cc:* GHC Devs
> *Subject:* [External] Re: Shadowing in toIface* output
>
>
>
> So does that mean Tidy produces unique `occNameFS`s, and then `Prep`
> breaks them?
>
>
>
> Tidy does not produce unique OccNames. Rather, it avoids *shadowing*, so
> that if you delete all the uniques and print out the program (which is
> precisely what happens in an .hi file) you'll still get something sensible.
>
>
>
> I'm not sure whether or not Prep maintains this invariant. There is no
> particular reason it should. It might, but it is not (currently) a goal.
>
>
>
> Simon
>
>
>
> On Sat, 2 Apr 2022 at 04:35, Gergő Érdi wrote:
>
> So does that mean Tidy produces unique `occNameFS`s, and then `Prep`
> breaks them?
>
> On Fri, Apr 1, 2022 at 10:35 PM Josh Meredith
> wrote:
> >
> > Hi,
> >
> > I encountered this when we used that for Plutus. I'll have to dig up the
> details, but IIRC `toIfaceExpr` expects GHC to have already tidied the
> output, which deals with this issue of overlapping variable names.
> >
> > Cheers,
> > Josh
> >
> > On Sat, 2 Apr 2022 at 01:26, ÉRDI Gergő wrote:
> >>
> >> Hi,
> >>
> >> I'm trying to save (Prep'd) Core bindings right next to the serialized
> >> `ModIface` (so basically `put_`ing them into the same bytestream, after
> the
> >> `ModIface`), and that's exactly what the functions in `GHC.CoreToIface`
> >> seem to be for, so I expected it to Just Work. However, I noticed that I
> >> very frequently get problems with shadowing. For example, Core that
> looks
> >> like `\v{u1} v{u2} -> v{u1}` would get translated to `\v v -> v`, which
> is
> >> disastrous since these locally bound `Var`s are represented as just
> their
> >> `getOccFS` (i.e. the `FastString` `"v"`).
> >>
> >> But this can't be right: if `toIfaceExpr` would fail this blatently,
> >> then the unfoldings couldn't be saved & restored, which is something GHC
> >> itself does as part of normal `.hi` file handling. So clearly I must be
> >> doing something wrong.
> >>
> >> So I guess my question could be, what could be causing `toIfaceExpr` (a
> >> pure function!) to behave this way for my Cores? But then, if I look at
> >> the implementation of `toIface*`, I can see that it really doesn't do
> >> anything
Re: Git problem
Thanks Viktor -- I'll try that
Simon
On Thu, 7 Apr 2022 at 01:37, Viktor Dukhovni wrote:
> On Wed, Apr 06, 2022 at 10:55:09PM +0100, Simon Peyton Jones wrote:
>
> > I see this
> > bash$ git status
> > On branch wip/romes/ttg-splices-improvements
> > Your branch is up to date with
> 'origin/wip/romes/ttg-splices-improvements'.
> >
> > modified libraries/Cabal
> > +Subproject commit d638e33dbc056048b393964286c7fe394b2730d7-dirty
> > modified libraries/unix
> > +Subproject commit 1f72ccec55c1b61299310b994754782103a617f5-dirty
> >
> > How can I get my submodules in sync with this branch?
>
> ( cd libraries/Cabal && { git clean -xdf .; git checkout .; } )
> ( cd libraries/unix && { git clean -xdf .; git checkout .; } )
>
> --
> Viktor.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Warning about glomming
It's a warning directed solely at compiler authors (hence -DDEBUG). If a lot of glomming is happening, it might be due to some scoping or dependency analysis bug -- e.g. perhaps OccAnal isn't putting bindings in proper dependency order, or perhaps some plugin is gratuitously scrambling the order of the top level definitions. Or it might be legitimate, as in your case. Perhaps adding a Note with the code that generates the warning (or wherever you looked -- where was that?) would be better. I always like to look for ways to reply not just to Gergo but to all the future Gergos who stumble over this. Gergo might you offer a patch? Simon On Thu, 7 Apr 2022 at 07:47, Gergő Érdi wrote: > Using -DDEBUG, I see a warning about glomming from OccurAnal. Having > read the relevant Note, the situation is exactly what's described > here: since I'm using cross-module specializations, the specializer > will generate rewrite rules that replace external references with > local forward references. > > But the one thing the Note doesn't explicitly state is why this is > reported as a warning. It sounds like OccurAnal is well equipped to > fix this problem. So is glomming a sign of a problem or is it not? If > I see that warning, does that point to a problem in how I use the GHC > API, a problem in the code that I'm trying to compile, or neither? > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Warning about glomming
Using -DDEBUG, I see a warning about glomming from OccurAnal. Having read the relevant Note, the situation is exactly what's described here: since I'm using cross-module specializations, the specializer will generate rewrite rules that replace external references with local forward references. But the one thing the Note doesn't explicitly state is why this is reported as a warning. It sounds like OccurAnal is well equipped to fix this problem. So is glomming a sign of a problem or is it not? If I see that warning, does that point to a problem in how I use the GHC API, a problem in the code that I'm trying to compile, or neither? ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
