OpenE2K
/
gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

[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
This commit is contained in:
Arnaud Charlet 2012-06-12 14:32:29 +02:00
parent 2137e8a657
commit fc7d1319f5
5 changed files with 147 additions and 96 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
gcc/ada/ChangeLog
View File

@ -1,3 +1,19 @@
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.

13
gcc/ada/a-exexpr-gcc.adb
View File

@ -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

210
gcc/ada/gnat_ugn.texi
View File

@ -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.
"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-tests.ads,
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.
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 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.
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

3
gcc/ada/sem_ch12.adb
View File

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

1
gcc/ada/xref_lib.adb
View File

@ -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";