- ---------------------------------------
- -- Private data in protected objects --
- ---------------------------------------
-
- -- Private object declarations in protected types pose problems
- -- similar to those of discriminants. They are expanded to components
- -- of a record which is passed as the parameter "_object" to expanded
- -- forms of all protected operations. As with discriminants, timing
- -- of this expansion is a problem. The sequence of statements for a
- -- protected operation is expanded before the operation itself, so the
- -- formal parameter for the record object containing the private data
- -- does not exist when the references to that data are expanded.
-
- -- For this reason, private data is handled in the same way as
- -- discriminants, expanding references to private data in protected
- -- operations (which appear as components) to placeholders which will
- -- eventually become renamings of the private selected components
- -- of the "_object" formal parameter. These placeholders are called
- -- "privals", by analogy to the "discriminals" used to implement
- -- discriminants. They are attached to the component declaration nodes
- -- representing the private object declarations of the protected type.
-
- -- As with discriminals, each protected subprogram needs a unique set
- -- of privals, since they must refer to renamings of components of a
- -- formal parameter of that operation. Entry bodies need another set,
- -- which they all share and which is associated with renamings in the
- -- Service_Entries procedure for the protected type (this is not yet
- -- implemented???). This means that we must associate a new set of
- -- privals (and discriminals) with the private declarations after
- -- the body of a protected subprogram is processed.
-
- -- The last complication is the presence of discriminants and discriminated
- -- components. In the corresponding record, the components are constrained
- -- by the discriminants of the record, but within each protected operation
- -- they are constrained by the discriminants of the actual. The actual
- -- subtypes of those components are constructed as for other unconstrained
- -- formals, but the privals are created before the formal object is added
- -- to the parameter list of the protected operation, so they carry the
- -- nominal subtype of the original component. After the protected operation
- -- is actually created (in the expansion of the protected body) we must
- -- patch the types of each prival occurrence with the proper actual subtype
- -- which is by now set. The Privals_Chain is used for this patching.
+ ---------------------------------------------------
+ -- Handling of private data in protected objects --
+ ---------------------------------------------------
+
+ -- Private components in protected types pose problems similar to those
+ -- of discriminants. Private data is visible and can be directly referenced
+ -- from protected bodies. However, when protected entries and subprograms
+ -- are expanded into corresponding bodies and barrier functions, private
+ -- components lose their original context and visibility.
+
+ -- To remedy this side effect of expansion, private components are expanded
+ -- into renamings called "privals", by analogy with "discriminals".
+
+ -- private_comp : comp_type renames _object.private_comp;
+
+ -- Prival declarations are inserted during the analysis of subprogram and
+ -- entry bodies to ensure proper visibility for any subsequent expansion.
+ -- _Object is the formal parameter of the generated corresponding body or
+ -- a local renaming which denotes the protected object obtained from entry
+ -- parameter _O. Privals receive minimal decoration upon creation and are
+ -- categorized as either E_Variable for the general case or E_Constant when
+ -- they appear in functions.
+
+ -- Along with the local declarations, each private component carries a
+ -- placeholder which references the prival entity in the current body. This
+ -- form of indirection is used to resolve name clashes of privals and other
+ -- locally visible entities such as parameters, local objects, entry family
+ -- indexes or identifiers used in the barrier condition.
+
+ -- When analyzing the statements of a protected subprogram or entry, any
+ -- reference to a private component must resolve to the locally declared
+ -- prival through normal visibility. In case of name conflicts (the cases
+ -- above), the prival is marked as hidden and acts as a weakly declared
+ -- entity. As a result, the reference points to the correct entity. When a
+ -- private component is denoted by an expanded name (prot_type.comp for
+ -- example), the expansion mechanism uses the placeholder of the component
+ -- to correct the Entity and Etype of the reference.