Re: Preelaboration

["Randy Brukardt" <randy@rrsoftware.com>]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lymvnqnf3h.fsf@pushface.org...
>I (think I) need to eliminate elaboration calls in parts of my Cortex
> GNAT Runtime Systems project[1], and I'm left with one that I can't
> understand.
>
> (1) what does pragma Preelaborate actually mean? I hoped it would mean
> "you don't need to elaborate this package".

What it says in 10.2.1, no more and no less. There is no required effect on 
code generation (unless Annex C is supported, and even then it is limited).

> (2) If you give Preelaborate, is it a compiler error to generate
> elaboration code? (the generated elaboration procedure does nothing).

No, the only errors are those defined by 10.2.1.

C.4 says that a subset of preelaborable packages should not generate any 
code. Which only applies if Annex C is implemented, and in any case is not a 
testable requirement (the ACATS cannot require code inspection, which is the 
only way to determine if C.4 is followed).

C.4(12) supposedly requires documentation of cases where code is generated, 
but that sort of requirement is widely ignored. (And would be useless, I'd 
just write something like "Elaboration of a preelaborable package may 
execute code in all cases other than those required by C.4 to not execute 
any code." It's way too hard for an implementer to figure out what will and 
will not do something.

(And this whole set of requirements is silly anyway. What implementer 
executes code if they don't have to?? So anything that can be done without 
code is done that way, and everything else executes some code, regardless of 
any categorization pragma.)

> (3) I find ARM 10.2.1(10)[2] unclear (I got here because the problematic
> package body instantiates a generic). Does it mean that the
> instantiation won't be preelaborable unless all of 10.1 .. 10.4 are
> false? Or does it mean that the compiler will make these assumptions
> regardless of actuals?

This means that the generic body would be illegal if preelaborated, unless 
it means the preelaboration requirements using those assumptions. The 
instance can't be preelaborable unless the body is.

> And, looking at (10.1), would you expect
>
>   generic
>      type Item is private with Preelaborable_Initialization;
>   package Generic_Queues is
>
> to be legal? GNAT rejects it, 'aspect "Preelaborable_Initialization" not
> allowed for formal type declaration'.

Preelaborable_Initialization is not an aspect, as it is not the same for all 
views of a type. We tried to come up with a model to make it an aspect and 
failed to come up with something that makes sense.

In addition, formal types aren't allowed to have language-defined aspects, 
as that would add implicit contracts to the specification (and notably, 
would need rules for those contracts). pragma P_I isn't allowed in a formal 
part, either.

To get a formal type that has P_I, you'd need to use a generic derived type 
where the ancestor has P_I. Probably not what you want.

I would guess in this case that the instance in a preelaborable package 
should make the package illegal; the generic would need to be Preelaborable, 
but then it most likely would be illegal.

But this area is complicated (I might be getting it all wrong) and it 
probably doesn't do what you want anyway (Pure/Preelaborable categorizations 
in general were a failure, as they can't be applied to the majority of 
packages). I don't really have any advice, other than if you really care, 
look up the old AIs on the topic.

                           Randy.