diff options
Diffstat (limited to 'gcc')
| -rw-r--r-- | gcc/ada/ChangeLog | 11 | ||||
| -rw-r--r-- | gcc/ada/gnat_rm.texi | 79 | ||||
| -rw-r--r-- | gcc/ada/gnat_ugn.texi | 11 | ||||
| -rw-r--r-- | gcc/ada/par-ch2.adb | 14 | ||||
| -rw-r--r-- | gcc/ada/sem_attr.adb | 3 |
5 files changed, 70 insertions, 48 deletions
diff --git a/gcc/ada/ChangeLog b/gcc/ada/ChangeLog index 0d2bd8e..2b99056 100644 --- a/gcc/ada/ChangeLog +++ b/gcc/ada/ChangeLog @@ -1,3 +1,14 @@ +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 diff --git a/gcc/ada/gnat_rm.texi b/gcc/ada/gnat_rm.texi index 0905f1c..09fcb14 100644 --- a/gcc/ada/gnat_rm.texi +++ b/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 diff --git a/gcc/ada/gnat_ugn.texi b/gcc/ada/gnat_ugn.texi index ce4f863..6a0a18d 100644 --- a/gcc/ada/gnat_ugn.texi +++ b/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.} diff --git a/gcc/ada/par-ch2.adb b/gcc/ada/par-ch2.adb index def8ef5..e0bf09d 100644 --- a/gcc/ada/par-ch2.adb +++ b/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 diff --git a/gcc/ada/sem_attr.adb b/gcc/ada/sem_attr.adb index c9f4995..3eccf93 100644 --- a/gcc/ada/sem_attr.adb +++ b/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)) |