AI22-0137-1/04

AI22-0137-1

!standard 3.10.1(8.1/3) 25-08-15 AI22-0137-1/04

!standard 3.10.1(8.4/3)

!class Binding Interpretation 25-06-30

!status Revision-202Y 25-07-30

!status WG9 Approved 25-10-08

!status ARG Approved 15-0-1 25-07-30

!status work item 25-06-30

!status received 25-06-30

!assigned author Stephen Baird

!submitter Stephen Baird

!priority Low

!difficulty Easy

!qualifier Omission

!subject Renaming-as-body with a parameter of an incomplete type

!summary

A renaming-as-body is illegal if the subprogram has an untagged incomplete parameter or any incomplete result type.

!problem

We do not require implementations to use a wrapper model for implementing renamings-as-body, but we do want to allow that option. Allowing cases where that approach does not work introduces problems for implementations that choose that implementation strategy.

Therefore, a renaming-as-body should be illegal if an equivalent explicit wrapper subprogram would violate the rule about uses of incomplete parameter types in the profile of a subprogram when the subprogram is called. Specifically, RM 3.10.1(10/3): “An actual parameter in a call shall not be of an untagged incomplete view".

For a specific example, suppose we have:

A package P1 that declares a visible untagged type T.
Package specs P2 and P3, each having a limited with of P1 and each having a visible declaration of a procedure Proc which takes a parameter of the incomplete type P1.T.
The body of P2 withs (only) P3; it does not with P1. Then P2.Proc is completed via a renaming-as-body, renaming P3.Proc.

[This is shown as code in the Example section below, that might be easier to understand.]

Should that renaming-as-body be legal? (No.)

!recommendation

In effect, apply the existing 3.10.1(10/3) rule about explicit calls to the implicit call associated with an implicitly-declared wrapper subprogram. This effect is achieved by modifying the rules about how an incomplete view of a type can be used.

!wording

Modify 3.10.1(8.1/3):

as the subtype_mark defining the subtype of a parameter or result in a profile occurring within a basic_declaration{ other than a renaming-as-body (see 8.5.4)};

Modify 3.10.1(8.4/3):

as the subtype_mark defining the subtype of a parameter in the profile for a subprogram_body, entry_body, [or ]accept_statement{, or renaming-as-body};

!discussion

At least one production Ada compiler has run into the problem described in this AI.

Note that this problem does not occur for parameters of tagged incomplete types. A call passing an object of such a type is legal (as the details of parameter passing are known for such types). This is not true for results of a tagged incomplete type.

!example

package P1 is

type T is ...; -- untagged

end P1;

---

limited with P1;

package P2 is

procedure Proc (Arg : P1.T);

end P2;

---

limited with P1;

package P3 is

procedure Proc (Arg : P1.T);

end P3;

---

with P3;

package body P2 is

procedure Proc (Arg : P1.T) renames P3.Proc; -- Legal? (No.)

end P2;

!corrigendum 3.10.1(8.1/3)

@drepl

@xbullet{as the @fa{subtype_mark} defining the subtype of a parameter or result in a profile occurring within a @fa{basic_declaration}; }

@dby

@xbullet{as the @fa{subtype_mark} defining the subtype of a parameter or result in a profile occurring within a @fa{basic_declaration} other than a renaming-as-body (see @ref{8.5.4}); }

!corrigendum 3.10.1(8.4/3)

@drepl

@xbullet{as the @fa{subtype_mark} defining the subtype of a parameter in the profile for a @fa{subprogram_body}, @fa{entry_body}, or @fa{accept_statement};}