bug or feature

bug or feature

[Charly]

Hi,

I found the following strange behavior of gnat-gpl-2014 (ubuntu linux amd64) and I wonder, if it is a bug in gnat:

I  habe a package Datum_Pkg that defines a tagged type Datum and Datum_Vector (using Ada.Conainers.Vectors). In the main program I want to iterate over the vector (all irrelevant lines removed):

  1   with Ada.Text_IO;
  2   with Datum_Pkg;
  3  
  4   procedure Main is
  5 
  6      subtype Datum is Datum_Pkg.Datum;
  7      subtype Datum_Vector is Datum_Pkg.Datum_Vectors.Vector;
  8     
  9      D_Vec : Datum_Vector;
 10     
 11   begin
 12   
 13      for Dat : Datum_Pkg.Datum of D_Vec loop
 14         Ada.Text_IO.Put_Line ("Datum=" & Dat.Image);
 15      end loop;
 16      
 17      for Dat : Datum of D_Vec loop
 18         Ada.Text_IO.Put_Line ("Datum=" & Dat.Image);
 19      end loop;   
 20      
 21   end Main;

Line 13 compiles without message but in line 17 I get an error message:
   subtype indication does not match element type
But this line should be equivalent to line 13 because of the subtype definition
in line 6.


Regards
Charly

 

Re: bug or feature

[Dirk Heinrichs]

Charly wrote:

> [...] because of the subtype definition in line 6.

Shouldn't this be renames instead?

Bye...

	Dirk
-- 
Dirk Heinrichs <dirk.heinrichs@altum.de>
Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913
GPG Public Key CB614542 | Jabber: dirk.heinrichs@altum.de
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de

Re: bug or feature

[Stephen Leake]

Dirk Heinrichs <dirk.heinrichs@altum.de> writes:

> Charly wrote:
>
>> [...] because of the subtype definition in line 6.
>
> Shouldn't this be renames instead?

You can't use 'rename' on a type, only on an object. In most cases,
'subtype' is a good way to rename a type. But not in this case.

-- 
-- Stephe

Re: bug or feature

[Stephen Leake]

Charly <carl.weierstrass@googlemail.com> writes:

>   1   with Ada.Text_IO;
>   2   with Datum_Pkg;
>   3  
>   4   procedure Main is
>   5 
>   6      subtype Datum is Datum_Pkg.Datum;
>   7      subtype Datum_Vector is Datum_Pkg.Datum_Vectors.Vector;
>   8     
>   9      D_Vec : Datum_Vector;
>  10     
>  11   begin
>  12   
>  13      for Dat : Datum_Pkg.Datum of D_Vec loop
>  14         Ada.Text_IO.Put_Line ("Datum=" & Dat.Image);
>  15      end loop;
>  16      
>  17      for Dat : Datum of D_Vec loop
>  18         Ada.Text_IO.Put_Line ("Datum=" & Dat.Image);
>  19      end loop;   
>  20      
>  21   end Main;
>
> Line 13 compiles without message but in line 17 I get an error message:
>    subtype indication does not match element type
> But this line should be equivalent to line 13 because of the subtype definition
> in line 6.

line 6 defines a _new_ subtype, _different_ from Datum_Pkg.Datum. They have
the same base type, but the error message says "subtype", not "base
type".

So you are out of luck.

In general, a subtype can add constraints, which is why this matters; if
the loop parameter has different constraints than the container object,
you'll get runtime errors.

It might be possible to allow a "no new constraints" subtype such as
yours to be considered to match, but I suspect there are problems with
that as well.

-- 
-- Stephe

Re: bug or feature

[J-P. Rosen]

Le 08/09/2014 10:51, Stephen Leake a écrit :
> line 6 defines a _new_ subtype, _different_ from Datum_Pkg.Datum. They have
> the same base type, but the error message says "subtype", not "base
> type".
> 
> So you are out of luck.
Hmm... 5.5.2 says:

"The type of the subtype_indication, if any, of an array component
iterator shall cover the component type of the type of the
iterable_name. The type of the subtype_indication, if any, of a
container element iterator shall cover the default element type for the
type of the iterable_name."

So, it's the type of the subtype that matters.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: bug or feature

[Simon Wright]

Charly <carl.weierstrass@googlemail.com> writes:

> I found the following strange behavior of gnat-gpl-2014 (ubuntu linux
> amd64) and I wonder, if it is a bug in gnat:
>
> I habe a package Datum_Pkg that defines a tagged type Datum and
> Datum_Vector (using Ada.Conainers.Vectors). In the main program I want
> to iterate over the vector (all irrelevant lines removed):
[...]

> Line 13 compiles without message but in line 17 I get an error message:
>    subtype indication does not match element type
> But this line should be equivalent to line 13 because of the subtype
> definition in line 6.

Looks like a regression.

I tried this compilable version of your code

with Ada.Containers.Vectors;
with Ada.Text_IO;
procedure Datum is

   package Datum_Pkg is
      type Datum is tagged record
         V : Integer;
      end record;
      function Image (This : Datum) return String is (This.V'Img);
      package Datum_Vectors
        is new Ada.Containers.Vectors (Index_Type   => Positive,
                                       Element_Type => Datum);
      type Datum_Array is array (Positive range 1 .. 10) of Datum;
   end Datum_Pkg;

   subtype Datum is Datum_Pkg.Datum;
   subtype Datum_Vector is Datum_Pkg.Datum_Vectors.Vector;
--   subtype Datum_Vector is Datum_Pkg.Datum_Array;

   D_Vec : Datum_Vector;

begin

   for Dat : Datum_Pkg.Datum of D_Vec loop
      Ada.Text_IO.Put_Line ("Datum=" & Dat.Image);
   end loop;

   for Dat : Datum of D_Vec loop
      Ada.Text_IO.Put_Line ("Datum=" & Dat.Image);
   end loop;

end Datum;

and it fails as you say with GNAT GPL 2014 and FSF GCC 4.9.0. However,
GNAT GPL 2013 and FSF GCC 4.8.1 are both happy.

Not that that would mean it's a regression, necessarily, but if you swap
the definition of subtype Datum_Vector to the array version compilation
succeeds.

Re: bug or feature

[Adam Beneschan]

On Monday, September 8, 2014 1:52:01 AM UTC-7, Stephen Leake wrote:
> 
> >   1   with Ada.Text_IO;
> >   2   with Datum_Pkg;
> >   3  
> >   4   procedure Main is
> >   5 
> >   6      subtype Datum is Datum_Pkg.Datum;
> >   7      subtype Datum_Vector is Datum_Pkg.Datum_Vectors.Vector;
> >   8     
> >   9      D_Vec : Datum_Vector;
> >  10     
> >  11   begin
> >  12   
> >  13      for Dat : Datum_Pkg.Datum of D_Vec loop
> >  14         Ada.Text_IO.Put_Line ("Datum=" & Dat.Image);
> >  15      end loop;
> >  16      
> >  17      for Dat : Datum of D_Vec loop
> >  18         Ada.Text_IO.Put_Line ("Datum=" & Dat.Image);
> >  19      end loop;   
> >  20      
> >  21   end Main;
> 
> > Line 13 compiles without message but in line 17 I get an error message:
> >    subtype indication does not match element type
> > But this line should be equivalent to line 13 because of the subtype definition
> > in line 6.
> 
> line 6 defines a _new_ subtype, _different_ from Datum_Pkg.Datum. They have
> the same base type, but the error message says "subtype", not "base
> type".
> 
> So you are out of luck.
> 
> In general, a subtype can add constraints, which is why this matters; if
> the loop parameter has different constraints than the container object,
> you'll get runtime errors.

But that doesn't explain why he's getting a *compile-time* error.

As far as I can tell from the RM, you'd get an exception at run-time only if the subtype_indication is more restrictive than the container element *and* if the code actually tries to assign the loop parameter to an element that does not satisfy the subtype constraints.  This one looks like a GNAT bug to me.

                                   -- Adam

Re: bug or feature

[Charly]

Am Montag, 8. September 2014 10:48:42 UTC+2 schrieb Stephen Leake:
> Dirk Heinrichs writes:
> 
> 
> 
> > Charly wrote:
> 
> >
> 
> >> [...] because of the subtype definition in line 6.
> 
> >
> 
> > Shouldn't this be renames instead?
> 
> 
> 
> You can't use 'rename' on a type, only on an object. In most cases,
> 
> 'subtype' is a good way to rename a type. But not in this case.
> 
> 
> 
> -- 
> 
> -- Stephe

Why not in this case?
I've used 'subtype' in terms of 'renames' in many situations as I did in line 7 of my example program and never got this strange message.

------
Charly

Re: bug or feature

[Stephen Leake]

Charly <carl.weierstrass@googlemail.com> writes:

> Am Montag, 8. September 2014 10:48:42 UTC+2 schrieb Stephen Leake:
>> 
>> You can't use 'rename' on a type, only on an object. In most cases,
>> 
>> 'subtype' is a good way to rename a type. But not in this case.
>> 
>
> Why not in this case?

See the other thread.

-- 
-- Stephe

Re: bug or feature

[Dirk Heinrichs]

Stephen Leake wrote:

> Dirk Heinrichs <dirk.heinrichs@altum.de> writes:
> 
>> Charly wrote:
>>
>>> [...] because of the subtype definition in line 6.
>>
>> Shouldn't this be renames instead?
> 
> You can't use 'rename' on a type, only on an object. In most cases,
> 'subtype' is a good way to rename a type. But not in this case.

Ah, OK.

Bye...

	Dirk
-- 
Dirk Heinrichs <dirk.heinrichs@altum.de>
Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913
GPG Public Key CB614542 | Jabber: dirk.heinrichs@altum.de
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de

Re: bug or feature

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> Looks like a regression.
>
> I tried this compilable version of your code
>
> <snip>
> and it fails as you say with GNAT GPL 2014 and FSF GCC 4.9.0. However,
> GNAT GPL 2013 and FSF GCC 4.8.1 are both happy.

Gnat 7.2.1 gives the error.

In general, I've found that GNAT gets more precise as time goes on. So I
suspect this is a legitimate error, the check for which was recently
implemented.

On the other hand, the generalized iterator code is all fairly new, so
it could also be that something they changed broke this.

Definitely worth reporting.

-- 
-- Stephe

Re: bug or feature

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Simon Wright <simon@pushface.org> writes:
>
>> Looks like a regression.
>>
>> I tried this compilable version of your code
>>
>> <snip>
>> and it fails as you say with GNAT GPL 2014 and FSF GCC 4.9.0. However,
>> GNAT GPL 2013 and FSF GCC 4.8.1 are both happy.
>
> Gnat 7.2.1 gives the error.
>
> In general, I've found that GNAT gets more precise as time goes on. So I
> suspect this is a legitimate error, the check for which was recently
> implemented.
>
> On the other hand, the generalized iterator code is all fairly new, so
> it could also be that something they changed broke this.
>
> Definitely worth reporting.

AdaCore say "This works properly on the development version of GNAT."