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.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Incomplete type generic formal interactions with Implicit_Dereference Date: Wed, 24 Jan 2018 20:34:55 -0600 Organization: JSA Research & Innovation Message-ID: References: <21b6b4fb-4648-419e-ae6c-c361d54eaa2f@googlegroups.com> <97b909da-a35b-45f9-aa88-ad7cc192a1c9@googlegroups.com> Injection-Date: Thu, 25 Jan 2018 02:34:55 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="27291"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:50130 Date: 2018-01-24T20:34:55-06:00 List-Id: Yes, I believe your example is legal. (I didn't actually try compiling it to see if there is any other problem.) Randy. "Jere" wrote in message news:97b909da-a35b-45f9-aa88-ad7cc192a1c9@googlegroups.com... > 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. >