Next we traverse the bindings top to bottom. For each top-level binder

1. Make it into a GlobalId; its IdDetails becomes VanillaGlobal, reflecting the fact that from now on we regard it as a global, not local, Id

2. Give it a system-wide Unique. [Even non-exported things need system-wide Uniques because the byte-code generator builds a single Name->BCO symbol table.]

   We use the NameCache kept in the HscEnv as the source of such system-wide uniques.

   For external Ids, use the original-name cache in the NameCache to ensure that the unique assigned is the same as the Id had in any previous compilation run.

3. Rename top-level Ids according to the names we chose in step 1. If it's an external Id, make it have a External Name, otherwise make it have an Internal Name. This is used by the code generator to decide whether to make the label externally visible

4. Give it its UTTERLY FINAL IdInfo; in ptic, * its unfolding, if it should have one * its arity, computed from the number of visible lambdas

Finally, substitute these new top-level binders consistently throughout, including in unfoldings. We also tidy binders in RHSs, so that they print nicely in interfaces.

We compute hasCafRefs here, because IdInfo is supposed to be finalised after TidyPgm. But CorePrep does some transformations that affect CAF-hood. So we have to predict the result here, which is revolting.

In particular CorePrep expands Integer and Natural literals. So in the prediction code here we resort to applying the same expansion (cvt_literal). There are also numerous other ways in which we can introduce inconsistencies between CorePrep and TidyPgm. See Note [CAFfyness inconsistencies due to eta expansion in TidyPgm] for one such example.

Ugh! What ugliness we hath wrought.

What happens when we try to float bindings to the top level? At this point all the CafInfo is supposed to be correct, and we must make certain that is true of the new top-level bindings. There are two cases to consider

a) The top-level binding is marked asCafRefs. In that case we are basically fine. The floated bindings had better all be lazy lets, so they can float to top level, but they'll all have HasCafRefs (the default) which is safe.

b) The top-level binding is marked NoCafRefs. This really happens Example. CoreTidy produces

  $fApplicativeSTM [NoCafRefs] = D:Alternative retry# ...blah...

Now CorePrep has to eta-expand to

  $fApplicativeSTM = let sat = \xy. retry x y
                     in D:Alternative sat ...blah...

So what we want is

  sat [NoCafRefs] = \xy. retry x y
  $fApplicativeSTM [NoCafRefs] = D:Alternative sat ...blah...

So, gruesomely, we must set the NoCafRefs flag on the sat bindings, and substitute the modified 'sat' into the old RHS.

It should be the case that 'sat' is itself [NoCafRefs] (a value, no cafs) else the original top-level binding would not itself have been marked [NoCafRefs]. The DEBUG check in CoreToStg for consistentCafInfo will find this.

This is all very gruesome and horrible. It would be better to figure out CafInfo later, after CorePrep. We'll do that in due course. Meanwhile this horrible hack works.

Eta expansion during CorePrep can have non-obvious negative consequences on the CAFfyness computation done by TidyPgm (see Note [Disgusting computation of CafRefs] in TidyPgm). This late expansion happens/happened for a few reasons:

• CorePrep previously eta expanded unsaturated primop applications, as described in Note [Primop wrappers]).

• CorePrep still does eta expand unsaturated data constructor applications.

In particular, consider the program:

data Ty = Ty (RealWorld# -> (# RealWorld#, Int #))

-- Is this CAFfy?
x :: STM Int
x = Ty (retry# @Int)

Consider whether x is CAFfy. One might be tempted to answer "no". Afterall, f obviously has no CAF references and the application (retry# @Int) is essentially just a variable reference at runtime.

However, when CorePrep expanded the unsaturated application of 'retry#' it would rewrite this to

x = \u []
   let sat = retry# @Int
   in Ty sat

This is now a CAF. Failing to handle this properly was the cause of #16846 (closed). We fixed this by eliminating the need to eta expand primops, as described in Note [Primop wrappers]), However we have not yet done the same for data constructor applications.