From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,b2fbc21c7c13dad4,start
X-Google-Attributes: gid103376,public
From: dewar@cs.nyu.edu (Robert Dewar)
Subject: A nice new feature in GNAT 3.06 (to be released shortly)
Date: 1996/06/20
Message-ID: <dewar.835327691@schonberg>#1/1
X-Deja-AN: 161818303
organization: Courant Institute of Mathematical Sciences
newsgroups: comp.lang.ada
Date: 1996-06-20T00:00:00+00:00
List-Id: <comp.lang.ada>


Previously, GNAT error messages have not done a very good job when it
comes to generics, since only one source location was maintained (the
location within the generic template. This caused two less than happy
error message behaviors.

First, error messages referencing an entity in an instance of a generic
referred to the location in the template, but not the location of the
instantiation. For example (thanks to Volker Elling from Germany for
this example):

   procedure t2 is
      generic
         type x is private;
      package p is
         type y is record
            n : x;
         end record;
      end p;

      package q1 is new p (x => character);
      package q2 is new p (x => character);

      a : q1.y;
      b : q2.y;
   begin
      a := b;
   end t2;

GNAT before 3.06 give the distinctly dubious messages:

  t2.adb:16:12: expected type "y" defined at line 5
  t2.adb:16:12: found type "y" defined at line 5

But 3.06 gives

   t2.adb:16:12: expected type "q1.y" defined at line 5, instance at line 10
   t2.adb:16:12: found type "q2.y" defined at line 5, instance at line 11

Actually there are two separate improvements here, both separately useful.
First the qualification is added to identical type names in this situation,
and secondly, the line of the instantiation is given as well as the line
in the generic template.

Second, when an improper instantiation occurred, i.e. one of the
requirements of the generic declaration was violated by an instantiation,
the error was posted on the (blameless) generic template, instead of on
the (guilty) instantiation. For example given the generic: (thanks to
Johann Blieberger (blieb@auto.tuwien.ac.at) for this example)
                  
   with Gen_Bool;
   generic
     type F_Float is digits <>;
   package F_Bool is
     type F_Bool is new Gen_Bool.Gen_Bool with private;
     ...
   end;

It is improper to instantiate this package as follows:

   with F_Bool;
   procedure Main_F is
     type real is digits 10;
     package My_F_Bool is new F_Bool(real);
   begin
     null;
   end Main_F;

Since accessibility rules are violated by the instantiation.

GNAT before 3.06 gave the rather dubious message, pointing to the generic:

   f_bool.ads:5:41: type extension at deeper accessibility level than parent

but 3.06 gives the much more helpful messages pointing to the instantiation:

   main_f.adb:4:03: instantiation error at f_bool.ads:5
   main_f.adb:4:03: type extension at deeper accessibility level than parent

where the error messages point to the guilty instantiation, but reference
the construct within the template that causes the difficulties.

Both these features nest properly, i.e. if instantiations occur within
templates, then the messages will identify the complete string of locations
(i.e. the location in the template, and the locations of all relevant
instantiation lines).

Interestingly, this additional information is stored without requiring any
extra space in the tree, there is still only one source location in the tree.
If you are interested in looking to see how this is done, you can read the
description in source file sinput-l.ads.

Robert Dewar
ACT