* Re: Formal Subprogram Access
2018-02-13 5:51 ` Randy Brukardt
@ 2018-02-13 9:24 ` AdaMagica
2018-02-13 9:41 ` Dmitry A. Kazakov
2018-02-13 12:24 ` Simon Wright
2018-02-13 17:34 ` Jeffrey R. Carter
2 siblings, 1 reply; 25+ messages in thread
From: AdaMagica @ 2018-02-13 9:24 UTC (permalink / raw)
Am Dienstag, 13. Februar 2018 06:51:56 UTC+1 schrieb Randy Brukardt:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message
> news:p5mflm$ibq$1@dont-email.me...
> > On 02/10/2018 04:03 AM, Randy Brukardt wrote:
> >>
> >> Why do you think this is correct? I can't read 3.10.2(32/5) in a way
> >> which
> >> would prevent using a formal subprogram in this way (assuming that the
> >> profile matches, which is does trivially in this case). Indeed, there is
> >> specifically an exception allowing "an anonymous access type of an access
> >> parameter."
This is RM 6.3.1(9).
> > IIRC, you can't take 'Access of some attributes that act as subprograms,
> > but you can use them as the actual for a generic formal subprogram. So a
> > generic can't take 'Access of a generic formal subprogram.
>
> There's no such rule in the RM. As Christoph noted, a generic formal
> subprogram has convention Ada, 'Access is allowed. If you pass an attribute
> to it, you have to wrap it in a real subprogram for this reason. (There is a
> lot of code specifically to do this in Janus/Ada, it probably never has been
> tested outside of a single ACATS test -- I don't think anyone ever has had a
> reason to pass an attribute like Succ as a formal subprogram.)
But I found no rule that the generic actual subprogram parameter must not have the Intrinsic convention.
And IIRC, I once used the 'Image attribute as actual.
So now I'm confused. Is it allowed to take 'Access of a formal subprogram? If the actual is an attribute, it is Intrinsic, so 'Access is not allowed.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Formal Subprogram Access
2018-02-13 9:24 ` AdaMagica
@ 2018-02-13 9:41 ` Dmitry A. Kazakov
2018-02-13 10:28 ` AdaMagica
0 siblings, 1 reply; 25+ messages in thread
From: Dmitry A. Kazakov @ 2018-02-13 9:41 UTC (permalink / raw)
On 13/02/2018 10:24, AdaMagica wrote:
> So now I'm confused. Is it allowed to take 'Access of a formal subprogram? If the actual is an attribute, it is Intrinsic, so 'Access is not allowed.
and, one can write a generic, rename the formal argument inside it.
Instantiate it with 'Image, take 'Access of the renaming from the
instance and thus work around the constraint, now outside the generics.
Either the constraint is superfluous or generic renaming is not renaming
but actually a wrapper generator, which I think it really is.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Formal Subprogram Access
2018-02-13 9:41 ` Dmitry A. Kazakov
@ 2018-02-13 10:28 ` AdaMagica
2018-02-14 0:47 ` Randy Brukardt
0 siblings, 1 reply; 25+ messages in thread
From: AdaMagica @ 2018-02-13 10:28 UTC (permalink / raw)
RM 6.3.1(9) Attribute subprograms have convention Intrinsic.
RM 8.5.4(5/3) Intrinsic subprograms must not be renamed.
RM 12.6(9) In an instance, a formal_subprogram_declaration declares a view of
the actual. The profile of this view takes its ... calling
convention from the original profile of the actual entity.
It seems that attribute subprograms are allowed as actuals.
So again: Is 'Access and renaming of a formal subprogam allowed? It might be an attribute.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Formal Subprogram Access
2018-02-13 10:28 ` AdaMagica
@ 2018-02-14 0:47 ` Randy Brukardt
2018-02-14 8:19 ` Dmitry A. Kazakov
0 siblings, 1 reply; 25+ messages in thread
From: Randy Brukardt @ 2018-02-14 0:47 UTC (permalink / raw)
"AdaMagica" <christ-usch.grein@t-online.de> wrote in message
news:dfb02e95-8bcd-4226-84d5-39bd20243421@googlegroups.com...
> RM 6.3.1(9) Attribute subprograms have convention Intrinsic.
> RM 8.5.4(5/3) Intrinsic subprograms must not be renamed.
> RM 12.6(9) In an instance, a formal_subprogram_declaration declares a
> view of
> the actual. The profile of this view takes its ... calling
> convention from the original profile of the actual entity.
>
> It seems that attribute subprograms are allowed as actuals.
>
> So again: Is 'Access and renaming of a formal subprogam allowed? It might
> be an attribute.
RM 12.3(11): Legality Rules are not enforced in the body of an instance.
Ergo, the actual subprogram is irrelevant as to whether 'Access is allowed
in a generic body.
There is a special rule for that case in 3.10.2(38/3), and that rule
explicitly allows 'Access to be passed as an anonymous access type. Nothing
in 6.3.1 or anywhere else says that a generic formal subprogram has
convention intrinsic. So I conclude this is legal -- in a generic body.
The rules about the instance only apply in a generic specification, so if
the 'Access is given in the specification, then the 'Access might later be
illegal.
In either of these cases, renaming it (as a spec) does not change any of
these properties. (A renames-as-body is more like a call, so it could change
these properties, as a wrapper is required in any case.)
But a better solution in general is to avoid 'Access altogether -- then you
don't need a panel of experts to argue about whether it is legal or not. ;-)
Randy.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Formal Subprogram Access
2018-02-13 5:51 ` Randy Brukardt
2018-02-13 9:24 ` AdaMagica
@ 2018-02-13 12:24 ` Simon Wright
2018-02-14 0:53 ` Randy Brukardt
2018-02-13 17:34 ` Jeffrey R. Carter
2 siblings, 1 reply; 25+ messages in thread
From: Simon Wright @ 2018-02-13 12:24 UTC (permalink / raw)
"Randy Brukardt" <randy@rrsoftware.com> writes:
> There's no such rule in the RM. As Christoph noted, a generic formal
> subprogram has convention Ada, 'Access is allowed. If you pass an
> attribute to it, you have to wrap it in a real subprogram for this
> reason. (There is a lot of code specifically to do this in Janus/Ada,
> it probably never has been tested outside of a single ACATS test -- I
> don't think anyone ever has had a reason to pass an attribute like
> Succ as a formal subprogram.)
In GNAT, I've passed 'Image, 'Value as actuals for corresponding formal
subprograms.
generic
type Checked_Type is private;
Checked_Type_Name : String;
with function "=" (L, R : Checked_Type) return Boolean is <>;
with function Value (S : String) return Checked_Type is <>;
with function Image (V : Checked_Type) return String is <>;
package Check_Passed_Value is
Which ACATS test should have caught that (or any other attribute, of
course)?
I see that the GCC-based tests that I've been working on at
https://github.com/simonjwright/ACATS wouldn't necessarily catch all the
errors expected in the B (and L?) tests: for example, BC70009 reports 4
compilation errors, which counts as a success because of course B tests
are expected to fail, but doesn't check that all the expected errors
have in fact been caught. (In this case, 4 was correct.) I should check
the grading tool, though I'm not sure that complete conformance checks
are justified in this context - it's more to ensure that some feature
hasn't been broken.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Formal Subprogram Access
2018-02-13 12:24 ` Simon Wright
@ 2018-02-14 0:53 ` Randy Brukardt
2018-02-14 14:36 ` Simon Wright
0 siblings, 1 reply; 25+ messages in thread
From: Randy Brukardt @ 2018-02-14 0:53 UTC (permalink / raw)
"Simon Wright" <simon@pushface.org> wrote in message
news:lyeflpkrh3.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> There's no such rule in the RM. As Christoph noted, a generic formal
>> subprogram has convention Ada, 'Access is allowed. If you pass an
>> attribute to it, you have to wrap it in a real subprogram for this
>> reason. (There is a lot of code specifically to do this in Janus/Ada,
>> it probably never has been tested outside of a single ACATS test -- I
>> don't think anyone ever has had a reason to pass an attribute like
>> Succ as a formal subprogram.)
>
> In GNAT, I've passed 'Image, 'Value as actuals for corresponding formal
> subprograms.
It should be legal to do that. My point is that I don't think that there are
many such uses in practice (I've never written one), so it's rather likely
that the special code to implement those is mostly untested. I'm pretty sure
that there is a few Ada 83 ACATS tests that do this, but nothing for newer
attributes (like 'Read).
> generic
> type Checked_Type is private;
> Checked_Type_Name : String;
> with function "=" (L, R : Checked_Type) return Boolean is <>;
> with function Value (S : String) return Checked_Type is <>;
> with function Image (V : Checked_Type) return String is <>;
> package Check_Passed_Value is
>
> Which ACATS test should have caught that (or any other attribute, of
> course)?
I don't know of any easy way to find that out, and I don't have time to read
roughly 4000 tests to find one. Sorry.
> I see that the GCC-based tests that I've been working on at
> https://github.com/simonjwright/ACATS wouldn't necessarily catch all the
> errors expected in the B (and L?) tests: for example, BC70009 reports 4
> compilation errors, which counts as a success because of course B tests
> are expected to fail, but doesn't check that all the expected errors
> have in fact been caught. (In this case, 4 was correct.) I should check
> the grading tool, though I'm not sure that complete conformance checks
> are justified in this context - it's more to ensure that some feature
> hasn't been broken.
I have a set of tools for running the grading tool with GNAT. I've been
waiting to find some time to finish vetting the results, which I've recently
done. [Although I really ought to redo it with GNAT 18.1.] So I'll be
posting them soon as "submitted tests" (since compiler-specific stuff
doesn't belong in the ACATS proper).
Randy.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Formal Subprogram Access
2018-02-14 0:53 ` Randy Brukardt
@ 2018-02-14 14:36 ` Simon Wright
2018-02-15 4:56 ` Randy Brukardt
0 siblings, 1 reply; 25+ messages in thread
From: Simon Wright @ 2018-02-14 14:36 UTC (permalink / raw)
"Randy Brukardt" <randy@rrsoftware.com> writes:
> I have a set of tools for running the grading tool with GNAT. I've
> been waiting to find some time to finish vetting the results, which
> I've recently done. [Although I really ought to redo it with GNAT
> 18.1.] So I'll be posting them soon as "submitted tests" (since
> compiler-specific stuff doesn't belong in the ACATS proper).
Good news!
For info, my current 8.0.1 20180207 results, vs 4.1f, are
# of expected passes 2500
# of unexpected failures 9
# of expected failures 1451
# of unresolved testcases 11
# of unsupported tests 121
*** FAILURES: c250002 cxd1003 cxd1004 cxd1005 cxd4007 cxd2006 cxd3001 cxd3002 c611a04
'unsupported' includes those where there is more than one copy of each
unit in the input source.
'unresolved' means visual inspection required, all OK.
c250002 is a Mac file system UTF8 case sensitivity issue, OK on Linux.
The cxd failures are I think down to running on a host system, & AdaCore
would probably mark them as expected failures.
The new one to me is c611a04 (class-wide pre/post conditions); also
fails with GCC 7.1.0.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Formal Subprogram Access
2018-02-14 14:36 ` Simon Wright
@ 2018-02-15 4:56 ` Randy Brukardt
2018-02-15 13:12 ` Simon Clubley
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Randy Brukardt @ 2018-02-15 4:56 UTC (permalink / raw)
"Simon Wright" <simon@pushface.org> wrote in message
news:lymv0bk59g.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> I have a set of tools for running the grading tool with GNAT. I've
>> been waiting to find some time to finish vetting the results, which
>> I've recently done. [Although I really ought to redo it with GNAT
>> 18.1.] So I'll be posting them soon as "submitted tests" (since
>> compiler-specific stuff doesn't belong in the ACATS proper).
>
> Good news!
>
> For info, my current 8.0.1 20180207 results, vs 4.1f, are
>
> # of expected passes 2500
> # of unexpected failures 9
> # of expected failures 1451
> # of unresolved testcases 11
> # of unsupported tests 121
> *** FAILURES: c250002 cxd1003 cxd1004 cxd1005 cxd4007 cxd2006 cxd3001
> cxd3002 c611a04
This is similar to the list of C-Tests that the ACATS tools report as
failed.
> 'unsupported' includes those where there is more than one copy of each
> unit in the input source.
>
> 'unresolved' means visual inspection required, all OK.
>
> c250002 is a Mac file system UTF8 case sensitivity issue, OK on Linux.
I have a similar problem on Windows. I marked this one as a tools bug (since
I didn't implement the needed UTF-8 support into the ACATS grading tools
version 1.0), but perhaps it is a real bug with GNAT.
> The cxd failures are I think down to running on a host system, & AdaCore
> would probably mark them as expected failures.
On Windows, I have a somewhat different list of cxd tests that fail, but
I've blamed that on Windows not having the appropriate behavior. Probably an
implementer wouldn't test Annex D on such a target (which would potentially
eliminate the entire set from grading).
> The new one to me is c611a04 (class-wide pre/post conditions); also
> fails with GCC 7.1.0.
I think this test is quite new, and just reflects a bug in GNAT. GNAT, like
all Ada compilers, fails a decent percentage of new ACATS tests. It's
unreasonable to expect perfection in this area, and one expects that a
future version will fix it.
I also have a bunch of failed B-Tests (since the primary point of the
grading tools was to automate grading of B-Tests); that grading is somewhat
subjective as any hand grading will be. But there a few old tests that show
no errors at all; it's hard to imagine how those work unless they work
better with some other option setting.
There's also a large number of tests that fail grading mainly because the
tools can't handle where the error messages are placed. Those tests will be
corrected over time (some in 4.1G, coming soon) but for now one has to just
put them on the manual grading list that the ACATS tool takes.
One of the big things learned from these automatic grading tools is that it
is really easy for junk results to creep into typical ACATS grading setups
(which usually depend on comparing against known-good results). I found 4
ACATS tests that were marked as passing for Janus/Ada that actually failed.
Two of those actually reflected compiler bugs introduced in recent years
(both easy to fix, thank goodness), one was a batch file problem, and one
probably was just let off of the to-do list (but of course if it isn't on
the to-do list, it isn't very likely to ever be worked on). Thus I'm not too
surprised to find similar things for GNAT.
Randy.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Formal Subprogram Access
2018-02-15 4:56 ` Randy Brukardt
@ 2018-02-15 13:12 ` Simon Clubley
2018-02-15 16:38 ` Simon Wright
2018-02-15 16:19 ` Simon Wright
2018-02-15 23:03 ` Randy Brukardt
2 siblings, 1 reply; 25+ messages in thread
From: Simon Clubley @ 2018-02-15 13:12 UTC (permalink / raw)
On 2018-02-14, Randy Brukardt <randy@rrsoftware.com> wrote:
>
> "Simon Wright" <simon@pushface.org> wrote in message
> news:lymv0bk59g.fsf@pushface.org...
>>
>> Good news!
>>
>> For info, my current 8.0.1 20180207 results, vs 4.1f, are
>>
>> # of expected passes 2500
>> # of unexpected failures 9
>> # of expected failures 1451
>> # of unresolved testcases 11
>> # of unsupported tests 121
>> *** FAILURES: c250002 cxd1003 cxd1004 cxd1005 cxd4007 cxd2006 cxd3001
>> cxd3002 c611a04
>
> This is similar to the list of C-Tests that the ACATS tools report as
> failed.
>
Does the testsuite also report the number of unexpected passes ?
I don't see a line for that above, and if the number is zero, I would
expect to see a line of output confirming that.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Formal Subprogram Access
2018-02-15 13:12 ` Simon Clubley
@ 2018-02-15 16:38 ` Simon Wright
2018-02-15 18:40 ` Simon Clubley
0 siblings, 1 reply; 25+ messages in thread
From: Simon Wright @ 2018-02-15 16:38 UTC (permalink / raw)
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
> On 2018-02-14, Randy Brukardt <randy@rrsoftware.com> wrote:
>>
>> "Simon Wright" <simon@pushface.org> wrote in message
>> news:lymv0bk59g.fsf@pushface.org...
>>>
>>> Good news!
>>>
>>> For info, my current 8.0.1 20180207 results, vs 4.1f, are
>>>
>>> # of expected passes 2500
>>> # of unexpected failures 9
>>> # of expected failures 1451
>>> # of unresolved testcases 11
>>> # of unsupported tests 121
>>> *** FAILURES: c250002 cxd1003 cxd1004 cxd1005 cxd4007 cxd2006 cxd3001
>>> cxd3002 c611a04
>>
>> This is similar to the list of C-Tests that the ACATS tools report as
>> failed.
>>
>
> Does the testsuite also report the number of unexpected passes ?
It would if there were any.
> I don't see a line for that above, and if the number is zero, I would
> expect to see a line of output confirming that.
So far as I can tell, this behaviour is consistent with other GCC
tests. Certainly with "make check-gnat".
The GCC ACATS tests are run by a shell script, unlike all (?) the other
tests which are run via dejagnu, and the current script in GCC
reports PASSes and FAILs unconditionally and UNSUPPORTED if non-zero (it
doesn't check XPASS, because it doesn't run B or L tests which are the
ones expected to fail).
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Formal Subprogram Access
2018-02-15 16:38 ` Simon Wright
@ 2018-02-15 18:40 ` Simon Clubley
0 siblings, 0 replies; 25+ messages in thread
From: Simon Clubley @ 2018-02-15 18:40 UTC (permalink / raw)
On 2018-02-15, Simon Wright <simon@pushface.org> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>> Does the testsuite also report the number of unexpected passes ?
>
> It would if there were any.
>
>> I don't see a line for that above, and if the number is zero, I would
>> expect to see a line of output confirming that.
>
> So far as I can tell, this behaviour is consistent with other GCC
> tests. Certainly with "make check-gnat".
>
I see, thanks.
It's just that I tend to be more explicit in my output when reporting
things like this.
Thanks,
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Formal Subprogram Access
2018-02-15 4:56 ` Randy Brukardt
2018-02-15 13:12 ` Simon Clubley
@ 2018-02-15 16:19 ` Simon Wright
2018-02-15 23:03 ` Randy Brukardt
2 siblings, 0 replies; 25+ messages in thread
From: Simon Wright @ 2018-02-15 16:19 UTC (permalink / raw)
"Randy Brukardt" <randy@rrsoftware.com> writes:
> "Simon Wright" <simon@pushface.org> wrote in message
> news:lymv0bk59g.fsf@pushface.org...
>> c250002 is a Mac file system UTF8 case sensitivity issue, OK on Linux.
>
> I have a similar problem on Windows. I marked this one as a tools bug (since
> I didn't implement the needed UTF-8 support into the ACATS grading tools
> version 1.0), but perhaps it is a real bug with GNAT.
There was a discussion about this one getting on for a year ago:
https://groups.google.com/d/msg/comp.lang.ada/ZhDARPQ8deQ/fubEjsggBAAJ
See the second post.
AdaCore might address this if they have enough Windows customers who
need extended characters in package names! but otherwise I think a fix
is unlikely.
And the Mac problem with file names, which I diagnosed as code points in
NFC being converted to NFD on the file system, persists even into APFS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114#c2
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Formal Subprogram Access
2018-02-15 4:56 ` Randy Brukardt
2018-02-15 13:12 ` Simon Clubley
2018-02-15 16:19 ` Simon Wright
@ 2018-02-15 23:03 ` Randy Brukardt
2 siblings, 0 replies; 25+ messages in thread
From: Randy Brukardt @ 2018-02-15 23:03 UTC (permalink / raw)
I wrote:
...
> One of the big things learned from these automatic grading tools is that
> it is really easy for junk results to creep into typical ACATS grading
> setups (which usually depend on comparing against known-good results). I
> found 4 ACATS tests that were marked as passing for Janus/Ada that
> actually failed. Two of those actually reflected compiler bugs introduced
> in recent years (both easy to fix, thank goodness), one was a batch file
> problem, and one probably was just let off of the to-do list (but of
> course if it isn't on the to-do list, it isn't very likely to ever be
> worked on). Thus I'm not too surprised to find similar things for GNAT.
I should clarify a bit about this. Just because the automated tools report
GNAT as failing on some particular target, that doesn't mean tht GNAT
actually would fail a formal conformity assessment. There are a number of
other factors in play.
First, the fully automated testing tool can only handle "usual" tests; those
that require special handling have to be run specially. For my GNAT tools,
this includes things like the tests that include foreign language code (the
ACATS grading tools ignore such code as it isn't relevant to grading - the
only thing that matters about it is that it was compiled, and it isn't worth
anyone's time to try to automate detection of non-Ada compilers and non-Ada
source code). It also includes all of the Annex E tests that require actual
partitioning (I have no personal interest in figuring out how to configure
those).
For a formal conformity assessment, many of these special handling things
would be run using custom scripts (rather than the automatically generated
scripts generated by the tools); the results of running those scripts could
be graded with the usual grading tool. This would handle examples like the
cases above, as well as any other tests that need special options to be
processed correctly.
Moreover, an implementer doing a formal test would have the opportunity to
challenge the grading of any test, potentially to explain why it should be
considered "Passed", to suggest that it be run specially, or even to argue
that it does not appropriately reflect the rules of Ada. These test disputes
would be discussed with the ACAL (the formal tester) and possibly with the
ACAA Technical Agent (that's me). This process can result in modified
grading requirements for that implementer or for all ACATS users, or even
the permanent removal of test from the test suite.
Additionally, the ACATS gradiing tool enforces a rather strict view of the
ACATS grading standards. It's quite likely that a B-Test that it reports as
failed actually would be graded as passed by a human as the error message is
"close enough" to the required location. Moreover, a human can read the
contents of an error message while the grading tool makes no attempt to do
that. (I've spent some time improving existing ACATS tests so that the
grading tools are more likely to be able to grade them successfully; but
doing that for the entire test suite is not going to be a good use of
limited resources.)
To summarize, just because an automatic test run grades some tests as failed
doesn't necessarily mean that those tests would be graded as failed in a
formal conformity assessment. More simply, some failures in an automatic
test run doesn't mean that the compiler can't pass conformity assessment.
Randy.
P.S. It should be noted that I did most of this GNAT tools work on my own
time, and not in an official capacity as ACAA Technical Agent. If I had done
it officially, I wouldn't be allowed to talk about it (which would have
defeated the purpose of building the tools).
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Formal Subprogram Access
2018-02-13 5:51 ` Randy Brukardt
2018-02-13 9:24 ` AdaMagica
2018-02-13 12:24 ` Simon Wright
@ 2018-02-13 17:34 ` Jeffrey R. Carter
2018-02-13 18:31 ` AdaMagica
2 siblings, 1 reply; 25+ messages in thread
From: Jeffrey R. Carter @ 2018-02-13 17:34 UTC (permalink / raw)
On 02/13/2018 06:51 AM, Randy Brukardt wrote:
>
> There's no such rule in the RM. As Christoph noted, a generic formal
> subprogram has convention Ada, 'Access is allowed. If you pass an attribute
> to it, you have to wrap it in a real subprogram for this reason. (There is a
> lot of code specifically to do this in Janus/Ada, it probably never has been
> tested outside of a single ACATS test -- I don't think anyone ever has had a
> reason to pass an attribute like Succ as a formal subprogram.)
6.3.1(9) says an attribute subprogram is Intrinsic
6.3.1(11) say you can't apply 'Access to an Intrinsic subprogram
12.6 (14) says a generic formal subprogram may be matched by an attribute function
12.6(16.2) say a generic formal subprogram with "is null" for the default, not
matched by an explicit actual, is Intrinsic.
Since a formal subprogram may be instantiated with an Intrinsic actual, a
generic should not be allowed to take 'Access of a formal subprogram.
> If you rename such an attribute, however, the convention stays the same, so
> 'Access isn't allowed then. But renaaming a formal subprogram certainly
> shouldn't change whether or not 'Access is allowed.
The only restriction I can see on renaming an Intrinsic subprogram deals with
renaming-as-body, which doesn't apply here, so the renaming seems legal.
However, as the convention of the renaming may also be Intrinsic, it seems a
generic should be allowed to take 'Access of a renaming of a formal subprogram.
> As I said, file a bug report. Even if I'm wrong about the legality of
> 'Access on a formal subprogram, the renames should work the same way.
GNAT does instantiation as macro expansion. Might that have any effect on how
these rules apply or when a violation is detected?
--
Jeff Carter
"If you don't get the President of the United States on that
phone, ... you're going to have to answer to the Coca-Cola
Company."
Dr. Strangelove
32
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Formal Subprogram Access
2018-02-13 17:34 ` Jeffrey R. Carter
@ 2018-02-13 18:31 ` AdaMagica
2018-02-14 0:57 ` Randy Brukardt
0 siblings, 1 reply; 25+ messages in thread
From: AdaMagica @ 2018-02-13 18:31 UTC (permalink / raw)
So taking everything together, and as a generic body assumes the worst, 'Access should be forbidden for generic subprogram parameters.
I cannot find such a rule in the RM. Looks like an oversight?
Is this worth a note in Ada Comment?
As Randy said, generic parameter subprograms should be wrapped in a local subprogram for 'Access - or do I misinterprete him?
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Formal Subprogram Access
2018-02-13 18:31 ` AdaMagica
@ 2018-02-14 0:57 ` Randy Brukardt
0 siblings, 0 replies; 25+ messages in thread
From: Randy Brukardt @ 2018-02-14 0:57 UTC (permalink / raw)
"AdaMagica" <christ-usch.grein@t-online.de> wrote in message
news:1f226b44-eff5-4d54-bacf-07e2303f1b50@googlegroups.com...
> So taking everything together, and as a generic body assumes the worst,
> 'Access should be forbidden for generic subprogram parameters.
>
> I cannot find such a rule in the RM. Looks like an oversight?
I doubt that we could change this at this late date (20+ years) even if it
was an original mistake.
> Is this worth a note in Ada Comment?
Up to you.
> As Randy said, generic parameter subprograms should be wrapped in a local
> subprogram for 'Access - or do I misinterprete him?
No, I said that the *compiler* has to wrap generic actual subprograms. (For
Janus/Ada, we have to do that for all subprograms, because of generic
sharing and the possibility that the parameters change subtypes, or have a
deeper level, or many other things. So this is a non-problem for Janus/Ada
in any case.) So far as I can tell, they have to have an Ada convention, so
they have the be wrapped if the convention is anything else [and that
matters].
Note that the same issue comes up when passing predefined operators
(probably a more realistic case).
Randy.
^ permalink raw reply [flat|nested] 25+ messages in thread