Version 1.4 of si99s/si99-0043-1.txt

Unformatted version of si99s/si99-0043-1.txt version 1.4
Other versions for file si99s/si99-0043-1.txt

!standard 3.12.1          09-03-11 SI99-0043-1/03
!class ramification 09-02-28
!status ARG Approved 10-0-0 09-02-20
!status work item 09-01-21
!status received 08-12-08
!priority Low
!difficulty Easy
!subject Multiple A_Configuration_Compilation_Units are supported
!summary
ASIS allows multiple units to exist in a Context that have Unit_Kinds = A_Configuration_Compilation_Unit.
!question
Consider the A_Pragma Elements that belong to A_Configuration_Compilation unit. They can be obtained as the results of Asis.Elements.Configuration_Pragmas and Asis.Elements.Compilation_Pragmas queries. That is, elements representing configuration pragmas.
The problem is that their enclosing A_Configuration_Compilation unit is not a first-class unit citizen, the current ASIS Standard says that it can be (at most) one unit of this kind in a Context.
If configuration pragmas can be placed into configuration files (as is the case for many implementation), and a compilation may use more then one configuration file, we may have overlapped spans for configuration pragma elements that does not seem to be reasonable and useful.
What is the intent here?
!response
The comment on the definition of A_Configuration_Compilation_Unit says in part: "A Context is not limited to the number of units of A_Configuration_Compilation kind." So the questioner's assertion that there is at most one such unit is incorrect.
The wording is rather convoluted, so we simplify it to make the intention crystal clear.
!wording
Change the comment on A_Configuration_Compilation_Unit in 3.12.1 to:
-- Corresponds to the whole content of a -- compilation with no compilation_unit, -- but possibly containing comments, -- configuration pragmas, or both. -- A Context is may have any number of -- units of A_Configuration_Compilation kind. -- A unit of A_Configuration_Compilation -- does not have a name. This unit -- represents configuration pragmas that -- are "in effect". The only interface that -- returns this unit kind is -- Enclosing_Compilation_Unit when given -- A_Pragma element obtained from Configuration_Pragmas.
!appendix

From: Sergey I. Rybin
Sent: Monday, December  8, 2008  6:06 AM

This message comes form a practical problem reported for the GNAT ASIS
implementation.

Consider the A_Pragma Elements that belong to A_Configuration_Compilation unit.
They can be obtained as the results of Asis.Elements.Configuration_Pragmas and
Asis.Elements.Compilation_Pragmas queries. That is, elements representing
configuration pragmas.

The first question - are these A_Pragma elements Is_Part_Of_Implicit? If they
are not, they should test True with Asis.Text.Is_Text_Available, so
Asis.Text.Element_Span should return some non-nil result for them. But what does
the span mean in this case? (The problem is that their enclosing
A_Configuration_Compilation unit is not a first-class unit citizen, the current
ASIS Standard says that it can be (at most) one unit of this kind in a Context.

And in case of GNAT where configuration pragmas are placed into configuration
files, and a compilation may use more then one configuration file, we may have
overlapped spans for configuration pragma elements that does not seem to be
reasonable and useful.

For me it looks like a gap in the ASIS Standard.

Another problem corresponds to Asis.Compilation_Units.Text_Name query. ASIS does
not forbid A_Configuration_Compilation unit to be an argument for this query,
but in case when configuration pragmas can be located in configuration files,
this query does not make very much sense for A_Configuration_Compilation unit,
because we may have at most one such unit in each ASIS Context, so it is not
clear which file name should be returned. The only reasonable, but useless
possibility is to return a null result.

Next thing. When defining A_Configuration_Compilation value of the Unit_Kind
type, ASIS says:

      --  Corresponds to the whole content of a compilation with no
      --  compilation_unit, but possibly containing comments, configuration
      --  pragmas, or both. Any Context can have at most one unit of
      --  A_Configuration_Compilation kind. A unit of
      --  A_Configuration_Compilation does not have a name. This unit
      --  represents configuration pragmas that are "in effect".

But there is no way to get the list of pragmas from A_Configuration_Compilation
unit. Should we add a structural query that would allow to do this?

And finally, the general suggestion. We may add more flexibility to the way how
the ASIS Standard deals with A_Configuration_Compilation unit. The current
situation may be kept as a minimal requirement, and the ASIS Standard may allow
to have more then one *different* (that is, not Is_Equal)
A_Configuration_Compilation units in the same Context. All these
A_Configuration_Compilation unit should not have a name (in the sense of the
Asis.Compilation_Units.Unit_Full_Name query), but they may be allowed to
generate non-null results when submitted to Asis.Compilation_Units.Text_Name
query. This would make reasonable the span returned for configuration pragmas,
and at the application side it would allow to get a reasonable and useful answer
for the question: "Where does this configuration pragma come from?"

Thoughts?

****************************************************************

From: Tucker Taft
Sent: Tuesday, December  9, 2008 12:51 AM

I don't understand the original ASIS limitation to a single configuration
compilation unit. Certainly our AdaMagic front end allows any number of
compilations consisting only of pragmas.  If GNAT does as well, that means Green
Hills, Aonix, and GNAT all allow this. It seems silly to impose a limitation
that is not required by a number of Ada implementations.

Your suggestion seems reasonable, but perhaps we should go further?

****************************************************************

From: Pascal Leroy
Sent: Wednesday, December 10, 2008  1:03 AM

> Certainly our AdaMagic front end allows any number of compilations
> consisting only of pragmas.  If GNAT does as well,
> that means Green Hills, Aonix, and GNAT all allow this.

As I recall the IBM implementation also allowed any number of compilations
consisting only of pragmas.

****************************************************************

From: Sergey I. Rybin
Sent: Wednesday, December 10, 2008  3:17 AM

> I don't understand the original ASIS limitation to a single
> configuration compilation unit.

I think it may originate from old Ada days when it might be reasonable for old
heavy-weight implementations of compilation libraries. Anyway, now it definitely
looks odd.

> Your suggestion seems reasonable, but perhaps we should go further?

What do you mean?

****************************************************************

From: Sergey I. Rybin
Sent: Wednesday, December 10, 2008  4:33 AM

I've just realised that this issue is not as clear as I thought...

The typical ASIS implementation technique is to use some precompiled stuff as a
basis for representing the ASIS Context. And here we have the consistency
problem. This problem is very similar to what is said in RM 05 10.1.4(5). But
nothing is said about consistency of configuration prarmas!

Consider the following situation: we have

procedure Proc1 is ... end Proc1;
procedure Proc2 is ... end Proc2;

with Proc1, Proc2;
procedure Main is ... end Main;

We put a configuration pragma (let it be, for example 'pragma Ada_95;') into the
configuration file 'gnat.adc' and compile Proc1. Then we edit the configuration
file (replace 'pragma Ada_95;' with 'pragma Ada_05;') and compile Proc2. Then we
remove the configuration file and compile Main.

The situation is quite legal from the point of view of the Ada Standard. So it
should be possible in ASIS to define and to process an ASIS Context based on
these compilations. And what do we have in this Context?

The result of Asis.Elements.Compilation_Pragmas will be:

- 'pragma Ada_95;' if the argument is Proc1;
- 'pragma Ada_05;' if the argument is Proc2;
- empty list if the argument is Main;

So, if we would like to remove the existing limitations for
A_Configuration_Compilation unit, the question is - how many
A_Configuration_Compilation units will we have in this context, and what are
their properties (text names, the content etc...)?

****************************************************************

From: Tucker Taft
Sent: Wednesday, December 10, 2008  1:19 PM

I think you should assume a source-based view of the world, so there is exactly
one set of configuration pragmas in force at any given moment.  They may have
originated from multiple files, but not from multiple versions of the same file.
I don't think we need to handle libraries that are not self-consistent,
including configuration pragmas.

****************************************************************

From: Tucker Taft
Sent: Wednesday, December 10, 2008  1:25 PM

By "going further" I meant that I didn't understand why these multiple
pragma-only compilations shouldn't have a name.  I may not understand the
implications of the distinction you are making in this sentence:

   ...All these A_Configuration_Compilation unit should not
   have a name (in the sense of the Asis.Compilation_Units.Unit_Full_Name
   query), but they may be allowed to generate non-null results when
   submitted to Asis.Compilation_Units.Text_Name query.

Is this saying that these pragma-only compilations don't have Ada
compilation-unit names, but they do have source-code file names?  If so, I guess
that makes sense...

****************************************************************

From: Sergey I. Rybin
Sent: Wednesday, December 10, 2008  1:51 PM

> I think you should assume a source-based view of the world, so there
> is exactly one set of configuration pragmas in force at any given
> moment.

But an ASIS Context is not a snapshot of a *moment*, it is a view of an Ada
compilation environment, that may originate from more then one compilation.

> They may have
> originated from multiple files, but not from multiple versions of the
> same file.

According to the Ada Standard, this is true only for Ada compilation units. The
notion of a configuration *file* is completely outside the semantic of the Ada
language as it is defined by the Standard. And different compilations may be
using different sets of configuration pragmas. Placing these pragmas into this
or that configuration file is just an implementation detail.

> I don't think we need
> to handle libraries that are not self-consistent,

That's true.

> including configuration pragmas.

This is also true, but it does not prevent us from different versions of the
same configuration file to be used to make up the same ASIS Context.

(May be I'm inventing problems here, but I think we have to consider all
possibilities that we may have)

****************************************************************

From: Randy Brukardt
Sent: Wednesday, December 10, 2008  1:57 PM

> I think you should assume a source-based view of the world, so there
> is exactly one set of configuration pragmas in force at any given
> moment.  They may have originated from multiple files, but not from
> multiple versions of the same file.  I don't think we need to handle
> libraries that are not self-consistent, including configuration
> pragmas.

This doesn't make much sense to me. I've always viewed configuration pragmas as
essentially Ada syntax for compiler options. Indeed, that's all they are in
Janus/Ada: a funky way to set default compiler options in the project file.
(It's usually easier to do that via other tools, but of course not as portable.)

Obviously, compiler options can vary for each compilation that makes up a
partition. If you can read such pragmas at all, the only sane way to do it in
Janus/Ada would be to synthesize appropriate pragmas based on the options used
for each unit. There are no global pragmas.

Indeed, for many (most?) projects, global settings don't make sense. If a
project is large enough that parts are developed by separate teams (the ultimate
being a third-party subsystem such as Claw), it doesn't make sense to make
global settings. For instance, Claw is Ada 95 code and (since it has a few
return-by-reference functions) can't be compiled in Ada 2005 mode. A global
setting of Ada 2005 is going to prevent the use of Claw. Similarly, a global
Suppress_All setting would make Claw malfunction.

Surely there are projects created solely in-house with strong management (most
avionics comes to mind) that probably could use global settings. But real-world
project management is more flexible than that. ASIS ought to be able to deal
with the real world capabilities of project management (at least to the extent
that it is visible in Ada, such as configuration pragmas).

****************************************************************

From: Randy Brukardt
Sent: Wednesday, December 10, 2008  2:00 PM

...
> This is also true, but it does not prevent us from different versions
> of the same configuration file to be used to make up the same ASIS
> Context.

Right. Our project management facilities allow each individual compilation to
have its own set of configuration pragmas (represented as compiler options). It
is easy to think of that as different versions of the configuration file
applying to each compilation.

> (May be I'm inventing problems here, but I think we have to consider
> all possibilities that we may have)

No, I think you are on the right track.

****************************************************************

From: Sergey I. Rybin
Sent: Wednesday, December 10, 2008  1:57 PM

> Is this saying that these pragma-only compilations don't have Ada
> compilation-unit names, but they do have source-code file names?  If
> so, I guess that makes sense...

But this is exactly that I have proposed...

In Asis.Compilation_Units we have two queries for obtaining names:

Unit_Full_Name:

--  Returns the string image of the fully expanded Ada name of the given
--  compilation unit.  This may be a simple name ("A") of a root library
--  unit, or an expanded name ("A.B") of a subunit or non-root child unit.
--  An expanded name shall contain the full parent_unit_name as its prefix.

--  Returns a null string only if A_Configuration_Compilation or a
--  Nil_Compilation_Unit is given.

Text_Name:

--  Returns the name of the text, or other structure, that was the source
--  of the compilation that resulted in this Compilation_Unit.  Returns a
--  null string if the unit has a Nil or nonexistent kind, or if the text
--  name is not available for any reason.

In case of a A_Configuration_Compilation, Unit_Full_Name should definitely
return null result, because this query is supposed to return a sting image of
the Ada name, and we do not have an Ada name for A_Configuration_Compilation
unit, but Text_Name (in case of our source-based compilation systems that relay
on the underlying file system) is a perfect means to get the name of the
configuration *file*.

****************************************************************

From: Tucker Taft
Sent: Wednesday, December 10, 2008  2:20 PM

Thanks, that clarifies the situation.
It sounds like Text_Name is the correct way to give the file name.

****************************************************************

From: Tucker Taft
Sent: Wednesday, December 10, 2008  2:36 PM

> This doesn't make much sense to me. I've always viewed configuration
> pragmas as essentially Ada syntax for compiler options. Indeed, that's
> all they are in Janus/Ada: a funky way to set default compiler options
> in the project file. (It's usually easier to do that via other tools,
> but of course not as portable.)

There are two ways of using configuration pragmas, in a file all by themselves,
in which case they apply to everything in the library, or at the head of the
source file, in which case they apply only to that source file.  I can believe
that some compilers have limitations on the first way, in particular the RM
allows them to only support the pragma-only units when the library is empty.

But I don't think ASIS needs to worry about the situation where the pragma-only
units are changed back and forth between different compilations. That really
isn't the model of pragma-only units. Certainly every source file can have its
own set of configuration pragmas, but those are the ones that appear at the head
of the file.

The other ones are the "library" configuration pragmas, and those apply to every
compilation in the library.

I realize the RM says the configuration pragmas in a pragma-only compilation
apply to "all future" compilation units, but I had always presumed that any time
you did a "build," you were effectively recompiling everything in the library
needed for the executable, and thereby whatever was the state of the pragma-only
compilations at that moment determined the pragmas that applied to the
executable.  I can't quite get my head around how any other interpretation would
work for these pragma-only files, since you can't name them in a with clause,
and if you "zipped" up an archive of your sources, you would get exactly one set
of pragma-only files and that is what represents the way your program should be
built.

Our compiler also has the notion of "sublibraries" and these can each have
separate sets of pragma-only compilations, so that gives you some flexibility,
and perhaps other compilers have a similar approach.

The Ada 2005 vs. Ada 95 could be handled with this sublibrary approach, putting
the Ada 95 code in a sublibrary without the Ada 2005 pragma.  Alternatively, you
could handle it by adding a configuration pragma to the head of each file that
didn't want the "default" settings.  But I certainly hope you wouldn't have an
"order dependent" interpretation of pragma-only compilations, because that seems
pretty much doomed to failure upon any kind of automated recompilation or
transfer of sources to someone else.

Am I way off here in my model?

****************************************************************

From: Jean-Pierre Rosen
Sent: Wednesday, December 10, 2008  4:01 PM

> Obviously, compiler options can vary for each compilation that makes
> up a partition. If you can read such pragmas at all, the only sane way
> to do it in Janus/Ada would be to synthesize appropriate pragmas based
> on the options used for each unit. There are no global pragmas.
[...]
> Surely there are projects created solely in-house with strong
> management (most avionics comes to mind) that probably could use
> global settings. But real-world project management is more flexible
> than that. ASIS ought to be able to deal with the real world
> capabilities of project management (at least to the extent that it is
> visible in Ada, such as configuration pragmas).

Wait a minute. We are discussing about removing the restriction of having only
one conceptual unit for all pragmas! If, for your implementation, it makes more
sense to group all options (ignoring how they are provided) into one conceptual
unit, noone is asking you to change your way. But for those implementations that
do have several physical files containing configuration pragmas, it makes little
sense to force the ASIS implementation to conceptually merge them.

For the issue of changing the configuration between compilations, there is
certainly an issue here, but I don't think that removing the restriction would
change the problem.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, December 10, 2008  6:19 PM

I think both Sergey and Tucker have moved beyond that specific issue into the
more general question of whether the ASIS model can map the real world very
well.

After all, if you get really pedantic, neither GNAT nor Janus/Ada have any
support for configuration pragmas in the sense envisioned in the Ada Standard.
Such pragmas don't exist in a separate source file somewhere, but rather as part
of a project file. That being the case, it would make sense for an ASIS
implementation to ignore them completely (it doesn't really define what happens
outside of Ada source files; it assumes that everything that exists in the
program exists in source somewhere, which has been a never-ending source of
problems). But is that really the useful and appropriate thing to do?

> For the issue of changing the configuration between compilations,
> there is certainly an issue here, but I don't think that removing the
> restriction would change the problem.

No, I was responding to Tucker's "should we go further" and Sergey's response to
that and his concern about versioning. If we bother changing these rules at all,
we ought to get them right; just getting rid of a restriction to one unit
doesn't do much at all in that direction.

****************************************************************

From: Tucker Taft
Sent: Wednesday, December 10, 2008  8:25 PM

> After all, if you get really pedantic, neither GNAT nor Janus/Ada have
> any support for configuration pragmas in the sense envisioned in the
> Ada Standard. Such pragmas don't exist in a separate source file
> somewhere, but rather as part of a project file.

My sense is that GNAT supports having configuration pragmas in a separate file.
It used to always be called "gnat.adc." It seems like it can be named anything
now, with the name specified in the project file with a command:

    for Global_Configuration_Pragmas use "config_prag.adc";

I'm not sure whether you can have multiple config-pragma files for a single
project, but you can have multiple projects as part of a single build.

> ...
> No, I was responding to Tucker's "should we go further" and Sergey's
> response to that and his concern about versioning. If we bother
> changing these rules at all, we ought to get them right; just getting
> rid of a restriction to one unit doesn't do much at all in that direction.

I am not an expert on how ASIS deals with inconsistency and versioning in
general, but I don't see the need to make configuration pragmas a big special
case.  I really can't quite imagine how one would deal with inconsistency in
ASIS, and it seems not terribly interesting, except perhaps to report that
"things are inconsistent."  Certainly most of the time when you do static
analysis, you will want to do it on an internally consistent library.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, December 10, 2008  9:40 PM

> My sense is that GNAT supports having configuration pragmas in a
> separate file.  It used to always be called "gnat.adc."

My recollection (perhaps wrong) is that the Gnat.Adc file contained stuff other
than just configuration pragmas. That makes it more like a global project file
than a configuration pragma file.

>  > ...
> > No, I was responding to Tucker's "should we go further" and Sergey's
> > response to that and his concern about versioning. If we bother
> > changing these rules at all, we ought to get them right; just
> > getting rid of a restriction to one unit doesn't do much at all in
> > that direction.
>
> I am not an expert on how ASIS deals with inconsistency and versioning
> in general, but I don't see the need to make configuration pragmas a
> big special case.  I really can't quite imagine how one would deal
> with inconsistency in ASIS, and it seems not terribly interesting,
> except perhaps to report that "things are inconsistent."  Certainly
> most of the time when you do static analysis, you will want to do it
> on an internally consistent library.

Because this *is* not a case of inconsistency. This is stuff that the user can
manually override, and in many cases it has nothing to do with the canonical
semantics of the Ada code. For instance, pragma Suppress just gives a permission
to omit checks. Similarly with Restrictions pragmas -- allowing a violation of
the restriction in some unit doesn't make any difference to the semantics of the
program. (It might cause trouble with a restricted runtime, but that's doesn't
seem very interesting for semantic analysis.)

We don't currently store *any* pragmas in the program library; they're
translated into compiler option settings in the project file. And we don't
consider the project file to be part of the library; Janus/Ada has a mode where
it will work just fine without such a file. In that case, there is no global
context at all; everything depends solely on the compiler options and
environment. So I don't see any inconsistency here; the question is whether we
could report the interesting information about the settings for each unit
through ASIS, or whether we simply have to report "no configuration pragmas"
everywhere. (That's surely simpler, but not very useful!)

I agree that the scenario that Sergey posited sounds a little weird. Let me
posit one that makes much more sense to me.

Imagine a project that includes a configuration pragma for pragma
Suppress(All_Checks); This will have the effect of including the /YR option in
all units currently in the project and also in any units added to the project in
the future. Further imagine that the user has manually removed the /YR option
from unit B and then compiled the project.

If an ASIS program then analyzes unit B from this project, does it see a pragma
Suppress(All_Checks);??? If it does, it is actively misleading (because the unit
B was compiled without such a pragma), but if it does not, then we effectively
have Sergey's versioning problem. (He just described it in Ada language terms of
changing the configuration pragmas rather than compiler options.)

Now, it surely is the case that the case postulated here is
implementation-defined; manually removing the option surely is not contemplated
by the Ada standard. But this is a possibility in the real world, and it's a
commonly used capability (to give a few units special compilation settings for
one reason or another). Indeed, it is easy to imagine a project file that
allowed applying one set of configuration pragmas to one unit and automatically
applying a different set to other units - that's essentially what manually
changing the options does.) The idea that there is a single set of global
settings used by everything is archaic at best.

Shouldn't ASIS be able to handle such cases? Obviously, it cannot say
definitively what it means to have different configuration pragmas for different
units, but it surely needs implementation-defined wording somewhere in order to
deal with issues like this. Otherwise, ASIS only will work for programs that are
*developed* purely according to the Ada Standard, and such programs are pretty
rare in practice. (I've never written one outside of ACATS tests, and even there
I've used varying sets of options.)

****************************************************************

From: Tucker Taft
Sent: Wednesday, December 10, 2008  10:50 PM

I see no problem in your pretending that each file has its own set of
configuration pragmas at the head. You might have to give a bogus source
position, but ASIS seems somewhat used to that kind of funny business.

But it seems clear to me that you don't really support the pragma-only
compilations that the RM talks about. That's fine by me, since you provide other
ways to provide defaults, override them, etc.  But I don't think you should try
to shoe-horn your model into the ASIS support for *global* pragma-only
compilations, since you really don't have that.  Instead, you support setting an
overridable default, which is somewhat different from the effect of a global,
pragma-only file.  It seems best for your implementation to always report the
configuration pragmas as though they appeared at the head of each source file,
and not imply there are any library-wide configuration pragmas.

****************************************************************

From: Vincent Celier
Sent: Wednesday, December 10, 2008  10:42 PM

> My recollection (perhaps wrong) is that the Gnat.Adc file contained
> stuff other than just configuration pragmas. That makes it more like a
> global project file than a configuration pragma file.
>

Your recollection is indeed wrong: gnat.adc and the other configuration pragmas
files specify with switch -gnatec= can only contain configuration pragmas.

****************************************************************

From: Pascal Leroy
Sent: Thursday, December 11, 2008  12:16 AM

> But I don't think ASIS needs to worry about the
> situation where the pragma-only units are changed
> back and forth between different compilations.
> That really isn't the model of pragma-only units.
>
> The other ones are the "library" configuration
> pragmas, and those apply to every compilation
> in the library.
>
> I realize the RM says the configuration pragmas
> in a pragma-only compilation apply to "all future"
> compilation units, but I had always presumed that
> any time you did a "build," you were effectively
> recompiling everything in the library needed for
> the executable, and thereby whatever was the state
> of the pragma-only compilations at that moment
> determined the pragmas that applied to the
> executable.

I don't think that this theory aligns with the IBM implementation, and I believe
that Sergey's scenario is valid.

In Apex, each view (aka library) can have its own pragmas-only file (named
pragma.1.ada).  When a (normal) unit is compiled, it uses the configuration
pragmas present in all the accessible pragma.1.ada files.  These files are
subject to incremental compilation, so they can be freely edited and that may or
may not cause recompilation.  For instance, adding a restriction causes
recompilation of the units where this restriction would have been violated, but
some other configuration pragmas have no effect until prelink time.  At prelink
time, a check is made that all the configuration pragmas used to compile all the
units in the closure are consistent (note: not identical, consistent).

Implementation-wise, each Diana tree contains a summary of the configuration
pragmas that were in effect when it was created.  I assume that ASIS would use
this information to synthetize a snapshot of the pragmas that were in effect
when this unit was compiled.  The effect would be exactly what Sergey described.

****************************************************************

From: Tucker Taft
Sent: Thursday, December 11, 2008  2:24 AM

It seems that from what you say, however, you could always use the current state
of pragma.1.ada and you would get an answer that is consistent with the state of
the library. I don't see the need to delve into the history, since clearly upon
recompilation from scratch they will all end up with the set represented by the
pragma.1.ada.

This seems no different than your general incremental compilation approach, where you can probably determine the state of other units at the time you did the original compile, but that is somewhat irrelevant at the time of the ASIS analysis.
Presuming that everything is consistent, then what you care about is the current state of the units, not their state at the moment of compile of some dependent unit.

****************************************************************

From: Sergey I. Rybin
Sent: Thursday, December 11, 2008  3:45 AM

Let me try to summarize where we are with this issue.

1. We have agreed that the current ASIS approach used for representing
   configuration pragmas is too restrictive at least for GNAT and AdaMagic
   compilers (and probably for IBM Ada compiler as well).

2. An ASIS application may want to now where the given configuration pragma
   comes from, and there are technical possibilities for these Ada compilers
   to compute the answer in terms of the (names) of (configuration) files.

3. The notion of a configuration file is completely outside the Ada Standard,
   it is just a common implementation detail of the Ada compilers under
   consideration. We may take benefits from the fact that this detail is
   in common for most of the Ada compilers we have now, but we have to
   be careful when adding the interface to this common detail at the
   ASIS Standard level.

4. It is a normal situation when one use different sets of configuration
   pragmas to compile different units belonging to the same Ada compilation
   environment (in case of GNAT, you may specify individual set of
   compilation options for any unit from you project, and these options
   may include pointers to configuration files to be used when compiling
   a unit). So, having more then one A_Configuration_Compilation unit in
   an ASIS Context is also a normal situation, and I do not see any
   problem with this (except for ASIS implementation problems :(   )

5. Everything looks reasonable and implementable for a typical reasonable
   set of units that are compiled in some reasonable ways. But there are
   some corner cases, that may look like some hacker ways of using
   the underlying compilation system, but that are perfectly legal in
   Ada sense. The question is - what do we want to do with these corner
   cases at the level of the ASIS Standard?

   The example of such a corner case was in my previous message: someone
   creates Ada sources Ada_Unit_1 and Ada_Unit_2 and a configuration file
   Ada_Config_File, compiles Ada_Unit_1 with Ada_Config_File, then edits
   Ada_Config_File and compiles Ada_Unit_2 with the modified version
   of Ada_Config_File. It is perfectly legal to put these units in the same
   Ada compilation environment, so ASIS should be able to process a Context
   based on the results of these compilations. So the question is -
   how many A_Configuration_Compilation units will we have in this Context,
   and what should be their properties.

   I would suggest the following - in this case we have two units of
   A_Configuration_Compilation kind, for both of them Text_Name returns
   the same "Ada_Config_File" string, they are different (Is_Equal is
   False for them), and we may use
   Asis.Compilation_Units.Times.Time_Of_Last_Update to make the difference
   between these two versions of configuration files.

****************************************************************

Questions? Ask the ACAA Technical Agent