Formal Subprogram Access

Formal Subprogram Access

[Jeffrey R. Carter]

Suppose I have something like

procedure Fpa_Proc (P : not null access procedure) is
    -- Empty
begin -- Fpa_Proc
    null;
end Fpa_Proc;

generic -- Fpa_Gen
    with procedure P;
procedure Fpa_Gen;

with Fpa_Proc;

procedure Fpa_Gen is
    -- Empty
begin -- Fpa_Gen
    Fpa_Proc (P => P'Access);
end Fpa_Gen;

(FPA for Formal Procedure Access)

FSF GNAT 7.2.0 rejects Fpa_Gen with the error

fpa_gen.adb:6:19: not subtype conformant with declaration at fpa_proc.adb:1
fpa_gen.adb:6:19: formal subprograms not allowed

which I think is correct. I can change it to have a wrapper procedure:

with Fpa_Proc;

procedure Fpa_Gen is
    procedure New_P is
       -- Empty
    begin -- New_P
       P;
    end New_P;
begin -- Fpa_Gen
    Fpa_Proc (P => New_P'Access);
end Fpa_Gen;

which compiles fine. But to my surprise, I can also rename P:

with Fpa_Proc;

procedure Fpa_Gen is
    procedure New_P renames P;
begin -- Fpa_Gen
    Fpa_Proc (P => New_P'Access);
end Fpa_Gen;

and this also compiles. I would think that if you can't take 'Access of a 
generic formal subprogram, then you shouldn't be able to take 'Access of a 
renaming of a generic formal subprogram. So I'm wondering if this last form is 
legal.

-- 
Jeff Carter
"Gentlemen, you can't fight in here. This is the War Room!"
Dr. Strangelove
30

Re: Formal Subprogram Access

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:p5l6bd$ete$1@dont-email.me...
> Suppose I have something like
>
> procedure Fpa_Proc (P : not null access procedure) is
>    -- Empty
> begin -- Fpa_Proc
>    null;
> end Fpa_Proc;
>
> generic -- Fpa_Gen
>    with procedure P;
> procedure Fpa_Gen;
>
> with Fpa_Proc;
>
> procedure Fpa_Gen is
>    -- Empty
> begin -- Fpa_Gen
>    Fpa_Proc (P => P'Access);
> end Fpa_Gen;
>
> (FPA for Formal Procedure Access)
>
> FSF GNAT 7.2.0 rejects Fpa_Gen with the error
>
> fpa_gen.adb:6:19: not subtype conformant with declaration at 
> fpa_proc.adb:1
> fpa_gen.adb:6:19: formal subprograms not allowed
>
> which I think is correct. I can change it to have a wrapper procedure:

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."

It's possible there is some rule somewhere else that I've forgotten.

> with Fpa_Proc;
>
> procedure Fpa_Gen is
>    procedure New_P is
>       -- Empty
>    begin -- New_P
>       P;
>    end New_P;
> begin -- Fpa_Gen
>    Fpa_Proc (P => New_P'Access);
> end Fpa_Gen;
>
> which compiles fine.

The fact this works makes it rather silly to not allow P directly.

> But to my surprise, I can also rename P:
>
> with Fpa_Proc;
>
> procedure Fpa_Gen is
>    procedure New_P renames P;
> begin -- Fpa_Gen
>    Fpa_Proc (P => New_P'Access);
> end Fpa_Gen;
>
> and this also compiles. I would think that if you can't take 'Access of a 
> generic formal subprogram, then you shouldn't be able to take 'Access of a 
> renaming of a generic formal subprogram. So I'm wondering if this last 
> form is legal.

My 60 second opinion is that all three should be legal. But if that's wrong 
for some subtle reason that I've forgotten, then surely the renames is 
illegal too. (3.10.2(32/5) uses the term "denoted" to ensure that renames 
are ignored for the purposes of enforcing the rule.) I'd definitely report a 
bug to the vendor.

                                Randy.

Re: Formal Subprogram Access

[Jeffrey R. Carter]

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."

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.

-- 
Jeff Carter
"What lazy lout left these wires all over the lawn?"
Poppy
98

Re: Formal Subprogram Access

[AdaMagica]

Am Samstag, 10. Februar 2018 04:03:32 UTC+1 schrieb Randy Brukardt:
> My 60 second opinion is that all three should be legal. But if that's wrong 
> for some subtle reason that I've forgotten, then surely the renames is 
> illegal too. (3.10.2(32/5) uses the term "denoted" to ensure that renames 
> are ignored for the purposes of enforcing the rule.) I'd definitely report a 
> bug to the vendor.

May be that the convention is Intrinsic, so no 'Access allowed. I however found no indication in the RM that generic parameter subprograms are Intrinsic.

Re: Formal Subprogram Access

[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."
>
> 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.)

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.

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.

                                    Randy.

Re: Formal Subprogram Access

[AdaMagica]

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.

Re: Formal Subprogram Access

[Dmitry A. Kazakov]

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

Re: Formal Subprogram Access

[AdaMagica]

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.

Re: Formal Subprogram Access

[Simon Wright]

"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.

Re: Formal Subprogram Access

[Jeffrey R. Carter]

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

Re: Formal Subprogram Access

[AdaMagica]

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?

Re: Formal Subprogram Access

[Randy Brukardt]

"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.

Re: Formal Subprogram Access

[Randy Brukardt]

"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.

Re: Formal Subprogram Access

[Randy Brukardt]

"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.

Re: Formal Subprogram Access

[Dmitry A. Kazakov]

On 14/02/2018 01:47, Randy Brukardt wrote:

> 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. ;-)

Yeah, and when Ada will get subprogram types finally? The only reason 
for 'Access here is to pass a subprogram as an argument!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Formal Subprogram Access

[Jacob Sparre Andersen]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Yeah, and when Ada will get subprogram types finally?

Then we will be able to have two subprograms with the same profile but
of different types.

\o/  (maybe)

Greetings,

Jacob
-- 
"Those who will not reason, are bigots,
 those who cannot, are fools, and
 those who dare not, are slaves."

Re: Formal Subprogram Access

[Dmitry A. Kazakov]

On 14/02/2018 11:01, Jacob Sparre Andersen wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Yeah, and when Ada will get subprogram types finally?
> 
> Then we will be able to have two subprograms with the same profile but
> of different types.

Yes, if subprogram types will be named, no, if only anonymous.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Formal Subprogram Access

[Simon Wright]

"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.

Re: Formal Subprogram Access

[Randy Brukardt]

"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.

Re: Formal Subprogram Access

[Simon Clubley]

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

Re: Formal Subprogram Access

[Simon Wright]

"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

Re: Formal Subprogram Access

[Simon Wright]

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).

Re: Formal Subprogram Access

[Simon Clubley]

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

Re: Formal Subprogram Access

[Randy Brukardt]

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).

Re: Formal Subprogram Access

[Jeffrey R. Carter]

For anyone who is interested, AdaCore has said that it shouldn't have accepted 
'Access on the renaming. It has modified its compiler to add a reference to ARM 
6.3.1(17) to the error msg, and to reject 'Access of a renaming of a generic 
formal subprogram.

-- 
Jeff Carter
"When danger reared its ugly head, he bravely
turned his tail and fled."
Monty Python and the Holy Grail
60