+2010-09-10 Thomas Quinot <quinot@adacore.com>
+
+ * scos.ads: Add comments.
+
+2010-09-10 Vincent Celier <celier@adacore.com>
+
+ * gnatcmd.adb (Get_Closure): Remove useless invocation of Close.
+
+2010-09-10 Hristian Kirtchev <kirtchev@adacore.com>
+
+ * exp_ch7.adb, exp_ch6.adb (Expand_Call): Establish a transient scope
+ for a controlled build-in-place function call which appears in an
+ anonymous context. The transient scope ensures that the intermediate
+ function result is cleaned up after the master is left.
+ (Make_Build_In_Place_Call_In_Anonymous_Context): Remove the creation
+ of the transient scope. This is now done in Exand_Call which covers
+ additional cases other than secondary stack release.
+
+2010-09-10 Arnaud Charlet <charlet@adacore.com>
+
+ * sem.adb (Do_Unit_And_Dependents): Add guard.
+
+2010-09-10 Robert Dewar <dewar@adacore.com>
+
+ * exp_ch5.adb: Update comments.
+ * exp_dist.adb: Minor reformatting.
+
2010-09-10 Robert Dewar <dewar@adacore.com>
* sem_ch13.adb (Check_Record_Representation_Clause): Implement record
S_Or_P : Name_Id;
function Build_Step (J : Nat) return Node_Id;
+ -- The increment step for the index of the right-hand side is written
+ -- as an attribute reference (Succ or Pred). This function returns
+ -- the corresponding node, which is placed at the end of theloop body.
+
-- Note that on the last iteration of the loop, the index is increased
- -- past the upper bound. This is consistent with the C semantics of the
- -- back-end, where such an off-by-one value on a dead variable is OK.
- -- However, in CodePeer mode this leads to spurious warnings, and thus
- -- we place a guard around the attribute reference.
+ -- (or decreased) past the corresponding bound. This is consistent with
+ -- the C semantics of the back-end, where such an off-by-one value on a
+ -- dead index variable is OK. However, in CodePeer mode this leads to
+ -- spurious warnings, and thus we place a guard around the attribute
+ -- reference. For obvious reasons we only do this for CodePeer.
----------------
-- Build_Step --
-- To prevent a double attachment, check that the current call is
-- not a rewriting of a protected function call.
- if Needs_Finalization (Etype (Subp))
- and then not Is_Inherently_Limited_Type (Etype (Subp))
- and then
- (No (First_Formal (Subp))
- or else
- not Is_Concurrent_Record_Type (Etype (First_Formal (Subp))))
- then
- Expand_Ctrl_Function_Call (N);
+ if Needs_Finalization (Etype (Subp)) then
+ if not Is_Inherently_Limited_Type (Etype (Subp))
+ and then
+ (No (First_Formal (Subp))
+ or else
+ not Is_Concurrent_Record_Type (Etype (First_Formal (Subp))))
+ then
+ Expand_Ctrl_Function_Call (N);
+
+ -- Build-in-place function calls which appear in anonymous contexts
+ -- need a transient scope to ensure the proper finalization of the
+ -- intermediate result after its use.
+
+ elsif Is_Build_In_Place_Function_Call (N)
+ and then Nkind_In (Parent (N), N_Attribute_Reference,
+ N_Function_Call,
+ N_Indexed_Component,
+ N_Object_Renaming_Declaration,
+ N_Procedure_Call_Statement,
+ N_Selected_Component,
+ N_Slice)
+ then
+ Establish_Transient_Scope (N, Sec_Stack => True);
+ end if;
end if;
-- Test for First_Optional_Parameter, and if so, truncate parameter list
-- scope is established to ensure eventual cleanup of the result.
else
-
-- Pass an allocation parameter indicating that the function should
-- allocate its result on the secondary stack.
Add_Access_Actual_To_Build_In_Place_Call
(Func_Call, Function_Id, Empty);
-
- Establish_Transient_Scope (Func_Call, Sec_Stack => True);
end if;
end Make_Build_In_Place_Call_In_Anonymous_Context;
-- releasing or some finalizations are needed or in the context
-- of tasking
- if Uses_Sec_Stack (Current_Scope)
+ if Uses_Sec_Stack (Current_Scope)
and then not Sec_Stack_Needed_For_Return (Current_Scope)
then
null;
if Is_Itype (Typ) and then Typ /= Base_Type (Typ) then
Build_To_Any_Function
- (Loc => Loc,
- Typ => Etype (Typ),
- Decl => Decl,
- Fnam => Fnam);
+ (Loc => Loc,
+ Typ => Etype (Typ),
+ Decl => Decl,
+ Fnam => Fnam);
return;
end if;
Return_Code => Return_Code,
Err_To_Out => True);
- Close (FD);
-
-- Read the output of the invocation of gnatmake
Open (File, In_File, Get_Name_String (Name));
-- Note: for I and W, condition above is in the RM syntax sense (this
-- condition is a decision in SCO terminology).
- -- and is omitted for all other cases.
+ -- and is omitted for all other cases
-- Note: up to 6 entries can appear on a single CS line. If more than 6
-- entries appear in one logical statement sequence, continuation lines
-- For each decision, a decision line is generated with the form:
- -- C* sloc expression
+ -- C* sloc expression [chaining]
-- Here * is one of the following characters:
-- For I, E, P, W, sloc is the source location of the IF, EXIT, PRAGMA or
-- WHILE token.
- -- For X, sloc is omitted.
+ -- For X, sloc is omitted
-- The expression is a prefix polish form indicating the structure of
-- the decision, including logical operators and short-circuit forms.
-- where t/f are used to mark a condition that has been recognized by
-- the compiler as always being true or false.
- -- & indicates AND THEN connecting two conditions.
+ -- & indicates AND THEN connecting two conditions
- -- | indicates OR ELSE connecting two conditions.
+ -- | indicates OR ELSE connecting two conditions
- -- ! indicates NOT applied to the expression.
+ -- ! indicates NOT applied to the expression
-- Note that complex decisions do NOT include non-short-circuited logical
-- operators (AND/XOR/OR). In the context of existing coverage tools the
-- condition, and that is true even if the Ada 2005 set membership
-- form is used, e.g. A in (2,7,11.15).
+ -- The expression can be followed by chaining indicators of the form
+ -- Tsloc-range or Fsloc-range.
+
+ -- T* is present when the statement with the given sloc range is executed
+ -- if, and only if, the decision evaluates to TRUE.
+
+ -- F* is present when the statement with the given sloc range is executed
+ -- if, and only if, the decision evaluates to FALSE.
+
+ -- For an IF statement or ELSIF part, a T chaining indicator is always
+ -- present, with the sloc range of the first statement in the
+ -- corresponding sequence.
+
+ -- For an ELSE part, the last decision in the IF statement (that of the
+ -- last ELSIF part, if any, or that of the IF statement if there is no
+ -- ELSIF part) has an F chaining indicator with the sloc range of the
+ -- first statement in the sequence of the ELSE part.
+
+ -- For a WHILE loop, a T chaining indicator is always present, with the
+ -- sloc range of the first statement in the loop, but no F chaining
+ -- indicator is ever present.
+
+ -- For an EXIT WHEN statement, an F chaining indicator is present if
+ -- there is an immediately following sequence in the same sequence of
+ -- statements.
+
+ -- In all other cases, chaining indicators are omitted
+
-- Case Expressions
-- For case statements, we rely on statement coverage to make sure that
-- CC sloc-range sloc-range ...
- -- where sloc-range covers the range of the case expression.
+ -- where sloc-range covers the range of the case expression
-- Note: up to 6 entries can appear on a single CC line. If more than 6
-- entries appear in one logical statement sequence, continuation lines
-- To = ending source location
-- Last = False for all but the last entry, True for last entry
+ -- Element (chaining indicator)
+ -- C1 = 'H' (cHain)
+ -- C2 = 'T' or 'F' (chaining on decision true/false)
+ -- From = starting source location of chained statement
+ -- To = ending source location of chained statement
+
-- Note: the sequence starting with a decision, and continuing with
-- operators and elements up to and including the first one labeled with
-- Last = True, indicate the sequence to be output on one decision line.
-- If the context item indicates that a package body is needed
-- because of an instantiation in CU, traverse the body now,
- -- even if CU is not related to the main unit.
+ -- even if CU is not related to the main unit. If the generic
+ -- itself appears in a package body, the context item is this
+ -- body, and it already appears in the traversal order, so we
+ -- only need to examine the case where the context item is a
+ -- package declaration.
if Present (Withed_Body (Context_Item))
- and then Present (Corresponding_Body (Unit (Lib_Unit)))
+ and then Nkind (Unit (Lib_Unit)) = N_Package_Declaration
+ and then Present (Corresponding_Body (Unit (Lib_Unit)))
then
Body_CU :=
Parent