[multiple changes]

2012-06-12  Arnaud Charlet  <charlet@adacore.com>

	* xref_lib.adb (Get_Full_Type): Add support for 'G'.

2012-06-12  Tristan Gingold  <gingold@adacore.com>

	* a-exexpr-gcc.adb (Unwind_Exception): Add 4 more private fields.

2012-06-12  Fedor Rybin  <frybin@adacore.com>

	* gnat_ugn.texi: Update doc on gnattest.

2012-06-12  Robert Dewar  <dewar@adacore.com>

	* sem_ch12.adb: Add comments.

From-SVN: r188453

gcc/ada/ChangeLog

+2012-06-12  Arnaud Charlet  <charlet@adacore.com>
+
+	* xref_lib.adb (Get_Full_Type): Add support for 'G'.
+
+2012-06-12  Tristan Gingold  <gingold@adacore.com>
+
+	* a-exexpr-gcc.adb (Unwind_Exception): Add 4 more private fields.
+
+2012-06-12  Fedor Rybin  <frybin@adacore.com>
+
+	* gnat_ugn.texi: Update doc on gnattest.
+
+2012-06-12  Robert Dewar  <dewar@adacore.com>
+
+	* sem_ch12.adb: Add comments.
+
 2012-06-12  Robert Dewar  <dewar@adacore.com>
 
 	* switch-c.adb, inline.adb, usage.adb, opt.ads: Minor reformatting.

gcc/ada/a-exexpr-gcc.adb

@@ -6,7 +6,7 @@
 --                                                                          --
 --                                 B o d y                                  --
 --                                                                          --
---          Copyright (C) 1992-2011, Free Software Foundation, Inc.         --
+--          Copyright (C) 1992-2012, Free Software Foundation, Inc.         --
 --                                                                          --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -108,6 +108,14 @@ package body Exception_Propagation is
       Cleanup  : System.Address;
       Private1 : Unwind_Word;
       Private2 : Unwind_Word;
+
+      --  Usual exception structure has only 2 private fields, but the SEH
+      --  one has 6.  To avoid makeing this file more complex, we use 6 fields
+      --  on all platforms, wasting a few bytes on some.
+      Private3 : Unwind_Word;
+      Private4 : Unwind_Word;
+      Private5 : Unwind_Word;
+      Private6 : Unwind_Word;
    end record;
    pragma Convention (C, Unwind_Exception);
    --  Map the GCC struct used for exception handling
@@ -475,8 +483,7 @@ package body Exception_Propagation is
         new GNAT_GCC_Exception'
           (Header     => (Class => GNAT_Exception_Class,
                           Cleanup => GNAT_GCC_Exception_Cleanup'Address,
-                          Private1 => 0,
-                          Private2 => 0),
+                          others => 0),
            Occurrence => Excep.all);
 
       --  Propagate it

gcc/ada/gnat_ugn.texi

@@ -18068,24 +18068,24 @@ Verbose mode: generate version information.
 @findex gnattest
 
 @noindent
-@command{gnattest} is an ASIS-based utility that creates unit-test stubs
+@command{gnattest} is an ASIS-based utility that creates unit-test skeletons
 as well as a test driver infrastructure (harness). @command{gnattest} creates
-a stub for each visible subprogram in the packages under consideration when
+a skeleton for each visible subprogram in the packages under consideration when
 they do not exist already.
 
 In order to process source files from a project, @command{gnattest} has to
-semantically analyze the sources. Therefore, test stubs can only be
+semantically analyze the sources. Therefore, test skeletons can only be
 generated for legal Ada units. If a unit is dependent on other units,
 those units should be among the source files of the project or of other projects
 imported by this one.
 
-Generated stubs and harnesses are based on the AUnit testing framework. AUnit is
-an Ada adaptation of the xxxUnit testing frameworks, similar to JUnit for Java
-or CppUnit for C++. While it is advised that gnattest users read the AUnit
-manual, deep knowledge of AUnit is not necessary for using gnattest. For correct
-operation of @command{gnattest}, AUnit should be installed and aunit.gpr must be
-on the project path. This happens automatically when Aunit is installed at its
-default location.
+Generated skeletons and harnesses are based on the AUnit testing framework.
+AUnit is an Ada adaptation of the xxxUnit testing frameworks, similar to JUnit
+for Java or CppUnit for C++. While it is advised that gnattest users read
+the AUnit manual, deep knowledge of AUnit is not necessary for using gnattest.
+For correct operation of @command{gnattest}, AUnit should be installed and
+aunit.gpr must be on the project path. This happens automatically when Aunit
+is installed at its default location.
 @menu
 * Running gnattest::
 * Switches for gnattest::
@@ -18124,11 +18124,6 @@ specifies the project defining the location of source files. When no
 file names are provided on the command line, all sources in the project
 are used as input. This switch is required.
 
-@item --harness-dir=dirname
-specifies the directory that will hold the harness packages and project file
-for the test driver. The harness directory should be specified either by that
-switch or by the corresponding attribute in the project file.
-
 @item filename
 is the name of the source file containing the library unit package declaration
 for which a test package will be created. The file name may be given with a
@@ -18137,7 +18132,7 @@ path.
 @item @samp{@var{gcc_switches}}
 is a list of switches for
 @command{gcc}. These switches will be passed on to all compiler invocations
-made by @command{gnatstub} to generate a set of ASIS trees. Here you can provide
+made by @command{gnattest} to generate a set of ASIS trees. Here you can provide
 @option{^-I^/INCLUDE_DIRS=^} switches to form the source search path,
 use the @option{-gnatec} switch to set the configuration file,
 use the @option{-gnat05} switch if sources should be compiled in
@@ -18152,13 +18147,13 @@ is an optional sequence of switches as described in the next section.
 
 @itemize @bullet
 @item automatic harness:
-the harness code, which is located either in the harness-dir as specified on
-the command line or in the project file. All of this code is generated
-completely automatically and can be destroyed and regenerated at will. It is not
-recommended to modify this code manually, since it could easily be overridden
-by mistake. The entry point in the harness code is the project file named
-@command{test_driver.gpr}. Tests can be compiled and run using a command
-such as:
+the harness code, which is located by default in "gnattest/harness" directory
+that is created in the object directory of corresponding project file. All of
+this code is generated completely automatically and can be destroyed and
+regenerated at will. It is not recommended to modify this code manually, since
+it could easily be overridden by mistake. The entry point in the harness code is
+the project file named @command{test_driver.gpr}. Tests can be compiled and run
+using a command such as:
 
 @smallexample
 gnatmake -P<harness-dir>/test_driver
@@ -18168,18 +18163,17 @@ test_runner
 Note that you might need to specify the necessary values of scenario variables
 when you are not using the AUnit defaults.
 
-@item actual unit test stubs:
-a test stub for each visible subprogram is created in a separate file, if it
+@item actual unit test skeletons:
+a test skeleton for each visible subprogram is created in a separate file, if it
 doesn't exist already. By default, those separate test files are located in a
-"tests" directory that is created in the directory containing the source file
-itself. If it is not appropriate to create the tests in subdirectories of the
-source, option @option{--separate-root} can be used. For example, if a source
-file my_unit.ads in directory src contains a visible subprogram Proc, then
-the corresponding unit test will be found in file
-src/tests/my_unit-tests-proc_<code>.adb. <code> is a signature encoding used to
-differentiate test names in case of overloading.
-
-Note that if the project already has both my_unit.ads and my_unit-tests.ads,
+"gnattest/tests" directory that is created in the object directory of
+corresponding project file. For example, if a source file my_unit.ads in
+directory src contains a visible subprogram Proc, then the corresponding unit
+test will be found in file src/tests/my_unit-test_data-tests-proc_<code>.adb.
+<code> is a signature encoding used to differentiate test names in case of
+overloading.
+
+Note that if the project already has both my_unit.ads and my_unit-test_data.ads,
 this will cause a name conflict with the generated test package.
 @end itemize
 
@@ -18215,30 +18209,48 @@ Suppresses noncritical output messages.
 @cindex @option{-v} (@command{gnattest})
 Verbose mode: generates version information.
 
-@item --liskov
-@cindex @option{--liskov} (@command{gnattest})
-Enables Liskov verification: run all tests from all parents in order
+@item --validate-type-extensions
+@cindex @option{--validate-type-extensions} (@command{gnattest})
+Enables substitution check: run all tests from all parents in order
 to check substitutability.
 
-@item --stub-default=@var{val}
-@cindex @option{--stub-default} (@command{gnattest})
-Specifies the default behavior of generated stubs. @var{val} can be either
+@item --skeleton-default=@var{val}
+@cindex @option{--skeleton-default} (@command{gnattest})
+Specifies the default behavior of generated skeletons. @var{val} can be either
 "fail" or "pass", "fail" being the default.
 
-@item --separate-root=@var{dirname}
-@cindex @option{--separate-root} (@command{gnattest})
+@item --tests-root=@var{dirname}
+@cindex @option{--tests-root} (@command{gnattest})
 The directory hierarchy of tested sources is recreated in the @var{dirname}
 directory, and test packages are placed in corresponding directories.
+If the @var{dirname} is a relative path, it is considered relative to the object
+directory of the project file. When all sources from all projects are taken
+recursively from all projects, directory hierarchies of tested sources are
+recreated for each project in their object directories and test packages are
+placed accordingly.
 
 @item --subdir=@var{dirname}
 @cindex @option{--subdir} (@command{gnattest})
-Test packages are placed in subdirectories. This is the default output mode
-since it does not require any additional input from the user. Subdirectories
-named "tests" will be created by default.
+Test packages are placed in subdirectories.
+
+@item --tests-dir=@var{dirname}
+@cindex @option{--tests-dir} (@command{gnattest})
+All test packages are placed in the @var{dirname} directory.
+If the @var{dirname} is a relative path, it is considered relative to the object
+directory of the project file. When all sources from all projects are taken
+recursively from all projects, @var{dirname} directories are created for each
+project in their object directories and test packages are placed accordingly.
+
+@item --harness-dir=@var{dirname}
+@cindex @option{--harness-dir} (@command{gnattest})
+specifies the directory that will hold the harness packages and project file
+for the test driver. If the @var{dirname} is a relative path, it is considered
+relative to the object directory of the project file.
 
 @end table
 
-@option{--separate_root} and @option{--subdir} switches are mutually exclusive.
+@option{--tests_root}, @option{--subdir} and @option{--tests-dir} switches are
+mutually exclusive.
 
 @node Project Attributes for gnattest
 @section Project Attributes for @command{gnattest}
@@ -18251,13 +18263,17 @@ package gnattest. Here is the list of attributes:
 
 @itemize @bullet
 
-@item Separate_Stub_Root
-is used to select the same output mode as with the --separate-root option.
-This attribute cannot be used together with Stub_Subdir.
+@item Tests_Root
+is used to select the same output mode as with the --tests-root option.
+This attribute cannot be used together with Subdir or Tests_Dir.
 
-@item Stub_Subdir
+@item Subdir
 is used to select the same output mode as with the --subdir option.
-This attribute cannot be used together with Separate_Stub_Root.
+This attribute cannot be used together with Tests_Root or Tests_Dir.
+
+@item Tests_Dir
+is used to select the same output mode as with the --tests-dir option.
+This attribute cannot be used together with Subdir or Tests_Root.
 
 @item Harness_Dir
 is used to specify the directory in which to place harness packages and project
@@ -18267,9 +18283,9 @@ file for the test driver, otherwise specified by --harness-dir.
 is used to specify the project file, otherwise given by
 --additional-tests switch.
 
-@item Stubs_Default
-is used to specify the default behaviour of test stubs, otherwise
-specified by --stub-default option. The value of this attribute
+@item Skeletons_Default
+is used to specify the default behaviour of test skeletons, otherwise
+specified by --skeleton-default option. The value of this attribute
 should be either "pass" or "fail".
 
 @end itemize
@@ -18309,16 +18325,16 @@ Since no special output option was specified, the test package Simple.Tests
 is located in:
 
 @smallexample
-<install_prefix>/share/examples/gnattest/simple/src/tests
+<install_prefix>/share/examples/gnattest/simple/obj/gnattest/tests
 @end smallexample
 
 For each package containing visible subprograms, a child test package is
 generated. It contains one test routine per tested subprogram. Each
 declaration of a test subprogram has a comment specifying which tested
 subprogram it corresponds to. All of the test routines have separate bodies.
-The test routine located at simple-tests-test_inc_5eaee3.adb contains a single
-statement: a call to procedure Assert. It has two arguments: the Boolean
-expression we want to check and the diagnosis message to display if
+The test routine located at simple-test_data-tests-test_inc_5eaee3.adb contains
+a single statement: a call to procedure Assert. It has two arguments:
+the Boolean expression we want to check and the diagnosis message to display if
 the condition is false.
 
 That is where actual testing code should be written after a proper setup.
@@ -18336,22 +18352,24 @@ is reported.
 
 @noindent
 
-Besides test routines themselves, each test package has an inner package
-Env_Mgmt that has two procedures: User_Set_Up and User_Tear_Down.
-User_Set_Up is called before each test routine of the package and
-User_Tear_Down is called after each test routine. Those two procedures can
-be used to perform necessary initialization and finalization,
-memory allocation, etc.
+Besides test routines themselves, each test package has a parent package
+Test_Data that has two procedures: Set_Up and Tear_Down. This package is never
+overwritten by the tool. Set_Up is called before each test routine of the
+package and Tear_Down is called after each test routine. Those two procedures
+can be used to perform necessary initialization and finalization,
+memory allocation, etc. Test type declared in Test_Data package is parent type
+for the test type of test package and can have user-defined components whose
+values can be set by Set_Up routine and used in test routines afterwards.
 
 @node Regenerating Tests
 @section Regenerating Tests
 
 @noindent
 
-Bodies of test routines and env_mgmt packages are never overridden after they
+Bodies of test routines and test_data packages are never overridden after they
 have been created once. As long as the name of the subprogram, full expanded Ada
 names, and the order of its parameters is the same, the old test routine will
-fit in its place and no test stub will be generated for the subprogram.
+fit in its place and no test skeleton will be generated for the subprogram.
 
 This can be demonstrated with the previous example. By uncommenting declaration
 and body of function Dec in simple.ads and simple.adb, running
@@ -18364,10 +18382,10 @@ gprbuild -Ptest_driver
 test_runner
 @end smallexample
 
-the old test is not replaced with a stub, nor is it lost, but a new test stub is
-created for function Dec.
+the old test is not replaced with a stub, nor is it lost, but a new test
+skeleton is created for function Dec.
 
-The only way of regenerating tests stubs is to remove the previously created
+The only way of regenerating tests skeletons is to remove the previously created
 tests.
 
 @node Default Test Behavior
@@ -18380,8 +18398,9 @@ either count them all as failed (this is useful to see which tests are still
 left to implement) or as passed (to sort out unimplemented ones from those
 actually failing).
 
-The test driver accepts a switch to specify this behavior: --stub-default=val,
-where val is either "pass" or "fail" (exactly as for @command{gnattest}).
+The test driver accepts a switch to specify this behavior:
+--skeleton-default=val, where val is either "pass" or "fail" (exactly as for
+@command{gnattest}).
 
 The default behavior of the test driver is set with the same switch
 as passed to gnattest when generating the test driver.
@@ -18399,11 +18418,11 @@ makes both tests pass, even the unimplemented one.
 
 @noindent
 
-Creation of test stubs for primitive operations of tagged types entails a number
-of features. Test routines for all primitives of a given tagged type are
-placed in a separate child package named according to the tagged type. For
+Creation of test skeletons for primitive operations of tagged types entails
+a number of features. Test routines for all primitives of a given tagged type
+are placed in a separate child package named according to the tagged type. For
 example, if you have tagged type T in package P, all tests for primitives
-of T will be in P.T_Tests.
+of T will be in P.T_Test_Data.T_Tests.
 
 Consider running gnattest on the second example (note: actual tests for this
 example already exist, so there's no need to worry if the tool reports that
@@ -18415,10 +18434,10 @@ gnattest --harness-dir=driver -Ptagged_rec.gpr
 @end smallexample
 
 Taking a closer look at the test type declared in the test package
-Speed1.Controller_Tests is necessary. It is declared in:
+Speed1.Controller_Test_Data is necessary. It is declared in:
 
 @smallexample
-<install_prefix>/share/examples/gnattest/tagged_rec/src/tests
+<install_prefix>/share/examples/gnattest/tagged_rec/obj/gnattest/tests
 @end smallexample
 
 Test types are direct or indirect descendants of
@@ -18433,10 +18452,10 @@ package Speed2.Auto_Controller, you will see that Test_Auto_Controller
 actually derives from Test_Controller rather than AUnit type Test_Fixture.
 Thus, test types mirror the hierarchy of tested types.
 
-The User_Set_Up procedure of Env_Mgmt package corresponding to a test package
+The Set_Up procedure of Test_Data package corresponding to a test package
 of primitive operations of type T assigns to Fixture a reference to an
 object of that exact type T. Notice, however, that if the tagged type has
-discriminants, the User_Set_Up only has a commented template for setting
+discriminants, the Set_Up only has a commented template for setting
 up the fixture, since filling the discriminant with actual value is up
 to the user.
 
@@ -18468,26 +18487,29 @@ derived type.
 
 @noindent
 
-Tagged Types Substitutability Testing is a way of verifying the Liskov
-substitution principle (LSP) by testing. LSP is a principle stating that if
+Tagged Types Substitutability Testing is a way of verifying the global type
+consistency by testing. Global type consistency is a principle stating that if
 S is a subtype of T (in Ada, S is a derived type of tagged type T),
 then objects of type T may be replaced with objects of type S (that is,
 objects of type S may be substituted for objects of type T), without
 altering any of the desirable properties of the program. When the properties
 of the program are expressed in the form of subprogram preconditions and
-postconditions (let's call them pre and post), LSP is formulated as relations
-between the pre and post of primitive operations and the pre and post of their
-derived operations. The pre of a derived operation should not be stronger than
-the original pre, and the post of the derived operation should not be weaker
-than the original post. Those relations ensure that verifying if a dispatching
-call is safe can be done just by using the pre and post of the root operation.
-
-Verifying LSP by testing consists of running all the unit tests associated with
-the primitives of a given tagged type with objects of its derived types.
+postconditions (let's call them pre and post), the principle is formulated as
+relations between the pre and post of primitive operations and the pre and post
+of their derived operations. The pre of a derived operation should not be
+stronger than the original pre, and the post of the derived operation should
+not be weaker than the original post. Those relations ensure that verifying if
+a dispatching call is safe can be done just by using the pre and post of the
+root operation.
+
+Verifying global type consistency by testing consists of running all the unit
+tests associated with the primitives of a given tagged type with objects of its
+derived types.
 
 In the example used in the previous section, there was clearly a violation of
-LSP. The overriding primitive Adjust_Speed in package Speed2 removes the
-functionality of the overridden primitive and thus doesn't respect LSP.
+type consistency. The overriding primitive Adjust_Speed in package Speed2
+removes the functionality of the overridden primitive and thus doesn't respect
+the consistency principle.
 Gnattest has a special option to run overridden parent tests against objects
 of the type which have overriding primitives:
 
@@ -18501,12 +18523,17 @@ test_runner
 While all the tests pass by themselves, the parent test for Adjust_Speed fails
 against objects of the derived type.
 
+Non-overridden tests are already inherited for derived test types, so the
+--validate-type-extensions enables the application of overriden tests to objects
+of derived types.
+
 @node Testing with Contracts
 @section Testing with Contracts
 
 @noindent
 
-@command{gnattest} supports pragmas Precondition, Postcondition, and Test_Case.
+@command{gnattest} supports pragmas Precondition, Postcondition, and Test_Case,
+as well as corresponding aspects.
 Test routines are generated, one per each Test_Case associated with a tested
 subprogram. Those test routines have special wrappers for tested functions
 that have composition of pre- and postcondition of the subprogram with
@@ -18615,7 +18642,6 @@ The tool currently does not support following features:
 @itemize @bullet
 @item generic tests for generic packages and package instantiations
 @item tests for protected subprograms and entries
-@item aspects Precondition, Postcondition, and Test_Case
 @item generating test packages for code that is not conformant with ada 2005
 
 @end itemize

gcc/ada/sem_ch12.adb

@@ -9449,7 +9449,8 @@ package body Sem_Ch12 is
                Has_Untagged_Inc := True;
             end if;
 
-            --  Add comments for following code???
+            --  This is a temporary implementation. Most of this code has
+            --  to be moved to sem_ch8, and will be commented then ???
 
             if Is_Entity_Name (Actual)
               and then not Is_Overloaded (Actual)

gcc/ada/xref_lib.adb

@@ -538,6 +538,7 @@ package body Xref_Lib is
 
          when 'h' => return "interface";
          when 'g' => return "macro";
+         when 'G' => return "function macro";
          when 'J' => return "class";
          when 'K' => return "package";
          when 'k' => return "generic package";