Patchwork [Ada] A prefixed view of a subprogram has convention Intrinsic

login
register
mail settings
Submitter Arnaud Charlet
Date Jan. 2, 2013, 9:38 a.m.
Message ID <20130102093819.GA31187@adacore.com>
Download mbox | patch
Permalink /patch/208980/
State New
Headers show

Comments

Arnaud Charlet - Jan. 2, 2013, 9:38 a.m.
This patch enforces the rule given in 6.3.1 (10.1/2): a prefixed view of a
subprogram is intrinsic, because the compiler has to generate a wrapper for any
call to it. If the name in a subprogram renaming is a prefixed view, the entity
is thus intrinsic, and 'Access cannot be applied to it.

Compiling the following must be rejected with:

main.adb:6:36: prefix of "Access" attribute cannot be intrinsic

---
with Some_Package;
procedure Main is
   Message: Some_Package.Message_Type;
   procedure Print renames Message.Print;  -- this has convention intrinsic,
                                           -- see RM 6.3.1(10.1/2)
   Method_Ref: access procedure := Print'Access;
    -- thus taking 'Access should be illegal
begin
   Method_Ref.all;
end;
---
package Some_Package is
   type Message_Type is tagged null record;
   procedure Print (Message: in Message_Type);
end Some_Package;

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-01-02  Ed Schonberg  <schonberg@adacore.com>

	* sem_ch8.adb (Analyze_Primitive_Renamed_Operation): The prefixed
	view of a subprogram has convention Intrnnsic, and a renaming
	of a prefixed view cannot be the prefix of an Access attribute.

Patch

Index: sem_ch8.adb
===================================================================
--- sem_ch8.adb	(revision 194776)
+++ sem_ch8.adb	(working copy)
@@ -397,8 +397,10 @@ 
       New_S   : Entity_Id;
       Is_Body : Boolean);
    --  If the renamed entity in a subprogram renaming is a primitive operation
-   --  or a class-wide operation in prefix form, save the target object, which
-   --  must be added to the list of actuals in any subsequent call.
+   --  or a class-wide operation in prefix form, save the target object,
+   --  which must be added to the list of actuals in any subsequent call.
+   --  The renaming operation is intrinsic because the compiler must in
+   --  fact generate a wrapper for it (6.3.1 (10 1/2)).
 
    function Applicable_Use (Pack_Name : Node_Id) return Boolean;
    --  Common code to Use_One_Package and Set_Use, to determine whether use
@@ -1602,6 +1604,10 @@ 
       --  match. The first formal of the renamed entity is skipped because it
       --  is the target object in any subsequent call.
 
+      --------------
+      -- Conforms --
+      --------------
+
       function Conforms
         (Subp : Entity_Id;
          Ctyp : Conformance_Type) return Boolean
@@ -1634,6 +1640,8 @@ 
          return True;
       end Conforms;
 
+   --  Start of processing for Analyze_Renamed_Primitive_Operation
+
    begin
       if not Is_Overloaded (Selector_Name (Name (N))) then
          Old_S := Entity (Selector_Name (Name (N)));
@@ -1681,6 +1689,14 @@ 
             if not Conforms (Old_S, Mode_Conformant) then
                Error_Msg_N ("mode conformance error in renaming", N);
             end if;
+
+            --  Enforce the rule given in (RM 6.3.1 (10.1/2)): a prefixed
+            --  view of a subprogram is intrinsic, because the compiler has
+            --  to generate a wrapper for any call to it. If the name in a
+            --  subprogram renaming is a prefixed view, the entity is thus
+            --  intrinsic, and 'Access cannot be applied to it.
+
+            Set_Convention (New_S, Convention_Intrinsic);
          end if;
 
          --  Inherit_Renamed_Profile (New_S, Old_S);