1------------------------------------------------------------------------------ 2-- -- 3-- ASIS-for-GNAT IMPLEMENTATION COMPONENTS -- 4-- -- 5-- A 4 G . U N I T _ R E C -- 6-- -- 7-- S p e c -- 8-- -- 9-- Copyright (C) 1995-2011, Free Software Foundation, Inc. -- 10-- -- 11-- ASIS-for-GNAT is free software; you can redistribute it and/or modify it -- 12-- under terms of the GNU General Public License as published by the Free -- 13-- Software Foundation; either version 2, or (at your option) any later -- 14-- version. ASIS-for-GNAT is distributed in the hope that it will be use- -- 15-- ful, but WITHOUT ANY WARRANTY; without even the implied warranty of MER- -- 16-- CHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General -- 17-- Public License for more details. You should have received a copy of the -- 18-- GNU General Public License distributed with ASIS-for-GNAT; see file -- 19-- COPYING. If not, write to the Free Software Foundation, 51 Franklin -- 20-- Street, Fifth Floor, Boston, MA 02110-1301, USA. -- 21-- -- 22-- -- 23-- -- 24-- -- 25-- -- 26-- -- 27-- -- 28-- -- 29-- ASIS-for-GNAT was originally developed by the ASIS-for-GNAT team at the -- 30-- Software Engineering Laboratory of the Swiss Federal Institute of -- 31-- Technology (LGL-EPFL) in Lausanne, Switzerland, in cooperation with the -- 32-- Scientific Research Computer Center of Moscow State University (SRCC -- 33-- MSU), Russia, with funding partially provided by grants from the Swiss -- 34-- National Science Foundation and the Swiss Academy of Engineering -- 35-- Sciences. ASIS-for-GNAT is now maintained by AdaCore -- 36-- (http://www.adacore.com). -- 37-- -- 38------------------------------------------------------------------------------ 39 40-- This package defines the type Unit_Record used for storing the 41-- information about ASIS Compilation Units. This type is used as an actual 42-- parameter for instantiating the GNAT Table package and obtaining the type 43-- for defining the individual Unit Table for each ASIS Context. 44 45with Asis; 46 47with Asis.Extensions; use Asis.Extensions; 48 49with A4G.A_Types; use A4G.A_Types; 50 51with Types; use Types; 52 53package A4G.Unit_Rec is 54 55 -- See A4G.Contt (spec) and A4G.Contt.UT for the complete documentation of 56 -- the Compilation Units processing in ASIS. 57 58 -- !!! Documentation should be put in order later!!! 59 60 --------------------------------- 61 -- Unit_Record type definition -- 62 --------------------------------- 63 64 type Unit_Record is record -- the field should be commented also here!!! 65 66 -------------------------------- 67 -- Fields for Unit Name Table -- 68 -------------------------------- 69 70 Ada_Name_Chars_Index : Int; 71 Norm_Ada_Name_Chars_Index : Int; 72 File_Name_Chars_Index : Int; 73 Ref_Name_Chars_Index : Int; 74 -- Starting locations of characters in the Name_Chars table minus 75 -- one (i.e. pointer to character just before first character). The 76 -- reason for the bias of one is that indexes in Name_Buffer are 77 -- one's origin, so this avoids unnecessary adds and subtracts of 1. 78 79 Ada_Name_Len : Short; 80 Norm_Ada_Name_Len : Short; 81 File_Name_Len : Short; 82 Ref_Name_Len : Short; 83 -- Lengths of the names in characters 84 85 -- We keep separate starting locations and separate lengths 86 -- for each "column" of Unit Name Table, but all the actual 87 -- strings are stored in the same Name_Chars table 88 89 Hash_Link : Unit_Id; 90 -- Link to next entry in names table for same hash code 91 92 ----------------------------------------------- 93 -- Fields for Black-Box Unit Name Attributes -- 94 ----------------------------------------------- 95 96 Top : Node_Id; 97 -- ??? Do we really need it? 98 -- This field is used only during the tree investigation, 99 -- and it is used only for the Units contained in this tree, 100 -- which have been known to ASIS before (the aim is to optimize 101 -- the tree investigation by eliminating the need to compute 102 -- the top node for the these Units). Tree swapping makes 103 -- the values of these fields obsolete, and we do not want 104 -- to keep them valid after investigating the tree. Instead, 105 -- if we need the top node corresponding to some Unit during 106 -- processing of some ASIS query, we compute it, and this 107 -- computation includes, if the Unit may be processed on the 108 -- base of the currently accessed tree, resetting this 109 -- tree, if necessary, and finding out the corresponding 110 -- N_Compuilation_Unit node in this tree. 111 112 Kind : Asis.Unit_Kinds; 113 Class : Asis.Unit_Classes; 114 Origin : Asis.Unit_Origins; 115 Main_Unit : Boolean; 116 Is_Body_Required : Boolean; 117 Time_Stamp : Time_Stamp_Type; 118 119 Is_Consistent : Boolean; 120 121 Source_File_Status : Source_File_Statuses; 122 123 Full_View_Trees : Elist_Id; 124 Limited_View_Trees : Elist_Id; 125 -- The lists of the trees in which the subtree for a given Unit is 126 -- contained, all these trees are consistent in the sense, that all of 127 -- them correspond to the same, latest version of unit's source. The 128 -- first list contains trees that contain full view of the unit, the 129 -- second contains trees that contain only limited views of the unit. 130 131 Main_Tree : Tree_Id; 132 -- The tree for which the given unit is a main unit. If there is no 133 -- tree for which the unit is the main unit, this field set to 134 -- Nil_Tree_Id 135 136 -------------------------------------- 137 -- Fields for Semantic Dependencies -- 138 -------------------------------------- 139 140 Ancestors : Elist_Id; 141 Descendants : Elist_Id; 142 Direct_Supporters : Elist_Id; 143 Supporters : Elist_Id; 144 Implicit_Supporters : Elist_Id; 145 Direct_Dependents : Elist_Id; 146 Dependents : Elist_Id; 147 Subunits_Or_Childs : Elist_Id; 148 149 Compilation_Dependencies : Elist_Id; 150 151 Subunits_Computed : Boolean; 152 153 -- The meaning of these lists completely corresponds to the values 154 -- of the Asis.Unit_Kinds.Relation_Kinds type, represented by its 155 -- literals with the same names. 156 -- SHOULD BE REVISED! For example, for subunits it may make sense 157 -- to use Ancestors for parent bodies, and it would make sense 158 -- for bodies to use Descendants for subunits. 159 -- 160 -- All these fields are either non-empty unit lists, or equal to 161 -- No_List, the latter case correspond to the situation, when 162 -- the corresponding dependency list is empty (???). 163 164 -- it would be nice to get rid of Direct_Supporters and of 165 -- Direct_Dependants as of ill-defined notions (they are not 166 -- defined in RM95, opposite to Supporters and Dependents 167 168 -- We may need Implicit_Supporters for 169 -- Asis.Compilation_Units.Elaboration_Order query 170 171 -- Subunits_Computed indicates if for a given parent body all its 172 -- subunits have already been computed (as a result of a Compilation 173 -- Unit semantic query). Computing subunits include allocating 174 -- nonexistent units for missed subunits. 175 176 -- Do we really need the list for Ancestors? We can easy compute 177 -- ancestors by stripping out selectors in normalized unit names. 178 179 -- OPEN PROBLEMS with ASIS 95 definition 180 -- ===================================== 181 182 -- 1. RM95 says 10.1.1(9): 183 -- A library unit is a program unit that is declared by a 184 -- library_item. When a program unit is a library unit, the 185 -- prefix "library" is used to refer to it (or "generic 186 -- library" if generic), as well as to its declaration and 187 -- body, as in "library procedure", "library package_body", 188 -- or "generic library package". The term compilation unit 189 -- is used to refer to a compilation_unit. When the meaning 190 -- is clear from context, the term is also used to refer to 191 -- the library_item of a compilation_unit or to the proper_body 192 -- of a subunit (that is, the compilation_unit without the 193 -- context_clause and the separate (parent_unit_name)). 194 -- 195 -- And AARM adds in 10.1.1(9.d): 196 -- We like to use the word "unit" for declaration-plus-body 197 -- things, and "item" for declaration or body separately 198 -- (as in declarative_item). The terms "compilation_unit", 199 -- "compilation unit" and "subunit" are exceptions to this rule. 200 -- 201 -- RM95 says 10.1.1(10): 202 -- The parent declaration of a library_item (and of the library 203 -- unit) is the declaration denoted by the parent_unit_name, if 204 -- any, of the defining_program_unit_name of the library_item. 205 -- If there is no parent_unit_name, the parent declaration is 206 -- the declaration of Standard, the library_item is a root 207 -- library_item, and the library unit (renaming) is a root 208 -- library unit (renaming). The declaration and body of 209 -- Standard itself have no parent declaration. The parent unit 210 -- of a library_item or library unit is the library unit 211 -- declared by its parent declaration. 212 -- 213 -- And AARM adds in 10.1.1(10.d): 214 -- Library units ... have "parent declarations" [which are 215 -- *compilation* units] and "parent units" [spec + body]. 216 -- We didn't bother to define the other possibilities: parent 217 -- body of a library unit, parent declaration of a subunit, 218 -- parent unit of a subunit. These are not needed... 219 -- 220 -- RM95 says 10.1.1(11): 221 -- The children of a library unit occur immediately within the 222 -- declarative region of the declaration of the library unit. 223 -- The ancestors of a library unit are itself, its parent, its 224 -- parent's parent, and so on. (Standard is an ancestor of 225 -- every library unit.) The descendant relation is the inverse 226 -- of the ancestor relation. 227 -- 228 -- AARM adds (10.1.1(11.b): 229 -- We use the unadorned term "ancestors" here to concisely 230 -- define both "ancestor unit" and "ancestor declaration" 231 -- 232 -- THE QUESTION IS: what do the *ASIS* notions of ancestors 233 -- and descendants mean - do they mean "ancestor (descendant) 234 -- unit" or "ancestor (descendant) declaration"? 235 -- 236 -- THE "WORKING" SOLUTION: now *in ASIS* "ancestor" means 237 -- "ancestor declaration", and "descendant" means "descendant 238 -- unit". (Is it really a good decision, if the Descendants 239 -- relation is defined by ASIS as the inverse of the ancestor 240 -- relation? From the other side, this looks quite natural from 241 -- the application viewpoint: if we are asking about ancestors, 242 -- we are very likely interested in declarations, but not 243 -- bodies,, and when we are asking about descendants, we are 244 -- very likely interested in *all* (compilation units which are) 245 -- the descendants. 246 -- 247 -- (Moreover, the query 248 -- Asis.Compilation_Units.Corresponding_Children has only 249 -- *declarations* as appropriate argument unit kinds, and it 250 -- returns declarations *and bodies (if any)* 251 252 end record; 253 254end A4G.Unit_Rec; 255