Renaming subprogram and default_expression

Renaming subprogram and default_expression

[Florian Weimer]

Is anything wrong with the following program?  Maybe I'm just
confused, but it looks perfectly legal to me.

procedure Defaults is

   type Typ is new Integer;

   procedure Original (X : Typ);
   procedure Renamed (X : Typ := -1);
   
   procedure Renamed (X : Typ := -1)
     renames Original;
   
   procedure Original (X : Typ) is
   begin
      null;
   end Original;

begin
   null;
end Defaults;

Re: Renaming subprogram and default_expression

[sk]

Hi, 

Compiles, links and runs on Linux (Mandrake 
7.1 - Kernel 2.2.19) using Gnat 3.13p with 
no problems in any of the above mentioned 3 
steps.

I even added put_lines and calls to both 
"Original" and "Renamed" so that things 
wouldn't get optimized away.


-------------------------------------
-- Vertically merge for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: Renaming subprogram and default_expression

[Christoph Grein]

> From: Florian Weimer <fw@deneb.enyo.de>
> 
> Is anything wrong with the following program?  Maybe I'm just
> confused, but it looks perfectly legal to me.
> 
> procedure Defaults is
> 
>    type Typ is new Integer;
> 
>    procedure Original (X : Typ);        <--- declaration
>    procedure Renamed (X : Typ := -1);   <--- declaration
>    
>    procedure Renamed (X : Typ := -1)    <--- renaming as body
>      renames Original;
>    
>    procedure Original (X : Typ) is      <--- proper body
>    begin
>       null;
>    end Original;
> 
> begin
>    null;
> end Defaults;

So it looks OK. Did some compiler complain?

Re: Renaming subprogram and default_expression

[Florian Weimer]

Christoph Grein <christoph.grein@eurocopter.com> writes:

> So it looks OK. Did some compiler complain?

GNAT 3.14p and GNAT 5.00w, both with the same, confusing error
message: 'default expression for "X" does not match'.

Re: Renaming subprogram and default_expression

[Lutz Donnerhacke]

* Florian Weimer wrote:
>Christoph Grein <christoph.grein@eurocopter.com> writes:
>> So it looks OK. Did some compiler complain?
>
>GNAT 3.14p and GNAT 5.00w, both with the same, confusing error
>message: 'default expression for "X" does not match'.

Initial program to reproduce this error in 3.13p. May it help you.

procedure Defaults is
   type Typ is new Integer;

   procedure Original (X : Typ);
   procedure Renamed (X : Typ := -2);
   procedure Renamed (X : Typ := -3) renames Original;

   procedure Original (X : Typ) is
   begin
      null;
   end Original;

begin
   null;
end Defaults;

Re: Renaming subprogram and default_expression

[Florian Weimer]

lutz@iks-jena.de (Lutz Donnerhacke) writes:

> * Florian Weimer wrote:
>>Christoph Grein <christoph.grein@eurocopter.com> writes:
>>> So it looks OK. Did some compiler complain?
>>
>>GNAT 3.14p and GNAT 5.00w, both with the same, confusing error
>>message: 'default expression for "X" does not match'.
>
> Initial program to reproduce this error in 3.13p. May it help you.
>
> procedure Defaults is
>    type Typ is new Integer;
>
>    procedure Original (X : Typ);
>    procedure Renamed (X : Typ := -2);
>    procedure Renamed (X : Typ := -3) renames Original;

This is illegal because full conformance of the
subprogram_specification to a preceding declaration is required, see
RM 8.5.4(5).  The error message is correct in this case.

Re: Renaming subprogram and default_expression

[Alexander Boucke]

Florian Weimer wrote in message <87sn84i80s.fsf@deneb.enyo.de>...
>Christoph Grein <christoph.grein@eurocopter.com> writes:
>
>> So it looks OK. Did some compiler complain?
>
>GNAT 3.14p and GNAT 5.00w, both with the same, confusing error
>message: 'default expression for "X" does not match'.

I had the same Error message trying to compile the strings_edit package from
D. Kazakov (could be found on AdaPower.com). The package compiled well with
gnat3.13p and there seems to be no error (spec and body have the same
default expressions). As in this example, there is a rename envolved and a
default-expression for a selfdefined type. There are no problems with
default expressions for booleans. Should this be an error of gnat-3.14p?
That's why I stayed with gnat-3.13p so far.

Regrards,

Alexander

P.S.: When trying to compile my program with -gnatN, the 3.14.p-compiler is
erroneous. Has anybody else noticed this?

Re: Renaming subprogram and default_expression

[Florian Weimer]

"Alexander Boucke" <alexb@lufmech.rwth-aachen.de> writes:

> Should this be an error of gnat-3.14p?

I think so.  I'm currently tracking it down.  It appears that the
generated body for the renaming declaration is checked for full
conformance to the specification of the renamed subprogram, which is
wrong.

The check on the generated body is unnecessary, and there is logic to
prevent it, but this logic fails to detect the situation because the
corresponding declaration at this point is already that of the renamed
subprogram, and not the renaming declaration.

Re: Renaming subprogram and default_expression

[Alexander Boucke]

Florian Weimer wrote in message <87zo2cgkib.fsf@deneb.enyo.de>...
>I think so.  I'm currently tracking it down.  It appears that the
>generated body for the renaming declaration is checked for full
>conformance to the specification of the renamed subprogram, which is
>wrong.


This does not seem to be the case for strings edit:

package body Strings_Edit

......
   package Roman_Edit is
      procedure Get
                (  Source  : in String;
                   Pointer : in out Integer;
                   Value   : out Roman;
                   First   : in Roman := Roman'First;
                   Last    : in Roman := Roman'Last;
                   ToFirst : in Boolean := False;
                   ToLast  : in Boolean := False
                );
..............
   end Roman_Edit;
   package body Roman_Edit is separate;

   procedure Get
             (  Source  : in String;
                Pointer : in out Integer;
                Value   : out Roman;
                First   : in Roman := Roman'First;
                               -- ^^ comment this
                Last    : in Roman := Roman'Last;
                                -- ^^ comment this
                ToFirst : in Boolean := False;
                ToLast  : in Boolean := False
             )  renames Roman_Edit.Get;
...............
end Strings_Edit;

Type roman is range 1..3999; is defined in strings edit.ads
Note, that gnat3.14p does not complain about the preset values for the
booelan arguments, only for the new integer type. If I comment these default
values, the program compiles. This seems to be the same error as in the
short testprog. starting this thread: A new integer-type was used there,
too.
I assume now, that the selfdefined type makes the problem here.

Regards,
Alexander

Re: Renaming subprogram and default_expression

[Florian Weimer]

"Alexander Boucke" <alexb@lufmech.rwth-aachen.de> writes:

> Type roman is range 1..3999; is defined in strings edit.ads Note,
> that gnat3.14p does not complain about the preset values for the
> booelan arguments, only for the new integer type. If I comment these
> default values, the program compiles. This seems to be the same
> error as in the short testprog. starting this thread: A new
> integer-type was used there, too.

You can eliminate the integer type.  The minimal test case for GCC 3.1
is:

procedure Defaults is

   procedure Original (X : Integer);
   procedure Renamed (X : Integer := -1);

   procedure Renamed (X : Integer := -1)
     renames Original;

   procedure Original (X : Integer) is
   begin
      null;
   end Original;

begin
   null;
end Defaults;

(I wouldn't have thought that such basic things are broken, that's why
I had not tried the default Integer type.)

I don't know why the bug doesn't occur with string types.  Oh well.

Re: Renaming subprogram and default_expression

[Alexander Boucke]

Right, even if I change the code as indicated, 3.14p does not compile...
>
>You can eliminate the integer type.  The minimal test case for GCC 3.1
>is:
>
>procedure Defaults is
>
>   procedure Original (X : Integer := -1);
                                    ^^^^
>   procedure Renamed (X : Integer := -1);
>
>   procedure Renamed (X : Integer := -1)
>     renames Original;
>
>   procedure Original (X : Integer := -1) is

                                    ^^^^^
>   begin
>      null;
>   end Original;
>
>begin
>   null;
>end Defaults;
>


Does not fail on boolean, character, float!

Re: Renaming subprogram and default_expression

[Larry Hazel]

Florian Weimer wrote:
> 
> "Alexander Boucke" <alexb@lufmech.rwth-aachen.de> writes:
> 
> > Type roman is range 1..3999; is defined in strings edit.ads Note,
> > that gnat3.14p does not complain about the preset values for the
> > booelan arguments, only for the new integer type. If I comment these
> > default values, the program compiles. This seems to be the same
> > error as in the short testprog. starting this thread: A new
> > integer-type was used there, too.
> 
> You can eliminate the integer type.  The minimal test case for GCC 3.1
> is:
> 
> procedure Defaults is
> 
>    procedure Original (X : Integer);
>    procedure Renamed (X : Integer := -1);
> 
>    procedure Renamed (X : Integer := -1)
>      renames Original;
> 
>    procedure Original (X : Integer) is
>    begin
>       null;
>    end Original;
> 
> begin
>    null;
> end Defaults;
> 
> (I wouldn't have thought that such basic things are broken, that's why
> I had not tried the default Integer type.)
> 
> I don't know why the bug doesn't occur with string types.  Oh well.

If you remove the declaration of Renamed and just leave the renames statement,
there is no error.  And here there is no need for the declaration.  However, if
you make it a package:

package Defaults is

   procedure Original (X : Integer);
   procedure Renamed (X : Integer := -1);

private

   procedure Renamed (X : Integer := -1)
     renames Original;
     
end Defaults;

the declaration is needed, and you get the error.  Looks like a bug.

Larry

Re: Renaming subprogram and default_expression

[Florian Weimer]

Florian Weimer <fw@deneb.enyo.de> writes:

> I don't know why the bug doesn't occur with string types.  Oh well.

I think I'm now on the right track.

GNAT ends up with something like this internally:

procedure defaults is
   procedure original (x : integer);
   procedure renamed (x : integer := "-" (1));
   procedure renamed (x : integer := "-" (1));
   
   procedure renamed (x : integer := -1) is  -- -1 is literal here
   begin
      original (x);
   end renamed;
   
   procedure original (x : integer) is
   begin
      null;
   end original;
begin
   null;
end defaults;

In this case, the error message is indeed appropriate.

Re: Renaming subprogram and default_expression

[Christoph Grein]

> package Defaults is
> 
>    procedure Original (X : Integer);        <--- (1) declaration
>    procedure Renamed (X : Integer := -1);   <--- (2) declaration
> 
> private
> 
>    procedure Renamed (X : Integer := -1)    <--- (3) renaming declaration
>      renames Original;
>      
> end Defaults;
> 
> the declaration is needed, and you get the error.  Looks like a bug.

The above exegesis is wrong. There is no bog here, the compiler is correct.
The following is the original. Please note the difference. While (3) is a 
renaming declaration that is illegal at this place because there is a 
conflictiog declaration (2), (3') is a renaming as body, completing the 
declaration (2'). If you remove (2'), (3') becomes a renaming declaration.

>    type Typ is new Integer;
> 
>    procedure Original (X : Typ);        <--- (1') declaration
>    procedure Renamed (X : Typ := -1);   <--- (2') declaration
>    
>    procedure Renamed (X : Typ := -1)    <--- (3') renaming as body
>      renames Original;
>    
>    procedure Original (X : Typ) is      <--- proper body
>    begin
>       null;
>    end Original;
> 
> begin
>    null;
> end Defaults;

Re: Renaming subprogram and default_expression

[Lutz Donnerhacke]

* Florian Weimer wrote:
>I think I'm now on the right track.

Congratulations!

>GNAT ends up with something like this internally:

>   procedure renamed (x : integer := "-" (1));
>   procedure renamed (x : integer := -1) is  -- -1 is literal here

>In this case, the error message is indeed appropriate.

Of course.