comp.lang.ada
 help / color / mirror / Atom feed
From: Jere <jhb.chat@gmail.com>
Subject: Re: Incomplete type generic formal interactions with Implicit_Dereference
Date: Tue, 23 Jan 2018 05:13:10 -0800 (PST)
Date: 2018-01-23T05:13:10-08:00	[thread overview]
Message-ID: <97b909da-a35b-45f9-aa88-ad7cc192a1c9@googlegroups.com> (raw)
In-Reply-To: <p461v9$3m6$1@franka.jacob-sparre.dk>

On Monday, January 22, 2018 at 8:08:59 PM UTC-5, Randy Brukardt wrote:
> "Jere" wrote in message 
> ...
> > Part of me thinks that since Some_Type is incomplete, that Ada wouldn't
> > allow for an Implicit_Dereference declared on it.  I guess it depends on
> > if it is meant to be evaluated in the compilation of the generic itself
> > or at the point at which the function is called.
> >
> > Anyone have any thoughts on this?
> 
> I don't think we ever considered this case. But I think it is OK.
> 
> Specifically, 4.1.5(6/3) says that a generalized reference denotes a view 
> equivalent to that of a dereference of the reference discriminant of the 
> reference object. Thus, any Legality Rules that apply to the dereference of 
> the discriminant apply to the generalized reference as well. For instance, 
> this includes any accessibility rules (which was an important part of the 
> design, as the accessibility rules prevent the access value from living 
> longer than the object containing the access discriminant).
> 
> As such, any other Legality Rules, like the ones about incomplete types 
> would also apply. Specifically, 3.10.1(10/3): "A prefix that denotes an 
> object shall not be of an incomplete view."
> 
> So a use of an Implicit_Dereference wherever the type is incomplete would 
> usually be illegal (there are a few ways that a dereference of an incomplete 
> view can be used, mainly to be passed as a parameter to some routine with an 
> access-to-incomplete parameter). But it would be OK where the type has been 
> completed (in this case, outside of the generic instantiation, the way you 
> intended to use this). This sounds like what you intended.
> 
>                                    Randy.

I think I gotcha.  Just wanted to verify since I realized that I presented
the example a bit disjointed.  If I have a dummy example:

procedure Main is
   generic
      type Some_Item(<>);
   package Some_Package is

      type New_Type is tagged limited private;

      type Some_Item_Holder(Ref : not null access Some_Item)
      is limited null record
         with
            Implicit_Dereference => Ref;

      function Get_Some_Item
         (Object : New_Type)
       return Some_Item_Holder;

   private

      type Some_Item_Access is access Some_Item;

      type New_Type is tagged limited record
         Some_Access : Some_Item_Access;
      end record;

   end Some_Package;

     

   package body Some_Package is
      function Get_Some_Item
         (Object : New_Type)
       return Some_Item_Holder
      is
      begin
         return (Ref => Object.Some_Access);
      end Get_Some_Item;
   end Some_Package;
   
   type Test;
   package Test_Pkg is new Some_Package(Test);
   
   type Test is record
      value : Integer;
   end record;
   
   Thing : Test_Pkg.New_Type;
   
begin
   Thing.Get_Some_Item.Value := 4;
end Main;


From your last response, if I understand correctly, then this
should be OK, legal Ada.  Sorry for the contrived example, I
just wanted to make sure I didn't mislead with my original message,
so I generated a minimal example.  I would normally have stuff
broken up into separate files with better naming, etc.

If Simon is seeing this, then the above code is one example of 
what causes one of the crashes.  It is the one that breaks in
both versions (GPL 2017 and FSF 7.2):


$ gcc --version
gcc.exe (Rev1, Built by MSYS2 project) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ gprbuild default.gpr
gcc -c -gnatn -gnato -gnatE -fstack-check -gnat12 -O3 main.adb
+===========================GNAT BUG DETECTED==============================+
| 7.2.0 (x86_64-w64-mingw32) Segmentation fault                            |
| Error detected at main.adb:49:9                                          |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .              |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact command that you entered.                              |
| Also include sources listed below.                                       |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

Ada\Scratch\src\main.adb

compilation abandoned
gprbuild: *** compilation phase failed


My NOTE:  the compilation flags just happened to be
whatever they were last.  This is from my scratch project
space.  I don't think they actually matter.
 


  reply	other threads:[~2018-01-23 13:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-20 18:00 Incomplete type generic formal interactions with Implicit_Dereference Jere
2018-01-20 20:25 ` Simon Wright
2018-01-20 22:22   ` Jere
2018-01-21 10:04     ` Simon Wright
2018-01-23 12:42       ` Jere
2018-01-31  1:41   ` Jere
2018-01-31  7:57     ` Simon Wright
2018-01-23  1:08 ` Randy Brukardt
2018-01-23 13:13   ` Jere [this message]
2018-01-23 13:20     ` Jere
2018-01-23 16:00     ` Simon Wright
2018-01-25  2:34     ` Randy Brukardt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox