[COMMITTED] a68: diagnose stack allocate memory in module preludes

[Jose E. Marchesi]

> Hi Jose.
>
> A question for my understanding:
>   The compiler cannot (at compile-time), decide how much space is needed
>   for publicized identifiers, right?
>   If it could, then you could emit this information in .ga68-exports,
>   and caller could use `alloca' to allocate this memory and pass the
>   pointer to prelude function.

No, thats dynamic memory.

But dynamic doesn't mean it has to be garbage collected.  The memory
allocated in a module prelude could be managed in a per-module heap, and
fred on postlude.

So consider for example:

  module Foo =
  def pub string s := "default";
      skip
  fed

The variable 's' above has a static part (the multiple descriptor) and a
dynamic part, schematically:

   s
  +------------+     +----------+
  | descriptor |-----| elements |
  +------------+     +----------+

Since 's' is a publicized identifier in a module, the descriptor is
allocated statically and lives in some data segment.  The elements
allocated in the prelude, "default", are currently allocated in the
GC-managed heap, but they could be managed by a per-module heap manager
instead, not GCed.  At postlude time, the space for "default" would be
fred.

If we then do:

  access Foo (s := "foo")

Here we are assigning to s the elements in "foo".  So we get:

                     +----------+
                     | "default"|
                     +----------+
   s
  +------------+     +----------+
  | descriptor |-----| "foo"    |
  +------------+     +----------+

Where "foo" is allocated in the GCed heap.  The original "default"
allocated in the module's prelude is no longer reachable.  Currently the
GC wil take care of that as well, but if we had a per-module non-GCed
heap for the module, it would still be in some list and disposed as
postlude time.


>
>
> On Thu, Nov 20, 2025 at 01:08:32PM +0100, Jose E. Marchesi wrote:
>> 
>> The initialization of publicized identifiers in modules happens when
>> the prelude of the module is executed upon invocation.  For example,
>> in the module definition:
>> 
>>   module Foo =
>>   def
>>       pub string foo := "whatever";
>>       pub ref int bar = heap int := 100;
>>       skip
>>   fed
>> 
>> The assignation of "whatever" to foo, and the generator, assignation
>> and ascription to bar, are all executed in the prelude of the module.
>> 
>> Now, in the variable declaration above:
>> 
>>   pub string foo := "whatever"
>> 
>> the implicit sample generator is 'loc'.  This is bad, because it means
>> the dynamic part of the value is stored on the stack... of the prelude
>> function, and that will go out of scope for sure.
>> 
>> A similar situation happens with the identity declaration of bar.
>> Should have we written:
>> 
>>   pub ref int bar = loc int := 100
>> 
>> Then the name generated by `loc int' will be on the prelude function's
>> stack, and will go out of scope as well.
>> 
>> This boils down to the fact that the publicized entities in a
>> top-level module definition are global, and the memory allocated for
>> them should have global scope.
>> 
>> So this patch implements the following rules and checks:
>> 
>> 1. The implicit sample generator used in variable declarations of
>>    publicized modules is _not_ loc, but some generator that provides
>>    names with global scope.  At the moment this is `heap', but we
>>    could at some point introduce another allocator that is not garbage
>>    collected, such as one that releases that memory when the module
>>    postlude is executed.
>> 
>> 2. Specifying a sample generator explicitly whose scope is not global
>>    is a compile-time error.  Thus:
>> 
>>      pub loc string invalid := "foo"
>> 
>>    results in:
>> 
>>      error: publicized variable should not be allocated on the stack
>> 
>> 3. Identity declarations with the form:
>> 
>>      pub ref int fishy = loc int
>> 
>>    are diagnosed with a warning:
>> 
>>      warning: value of 'loc' generator will be out of scope