Skip to content

R
riscv-gcc-1
Commit 913eb73e by Arnaud Charlet
Options

[multiple changes] 

2010-09-09  Ben Brosgol  <brosgol@adacore.com>

	* gnat_rm.texi: Minor wordsmithing of section on pragma Ordered.

2010-09-09  Arnaud Charlet  <charlet@adacore.com>

	* par-ch2.adb (Scan_Pragma_Argument_Association): In CodePeer mode,
	do not generate an error for compatibility with legacy code.
	ignored when generating SCIL.
	* sem_attr.adb (Resolve_Attribute): Ignore AI-229 in CodePeer mode.

From-SVN: r164082
parent c90b2058
Showing with 70 additions and 48 deletions
gcc/ada/ChangeLog
2010-09-09 Ben Brosgol <brosgol@adacore.com>
* gnat_rm.texi: Minor wordsmithing of section on pragma Ordered.
2010-09-09 Arnaud Charlet <charlet@adacore.com>
* par-ch2.adb (Scan_Pragma_Argument_Association): In CodePeer mode,
do not generate an error for compatibility with legacy code.
ignored when generating SCIL.
* sem_attr.adb (Resolve_Attribute): Ignore AI-229 in CodePeer mode.
2010-09-09 Thomas Quinot <quinot@adacore.com>
* s-strxdr.adb, gnat_rm.texi, s-stratt-xdr.adb, s-stratt.ads: Rename
......
gcc/ada/gnat_rm.texi
......@@ -3731,6 +3731,7 @@ pragma appears at the start of the file.
@node Pragma Ordered
@unnumberedsec Pragma Ordered
@findex Ordered
@findex pragma @code{Ordered}
@noindent
Syntax:
......@@ -3740,84 +3741,88 @@ pragma Ordered (enumeration_first_subtype_LOCAL_NAME);
@noindent
Most enumeration types are from a conceptual point of view unordered.
For example, if we write:
For example, consider:
@smallexample @c ada
type Color is (Red, Blue, Green, Yellow);
@end smallexample
@noindent
Then Ada semantics says that Blue > Red, and Green > Blue, but really
these relations make no sense, the enumeration type merely specifies
a set of possible colors, and the order is unimportant.
By Ada semantics @code{Blue > Red} and @code{Green > Blue},
but really these relations make no sense; the enumeration type merely
specifies a set of possible colors, and the order is unimportant.
@noindent
For such unordered enumeration types, it is generally a good idea if
clients avoid comparisons (other than equality or inequality), or
explicit ranges. For example, if we have code buried in some client
that says:
For unordered enumeration types, it is generally a good idea if
clients avoid comparisons (other than equality or inequality) and
explicit ranges. (A @emph{client} is a unit where the type is referenced,
other than the unit where the type is declared, its body, and its subunits.)
For example, if code buried in some client says:
@smallexample @c ada
if Current_Color < Yellow ....
if Current_Color in Blue .. Green
if Current_Color < Yellow then ...
if Current_Color in Blue .. Green then ...
@end smallexample
@noindent
Then the code is relying on the order, which is undesriable in this case.
then the client code is relying on the order, which is undesirable.
It makes the code hard to read and creates maintenance difficulties if
entries have to be added to the enumeration type. In cases like this,
we prefer if the code in the client lists the possibilities, or an
appropriate subtype is declared in the parent package, e.g. for the
above case, we might have in the parent package:
entries have to be added to the enumeration type. Instead,
the code in the client should list the possibilities, or an
appropriate subtype should be declared in the unit that declares
the original enumeration type. E.g., the following subtype could
be declared along with the type @code{Color}:
@smallexample @c ada
subtype RBG is Color range Red .. Green;
@end smallexample
@noindent
and then in the client we could write:
and then the client could write:
@smallexample @c ada
if Current_Color in RBG ....
if Current_Color = Blue or Current_Color = Green ...
if Current_Color in RBG then ...
if Current_Color = Blue or Current_Color = Green then ...
@end smallexample
@noindent
However some enumeration types are legitimately ordered from a conceptual
point of view. For example, if you have:
However, some enumeration types are legitimately ordered from a conceptual
point of view. For example, if you declare:
@smallexample @c ada
type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun);
@end smallexample
@noindent
then the ordering imposed by the language is reasonable, and it
is fine for clients to depend on this, writing for example:
then the ordering imposed by the language is reasonable, and
clients can depend on it, writing for example:
@smallexample @c ada
if D in Mon .. Fri then
if D < Wed
if D in Mon .. Fri then ...
if D < Wed then ...
@end smallexample
@noindent
pragma @option{Order} is provided to mark enumeration types that
are conceptually ordered, warning the reader that clients may depend
on the ordering. We provide a pragma to mark enumerations as Ordered
rather than one to mark them as Unordered, since in our experience,
the great majority of enumeration types are conceptually Unordered.
The pragma @option{Ordered} is provided to mark enumeration types that
are conceptually ordered, alerting the reader that clients may depend
on the ordering. GNAT provides a pragma to mark enumerations as ordered
rather than one to mark them as unordered, since in our experience,
the great majority of enumeration types are conceptually unordered.
The types Boolean, Character, Wide_Character, and Wide_Wide_Character
are considered to be ordered types, so there is a pragma Ordered
present in Standard for these types.
The types @code{Boolean}, @code{Character}, @code{Wide_Character},
and @code{Wide_Wide_Character}
are considered to be ordered types, so each is declared with a
pragma @code{Ordered} in package @code{Standard}.
Normally pragma Order serves as only documentation and a guide for
coding standards, but GNAT provides a warning switch -gnatw.u that
Normally pragma @code{Ordered} serves only as documentation and a guide for
coding standards, but GNAT provides a warning switch @option{-gnatw.u} that
requests warnings for inappropriate uses (comparisons and explicit
subranges) for unordered types. If this switch is used, then any
enumeration type not marked with pragma Ordered will be considered
enumeration type not marked with pragma @code{Ordered} will be considered
as unordered, and will generate warnings for inappropriate uses.
For additional information please refer to the description of the
@option{-gnatw.u} switch in the @value{EDITION} User's Guide.
@node Pragma Passive
@unnumberedsec Pragma Passive
@findex Passive
......
gcc/ada/gnat_ugn.texi
......@@ -5613,12 +5613,13 @@ the effect of @option{-gnatwF}).
@emph{Activate warnings on unordered enumeration types.}
@cindex @option{-gnatw.u} (@command{gcc})
This switch causes enumeration types to be considered as conceptually
unordered, unless an explicit pragma Order is given for the type. The
effect is to generate warnings in clients that use explicit comparisons
unordered, unless an explicit pragma @code{Ordered} is given for the type.
The effect is to generate warnings in clients that use explicit comparisons
or subranges, since these constructs both treat objects of the type as
ordered. A client is defined as a unit that is other than the unit in
which the type is declared, or its body or subunits. See description
of pragma Order in the GNAT RM for further details.
ordered. (A @emph{client} is defined as a unit that is other than the unit in
which the type is declared, or its body or subunits.) Please refer to
the description of pragma @code{Ordered} in the
@cite{@value{EDITION} Reference Manual} for further details.
@item -gnatw.U
@emph{Deactivate warnings on unordered enumeration types.}
......
gcc/ada/par-ch2.adb
......@@ -6,7 +6,7 @@
-- --
-- B o d y --
-- --
-- Copyright (C) 1992-2009, Free Software Foundation, Inc. --
-- Copyright (C) 1992-2010, 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- --
......@@ -501,11 +501,13 @@ package body Ch2 is
Id_Present := False;
end if;
if Identifier_Seen and not Id_Present then
Error_Msg_SC
("|pragma argument identifier required here");
Error_Msg_SC
("\since previous argument had identifier (RM 2.8(4))");
if Identifier_Seen and not Id_Present and not CodePeer_Mode then
-- In CodePeer mode, we do not generate an error for compatibility
-- with legacy code, since this error can be safely ignored when
-- generating SCIL.
Error_Msg_SC ("|pragma argument identifier required here");
Error_Msg_SC ("\since previous argument had identifier (RM 2.8(4))");
end if;
if Id_Present then
......
gcc/ada/sem_attr.adb
......@@ -7930,6 +7930,8 @@ package body Sem_Attr is
-- didn't permit the access to be declared in the generic
-- spec, whereas the revised rule does (as long as it's not
-- a formal type).
-- Note that we relax this check in CodePeer mode for
-- compatibility with legacy code.
-- There are a couple of subtleties of the test for applying
-- the check that are worth noting. First, we only apply it
......@@ -7950,6 +7952,7 @@ package body Sem_Attr is
-- been caught by the compilation of the generic unit.
elsif Attr_Id = Attribute_Access
and then not CodePeer_Mode
and then not In_Instance
and then Present (Enclosing_Generic_Unit (Entity (P)))
and then Present (Enclosing_Generic_Body (N))
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment