Refactoring for error: cannot inline "X" (forward instance within enclosing body)

Refactoring for error: cannot inline "X" (forward instance within enclosing body)

[Keean Schupke]

Hi,


I am forcing the inlining of some procedures using:

pragma Inline_Always(X);

and I am getting the error:

cannot inline "X" (forward instance within enclosing body)

Can someone explain what a forward instance is and what the enclosing body (IE the scope of the error is).


Regards,
Keean.

Re: Refactoring for error: cannot inline "X" (forward instance within enclosing body)

[Keean Schupke]

On Monday, 25 June 2012 14:02:21 UTC+1, Keean Schupke  wrote:
> Hi,
> 
> 
> I am forcing the inlining of some procedures using:
> 
> pragma Inline_Always(X);
> 
> and I am getting the error:
> 
> cannot inline "X" (forward instance within enclosing body)
> 
> Can someone explain what a forward instance is and what the enclosing body (IE the scope of the error is).
> 
> 
> Regards,
> Keean.

Sorry, double posted this.

Re: Refactoring for error: cannot inline "X" (forward instance within enclosing body)

[Brian Drummond]

On Mon, 25 Jun 2012 06:02:21 -0700, Keean Schupke wrote:

> Hi,
> 
> 
> I am forcing the inlining of some procedures using:
> 
> pragma Inline_Always(X);
> 
> and I am getting the error:
> 
> cannot inline "X" (forward instance within enclosing body)
> 
> Can someone explain what a forward instance is and what the enclosing
> body (IE the scope of the error is).

Try posting a minimal compilable example that allows others to reproduce 
the problem.

- Brian

Re: Refactoring for error: cannot inline "X" (forward instance within enclosing body)

[Keean Schupke]

On Monday, 25 June 2012 20:47:21 UTC+1, Brian Drummond  wrote:
> On Mon, 25 Jun 2012 06:02:21 -0700, Keean Schupke wrote:
> 
> > Hi,
> > 
> > 
> > I am forcing the inlining of some procedures using:
> > 
> > pragma Inline_Always(X);
> > 
> > and I am getting the error:
> > 
> > cannot inline "X" (forward instance within enclosing body)
> > 
> > Can someone explain what a forward instance is and what the enclosing
> > body (IE the scope of the error is).
> 
> Try posting a minimal compilable example that allows others to reproduce 
> the problem.
> 
> - Brian

Here's the minimal test example (as minimal as I can make it so far...):



procedure Test is
    generic
        type A is private;
        with function F(Node : in A) return A is <>;
    package Test_Signature is end;

    generic
    package Test_Implementation is
        type A is record null;
        end record;
        function F(X : in A) return A;
        pragma Inline_Always(F);
    end Test_Implementation;

    package body Test_Implementation is
        function F(
            X : in A
        ) return A is begin
            return X;
        end F;
    end Test_Implementation;

    package Test_Use is
        package T is new Test_Implementation;

        use T;
        package U is new Test_Signature(A => T.A);
    end Test_Use;

begin
    null;
end Test;



Cheers,
Keean.

Re: Refactoring for error: cannot inline "X" (forward instance within enclosing body)

[Georg Bauhaus]

On 26.06.12 09:51, Keean Schupke wrote:

> Here's the minimal test example (as minimal as I can make it so far...):

-gnatN makes this work.

Re: Refactoring for error: cannot inline "X" (forward instance within enclosing body)

[Brian Drummond]

On Tue, 26 Jun 2012 00:51:59 -0700, Keean Schupke wrote:

> On Monday, 25 June 2012 20:47:21 UTC+1, Brian Drummond  wrote:
>> On Mon, 25 Jun 2012 06:02:21 -0700, Keean Schupke wrote:
>> 
>> > Hi,
>> > 
>> > 
>> > I am forcing the inlining of some procedures using:
>> > pragma Inline_Always(X);
>> > and I am getting the error:
>> > cannot inline "X" (forward instance within enclosing body)

> Here's the minimal test example (as minimal as I can make it so far...):

This reveals that "some procedures" are (a) generic, and (b) declared in 
a package, and implemented in its body. Neither of these points was clear 
originally.

Now the package is visible while compiling the outer level, but the 
package body is hidden, so it seems reasonable that the implementation of 
the procedure (to be inlined) is not visible. Presumably the "forward 
instance" is an empty space where the implementation has not yet been 
filled in.

Georg points out a workaround : -gnatN performs inline expansion in the 
Gnat front end, which CAN see the package body while compiling the outer 
module. It is not clear to me : is that allowed by the LRM, or is Gnat 
being a little naughty here?

Or has this little example caught a corner case involving generics and 
Inline_Always where Gnat gets it wrong?

- Brian

Re: Refactoring for error: cannot inline "X" (forward instance within enclosing body)

[Keean Schupke]

On Tuesday, 26 June 2012 10:49:23 UTC+1, Georg Bauhaus  wrote:
> On 26.06.12 09:51, Keean Schupke wrote:
> 
> > Here's the minimal test example (as minimal as I can make it so far...):
> 
> -gnatN makes this work.


Ah, -gnatN does not fix my project, so I need to produce an updated example.

Cheers,
Keean.

Re: Refactoring for error: cannot inline "X" (forward instance within enclosing body)

[Keean Schupke]

On Tuesday, 26 June 2012 12:53:35 UTC+1, Keean Schupke  wrote:
> On Tuesday, 26 June 2012 10:49:23 UTC+1, Georg Bauhaus  wrote:
> > On 26.06.12 09:51, Keean Schupke wrote:
> > 
> > > Here's the minimal test example (as minimal as I can make it so far...):
> > 
> > -gnatN makes this work.
> 
> 
> Ah, -gnatN does not fix my project, so I need to produce an updated example.
> 
> Cheers,
> Keean.

This example is simplified a bit more and still causes the problem with -gnatN.



procedure Test is
    generic
    package A is end;

    generic
    package B is
        procedure F;
        pragma Inline_Always(F);
    end B;

    package body B is
        procedure F
        is begin null;
        end F;
    end B;

    package C is
        package My_A is new A;
        package My_B is new B;
    end C;
begin
    null;
end Test;



The following compiles fine:



procedure Test is
    generic
    package A is end;

    generic
    package B is
        procedure F;
        pragma Inline_Always(F);
    end B;

    package body B is
        procedure F
        is begin null;
        end F;
    end B;

    package My_A is new A;
    package My_B is new B;
begin
    null;
end Test;


Cheers,
Keean.

Re: Refactoring for error: cannot inline "X" (forward instance within enclosing body)

[Keean Schupke]

On Tuesday, 26 June 2012 16:42:09 UTC+1, Keean Schupke  wrote:
> On Tuesday, 26 June 2012 12:53:35 UTC+1, Keean Schupke  wrote:
> > On Tuesday, 26 June 2012 10:49:23 UTC+1, Georg Bauhaus  wrote:
> > > On 26.06.12 09:51, Keean Schupke wrote:
> > > 
> > > > Here's the minimal test example (as minimal as I can make it so far...):
> > > 
> > > -gnatN makes this work.
> > 
> > 
> > Ah, -gnatN does not fix my project, so I need to produce an updated example.
> > 
> > Cheers,
> > Keean.
> 
> This example is simplified a bit more and still causes the problem with -gnatN.
> 
> 
> 
> procedure Test is
>     generic
>     package A is end;
> 
>     generic
>     package B is
>         procedure F;
>         pragma Inline_Always(F);
>     end B;
> 
>     package body B is
>         procedure F
>         is begin null;
>         end F;
>     end B;
> 
>     package C is
>         package My_A is new A;
>         package My_B is new B;
>     end C;
> begin
>     null;
> end Test;
> 
> 
> 
> The following compiles fine:
> 
> 
> 
> procedure Test is
>     generic
>     package A is end;
> 
>     generic
>     package B is
>         procedure F;
>         pragma Inline_Always(F);
>     end B;
> 
>     package body B is
>         procedure F
>         is begin null;
>         end F;
>     end B;
> 
>     package My_A is new A;
>     package My_B is new B;
> begin
>     null;
> end Test;
> 
> 
> Cheers,
> Keean.


So the question is why does this compile without the "C" package? Can anyone explain to my why the compiler cannot inline when package "C" is there?


Cheers,
Keean.

Re: Refactoring for error: cannot inline "X" (forward instance within enclosing body)

[Randy Brukardt]

"Brian Drummond" <brian@shapes.demon.co.uk> wrote in message 
news:jsc3pr$iap$1@dont-email.me...
...
> Georg points out a workaround : -gnatN performs inline expansion in the
> Gnat front end, which CAN see the package body while compiling the outer
> module. It is not clear to me : is that allowed by the LRM, or is Gnat
> being a little naughty here?

Inline_Always is a GNAT invention, so it can do what it wants. And it is 
always OK for an Ada compiler to inline (whether or not a pragma or aspect 
or command line option is given.)

                                Randy.

Re: Refactoring for error: cannot inline "X" (forward instance within enclosing body)

[Keean Schupke]

On Tuesday, 26 June 2012 23:43:24 UTC+1, Randy Brukardt  wrote:
> "Brian Drummond" 
>  wrote in message 
> ...
> > Georg points out a workaround : -gnatN performs inline expansion in the
> > Gnat front end, which CAN see the package body while compiling the outer
> > module. It is not clear to me : is that allowed by the LRM, or is Gnat
> > being a little naughty here?
> 
> Inline_Always is a GNAT invention, so it can do what it wants. And it is 
> always OK for an Ada compiler to inline (whether or not a pragma or aspect 
> or command line option is given.)
> 
>                                 Randy.


Is this something that should be considered a limitation, or bug in GNAT?


Cheers,
Keean.

Re: Refactoring for error: cannot inline "X" (forward instance within enclosing body)

[Simon Wright]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> Or has this little example caught a corner case involving generics and
> Inline_Always where Gnat gets it wrong?

Looking at AARM05 6.3.2 (6) [1], an implementation doesn't have to obey
pragma Inline.

I don't know how AdaCore regard Inline_Always with respect to this; but
it seems unlikely that saying -gnatN could suddenly make it
possible. Unless -gnatN overrides the Inline_Always processing that
reports problems.

Either way, seems like a GNAT bug.

[1]http://www.adaic.org/resources/add_content/standards/05aarm/html/AA-6-3-2.html