* Incomplete type generic formal interactions with Implicit_Dereference @ 2018-01-20 18:00 Jere 2018-01-20 20:25 ` Simon Wright 2018-01-23 1:08 ` Randy Brukardt 0 siblings, 2 replies; 12+ messages in thread From: Jere @ 2018-01-20 18:00 UTC (permalink / raw) Recently I was working in a generic package that had an Incomplete type in its specification. Something like: generic type Some_Type(<>); -- ...other stuff package Some_Package is -- stuff end Some_Package; In it, I needed to return an access type of the Incomplete type, and I figured I would just do that through an implicit derefernced object. I made something like: type Some_Type_Holder(Ref : not null access Some_Type) is limited null record with Implicit_Dereference => Ref; At some point it led to a crash in GNAT, which I reported to AdaCore, and they said they fixed it in a future rev (side note, do I need to report that to the FSF team as well and how if so?). Recently, I've been wondering if what I tried to do was even meant to be legal? I don't actually use Some_Type_Holder directly in the package. It's just a return type of a function for a client to call. 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Incomplete type generic formal interactions with Implicit_Dereference 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-31 1:41 ` Jere 2018-01-23 1:08 ` Randy Brukardt 1 sibling, 2 replies; 12+ messages in thread From: Simon Wright @ 2018-01-20 20:25 UTC (permalink / raw) Jere <jhb.chat@gmail.com> writes: > At some point it led to a crash in GNAT, which I reported to AdaCore, > and they said they fixed it in a future rev (side note, do I need to > report that to the FSF team as well and how if so?). I don't know how many FSF GNAT contributors aren't AdaCore people, but it's not many! This sort of problem (deep in the compiler) isn't very likely to be solved by non-AdaCore folk. I've always felt uncomfortable when I report a bug to AdaCore (which won't contain proprietary info, since I don't have any) that no one else can see it. Not sure how reporting it to FSF as well as to AdaCore would be received; I try to go for one or the other. In any case, FSF won't accept reports on GNAT GPL (any more than AdaCore will accept reports on FSF GCC): you'd need to make sure the bug also happened with FSF GCC. To report a GNAT bug to FSF, set up an account on GCC Bugzilla <https://gcc.gnu.org/bugzilla/index.cgi>, and raise the bug on Product: gcc, Component: ada. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Incomplete type generic formal interactions with Implicit_Dereference 2018-01-20 20:25 ` Simon Wright @ 2018-01-20 22:22 ` Jere 2018-01-21 10:04 ` Simon Wright 2018-01-31 1:41 ` Jere 1 sibling, 1 reply; 12+ messages in thread From: Jere @ 2018-01-20 22:22 UTC (permalink / raw) On Saturday, January 20, 2018 at 3:25:34 PM UTC-5, Simon Wright wrote: > Jere writes: > > > At some point it led to a crash in GNAT, which I reported to AdaCore, > > and they said they fixed it in a future rev (side note, do I need to > > report that to the FSF team as well and how if so?). > > I don't know how many FSF GNAT contributors aren't AdaCore people, but > it's not many! This sort of problem (deep in the compiler) isn't very > likely to be solved by non-AdaCore folk. > > I've always felt uncomfortable when I report a bug to AdaCore (which > won't contain proprietary info, since I don't have any) that no one else > can see it. Not sure how reporting it to FSF as well as to AdaCore would > be received; I try to go for one or the other. > > In any case, FSF won't accept reports on GNAT GPL (any more than AdaCore > will accept reports on FSF GCC): you'd need to make sure the bug also > happened with FSF GCC. > > To report a GNAT bug to FSF, set up an account on GCC Bugzilla > <https://gcc.gnu.org/bugzilla/index.cgi>, and raise the bug on Product: > gcc, Component: ada. There were actually two bugs. One occurred on both GNAT GPL 2017 and GNAT FSF 7.2 on mingw64/msys2 x86_64 A second one only affected GNAT FSF 7.2 on mingw64/msys2 x86_64 The odd thing is for the second bug, GNAT GPL is 6.3, while the FSF is 7.2, yet the bug was fixed for the GPL version (6.3) and not the FSF version (7.2). I also wasn't sure if I should have reported the bug to FSF directly or to the maker of the mingw64 port of it. Based on your reply, it sounds like I should report that second one to FSF directly? Given that they don't seem to be incorporating bug fixes from GPL into FSF, I am concerned that the first bug I submitted to Adacore may not get fixed in the FSF version. It might, I just don't know since one of the bugs is fixed in an earlier version of GNAT but not a later version. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Incomplete type generic formal interactions with Implicit_Dereference 2018-01-20 22:22 ` Jere @ 2018-01-21 10:04 ` Simon Wright 2018-01-23 12:42 ` Jere 0 siblings, 1 reply; 12+ messages in thread From: Simon Wright @ 2018-01-21 10:04 UTC (permalink / raw) Jere <jhb.chat@gmail.com> writes: > There were actually two bugs. > One occurred on both GNAT GPL 2017 and GNAT FSF 7.2 on mingw64/msys2 > x86_64 A second one only affected GNAT FSF 7.2 on mingw64/msys2 x86_64 > > The odd thing is for the second bug, GNAT GPL is 6.3, while the FSF is > 7.2, yet the bug was fixed for the GPL version (6.3) and not the FSF > version (7.2). > > I also wasn't sure if I should have reported the bug to FSF directly > or to the maker of the mingw64 port of it. Based on your reply, it > sounds like I should report that second one to FSF directly? Given > that they don't seem to be incorporating bug fixes from GPL into FSF, > I am concerned that the first bug I submitted to Adacore may not get > fixed in the FSF version. It might, I just don't know since one of the > bugs is fixed in an earlier version of GNAT but not a later version. Under those circumstances I'd report the FSF bugs to FSF (I've been tracking the GCC 8 developments so that I can leap in with macOS binaries ASAP after the release!, so I'd check whether the bug was fixed in 8). AdaCore's timeline vs FSF isn't straighforward (there's some not-up-to-date info at [1]). AdaCore produce a Pro release about once a year, which they base on a well-known GCC release (in the case of GNAT GPL 2017, 6.3). This involves changes to Ada front-end code, to the C back-end code, and to the interface between them (and of course to Ada & C in the runtime). FSF GCC begins a new major release phase (currently for 8) also approximately once a year, not synced with AdaCore's releases. What AdaCore do (visibly, anyway) is to port the changes made in their own source tree at that time to the FSF tree; there's commonly a rush of commits at this point. After that, things slow down and bugs get fixed. So one would expect some of the bugs still present in GCC 7 to have been fixed in the GPL 2017 release (and, hopefully, in GCC 8). [1] https://people.debian.org/~lbrenta/debian-ada-policy.html#Timeline-of-GNAT-releases ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Incomplete type generic formal interactions with Implicit_Dereference 2018-01-21 10:04 ` Simon Wright @ 2018-01-23 12:42 ` Jere 0 siblings, 0 replies; 12+ messages in thread From: Jere @ 2018-01-23 12:42 UTC (permalink / raw) On Sunday, January 21, 2018 at 5:04:18 AM UTC-5, Simon Wright wrote: > Jere writes: > > > There were actually two bugs. > > One occurred on both GNAT GPL 2017 and GNAT FSF 7.2 on mingw64/msys2 > > x86_64 A second one only affected GNAT FSF 7.2 on mingw64/msys2 x86_64 > > > > The odd thing is for the second bug, GNAT GPL is 6.3, while the FSF is > > 7.2, yet the bug was fixed for the GPL version (6.3) and not the FSF > > version (7.2). > > > > I also wasn't sure if I should have reported the bug to FSF directly > > or to the maker of the mingw64 port of it. Based on your reply, it > > sounds like I should report that second one to FSF directly? Given > > that they don't seem to be incorporating bug fixes from GPL into FSF, > > I am concerned that the first bug I submitted to Adacore may not get > > fixed in the FSF version. It might, I just don't know since one of the > > bugs is fixed in an earlier version of GNAT but not a later version. > > Under those circumstances I'd report the FSF bugs to FSF (I've been > tracking the GCC 8 developments so that I can leap in with macOS > binaries ASAP after the release!, so I'd check whether the bug was fixed > in 8). > > AdaCore's timeline vs FSF isn't straighforward (there's some > not-up-to-date info at [1]). > > AdaCore produce a Pro release about once a year, which they base on a > well-known GCC release (in the case of GNAT GPL 2017, 6.3). This > involves changes to Ada front-end code, to the C back-end code, and to > the interface between them (and of course to Ada & C in the runtime). > > FSF GCC begins a new major release phase (currently for 8) also > approximately once a year, not synced with AdaCore's releases. What > AdaCore do (visibly, anyway) is to port the changes made in their own > source tree at that time to the FSF tree; there's commonly a rush of > commits at this point. After that, things slow down and bugs get fixed. > > So one would expect some of the bugs still present in GCC 7 to have been > fixed in the GPL 2017 release (and, hopefully, in GCC 8). > > [1] https://people.debian.org/~lbrenta/debian-ada-policy.html#Timeline-of-GNAT-releases Ok, that makes sense. It had just seemed odd that 6.3 had a bug fixed when 7.2 did not. Now I understand. I'll work on getting two bug reports to the FSF people. I only have the windows version of FSF GNAT to test on, so I don't know if it affects other platforms, but my gut says it will probably be the same since they result in GNAT crashes. Thanks! ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Incomplete type generic formal interactions with Implicit_Dereference 2018-01-20 20:25 ` Simon Wright 2018-01-20 22:22 ` Jere @ 2018-01-31 1:41 ` Jere 2018-01-31 7:57 ` Simon Wright 1 sibling, 1 reply; 12+ messages in thread From: Jere @ 2018-01-31 1:41 UTC (permalink / raw) On Saturday, January 20, 2018 at 3:25:34 PM UTC-5, Simon Wright wrote: > Jere writes: > > > At some point it led to a crash in GNAT, which I reported to AdaCore, > > and they said they fixed it in a future rev (side note, do I need to > > report that to the FSF team as well and how if so?). > > I don't know how many FSF GNAT contributors aren't AdaCore people, but > it's not many! This sort of problem (deep in the compiler) isn't very > likely to be solved by non-AdaCore folk. > > I've always felt uncomfortable when I report a bug to AdaCore (which > won't contain proprietary info, since I don't have any) that no one else > can see it. Not sure how reporting it to FSF as well as to AdaCore would > be received; I try to go for one or the other. > > In any case, FSF won't accept reports on GNAT GPL (any more than AdaCore > will accept reports on FSF GCC): you'd need to make sure the bug also > happened with FSF GCC. > > To report a GNAT bug to FSF, set up an account on GCC Bugzilla > <https://gcc.gnu.org/bugzilla/index.cgi>, and raise the bug on Product: > gcc, Component: ada. Thanks, I submitted the bug (took a while to get an account). https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84142 My first bug report so I probably noobed it up, but hopefully they won't be too upset if I did. Thanks for the help! ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Incomplete type generic formal interactions with Implicit_Dereference 2018-01-31 1:41 ` Jere @ 2018-01-31 7:57 ` Simon Wright 0 siblings, 0 replies; 12+ messages in thread From: Simon Wright @ 2018-01-31 7:57 UTC (permalink / raw) Jere <jhb.chat@gmail.com> writes: > Thanks, I submitted the bug (took a while to get an account). > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84142 > > My first bug report so I probably noobed it up, but hopefully they won't > be too upset if I did. Looks good to me ... > Thanks for the help! A pleasure. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Incomplete type generic formal interactions with Implicit_Dereference 2018-01-20 18:00 Incomplete type generic formal interactions with Implicit_Dereference Jere 2018-01-20 20:25 ` Simon Wright @ 2018-01-23 1:08 ` Randy Brukardt 2018-01-23 13:13 ` Jere 1 sibling, 1 reply; 12+ messages in thread From: Randy Brukardt @ 2018-01-23 1:08 UTC (permalink / raw) "Jere" <jhb.chat@gmail.com> wrote in message news:21b6b4fb-4648-419e-ae6c-c361d54eaa2f@googlegroups.com... ... > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Incomplete type generic formal interactions with Implicit_Dereference 2018-01-23 1:08 ` Randy Brukardt @ 2018-01-23 13:13 ` Jere 2018-01-23 13:20 ` Jere ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Jere @ 2018-01-23 13:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Incomplete type generic formal interactions with Implicit_Dereference 2018-01-23 13:13 ` Jere @ 2018-01-23 13:20 ` Jere 2018-01-23 16:00 ` Simon Wright 2018-01-25 2:34 ` Randy Brukardt 2 siblings, 0 replies; 12+ messages in thread From: Jere @ 2018-01-23 13:20 UTC (permalink / raw) On Tuesday, January 23, 2018 at 8:13:12 AM UTC-5, Jere wrote: > 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. I realize that some might point out the null access type. It doesn't change the result (again, contrived example), but for completion: procedure Main is generic type Some_Item(<>); package Some_Package is type Some_Item_Access is access Some_Item; 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; function Make(Ref : not null Some_Item_Access) return New_Type; private 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; function Make(Ref : not null Some_Item_Access) return New_Type is begin return (Some_Access => Ref); end Make; 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 := Test_Pkg.Make(new Test); begin Thing.Get_Some_Item.Value := 4; end Main; ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Incomplete type generic formal interactions with Implicit_Dereference 2018-01-23 13:13 ` Jere 2018-01-23 13:20 ` Jere @ 2018-01-23 16:00 ` Simon Wright 2018-01-25 2:34 ` Randy Brukardt 2 siblings, 0 replies; 12+ messages in thread From: Simon Wright @ 2018-01-23 16:00 UTC (permalink / raw) Jere <jhb.chat@gmail.com> writes: > 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): Also on FSF 8.0.0 (20171216). ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Incomplete type generic formal interactions with Implicit_Dereference 2018-01-23 13:13 ` Jere 2018-01-23 13:20 ` Jere 2018-01-23 16:00 ` Simon Wright @ 2018-01-25 2:34 ` Randy Brukardt 2 siblings, 0 replies; 12+ messages in thread From: Randy Brukardt @ 2018-01-25 2:34 UTC (permalink / raw) Yes, I believe your example is legal. (I didn't actually try compiling it to see if there is any other problem.) Randy. "Jere" <jhb.chat@gmail.com> 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. > ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-01-31 7:57 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2018-01-23 13:20 ` Jere 2018-01-23 16:00 ` Simon Wright 2018-01-25 2:34 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox