]>
Commit | Line | Data |
---|---|---|
8d08fdba MS |
1 | \input texinfo @c -*-texinfo-*- |
2 | @c %**start of header | |
3 | @setfilename g++int.info | |
4 | @settitle G++ internals | |
5 | @setchapternewpage odd | |
6 | @c %**end of header | |
7 | ||
8 | @node Top, Limitations of g++, (dir), (dir) | |
9 | @chapter Internal Architecture of the Compiler | |
10 | ||
11 | This is meant to describe the C++ frontend for gcc in detail. | |
12 | Questions and comments to mrs@@cygnus.com. | |
13 | ||
14 | @menu | |
15 | * Limitations of g++:: | |
16 | * Routines:: | |
17 | * Implementation Specifics:: | |
18 | * Glossary:: | |
19 | * Macros:: | |
20 | * Typical Behavior:: | |
21 | * Coding Conventions:: | |
22 | * Templates:: | |
23 | * Access Control:: | |
24 | * Error Reporting:: | |
25 | * Concept Index:: | |
26 | @end menu | |
27 | ||
28 | @node Limitations of g++, Routines, Top, Top | |
29 | @section Limitations of g++ | |
30 | ||
31 | @itemize @bullet | |
32 | @item | |
33 | Limitations on input source code: 240 nesting levels with the parser | |
34 | stacksize (YYSTACKSIZE) set to 500 (the default), and requires around | |
35 | 16.4k swap space per nesting level. The parser needs about 2.09 * | |
36 | number of nesting levels worth of stackspace. | |
37 | ||
38 | @cindex pushdecl_class_level | |
39 | @item | |
40 | I suspect there are other uses of pushdecl_class_level that do not call | |
41 | set_identifier_type_value in tandem with the call to | |
42 | pushdecl_class_level. It would seem to be an omission. | |
43 | ||
44 | @cindex delete, two argument | |
45 | @item | |
46 | For two argument delete, the second argument is always calculated by | |
47 | ``virtual_size ='' in the source. It currently has a problem, in that | |
48 | object size is not calculated by the virtual destructor and passed back | |
49 | for the second parameter to delete. Destructors need to return a value | |
50 | just like constructors. ANSI C++ Jun 5 92 wp 12.5.6 | |
51 | ||
52 | The second argument is magically deleted in build_method_call, if it is | |
53 | not used. It needs to be deleted for global operator delete also. | |
54 | ||
55 | @cindex access checking | |
56 | @item | |
57 | Access checking in general is unimplemented, there are a few cases | |
58 | where it is implemented. grok_enum_decls should be used in more places | |
59 | to do access checking, but this is only the tip of a bigger problem. | |
60 | ||
61 | @cindex @code{volatile} | |
62 | @item | |
63 | @code{volatile} is not implemented in general. | |
64 | ||
65 | @cindex pointers to members | |
66 | @item | |
67 | Pointers to members are only minimally supported, and there are places | |
68 | where the grammar doesn't even properly accept them yet. | |
69 | ||
70 | @cindex multiple inheritance | |
71 | @item | |
72 | @code{this} will be wrong in virtual members functions defined in a | |
73 | virtual base class, when they are overridden in a derived class, when | |
74 | called via a non-left most object. | |
75 | ||
76 | An example would be: | |
77 | ||
78 | @example | |
79 | extern "C" int printf(const char*, ...); | |
80 | struct A { virtual void f() { } }; | |
81 | struct B : virtual A { int b; B() : b(0) {} void f() { b++; } }; | |
82 | struct C : B {}; | |
83 | struct D : B {}; | |
84 | struct E : C, D {}; | |
85 | int main() | |
86 | { | |
87 | E e; | |
88 | C& c = e; D& d = e; | |
89 | c.f(); d.f(); | |
90 | printf ("C::b = %d, D::b = %d\n", e.C::b, e.D::b); | |
91 | return 0; | |
92 | } | |
93 | @end example | |
94 | ||
95 | This will print out 2, 0, instead of 1,1. | |
96 | ||
97 | @end itemize | |
98 | ||
99 | @node Routines, Implementation Specifics, Limitations of g++, Top | |
100 | @section Routines | |
101 | ||
102 | This section describes some of the routines used in the C++ front-end. | |
103 | ||
104 | @code{build_vtable} and @code{prepare_fresh_vtable} is used only within | |
105 | the @file{cp-class.c} file, and only in @code{finish_struct} and | |
106 | @code{modify_vtable_entries}. | |
107 | ||
108 | @code{build_vtable}, @code{prepare_fresh_vtable}, and | |
109 | @code{finish_struct} are the only routines that set @code{DECL_VPARENT}. | |
110 | ||
111 | @code{finish_struct} can steal the virtual function table from parents, | |
112 | this prohibits related_vslot from working. When finish_struct steals, | |
113 | we know that | |
114 | ||
115 | @example | |
116 | get_binfo (DECL_FIELD_CONTEXT (CLASSTYPE_VFIELD (t)), t, 0) | |
117 | @end example | |
118 | ||
119 | @noindent | |
120 | will get the related binfo. | |
121 | ||
122 | @code{layout_basetypes} does something with the VIRTUALS. | |
123 | ||
124 | Supposedly (according to Tiemann) most of the breadth first searching | |
125 | done, like in @code{get_base_distance} and in @code{get_binfo} was not | |
126 | because of any design decision. I have since found out the at least one | |
127 | part of the compiler needs the notion of depth first binfo searching, I | |
128 | am going to try and convert the whole thing, it should just work. The | |
129 | term left-most refers to the depth first left-most node. It uses | |
130 | @code{MAIN_VARIANT == type} as the condition to get left-most, because | |
131 | the things that have @code{BINFO_OFFSET}s of zero are shared and will | |
132 | have themselves as their own @code{MAIN_VARIANT}s. The non-shared right | |
133 | ones, are copies of the left-most one, hence if it is its own | |
134 | @code{MAIN_VARIENT}, we know it IS a left-most one, if it is not, it is | |
135 | a non-left-most one. | |
136 | ||
137 | @code{get_base_distance}'s path and distance matters in its use in: | |
138 | ||
139 | @itemize @bullet | |
140 | @item | |
141 | @code{prepare_fresh_vtable} (the code is probably wrong) | |
142 | @item | |
143 | @code{init_vfields} Depends upon distance probably in a safe way, | |
144 | build_offset_ref might use partial paths to do further lookups, | |
145 | hack_identifier is probably not properly checking access. | |
146 | ||
147 | @item | |
148 | @code{get_first_matching_virtual} probably should check for | |
149 | @code{get_base_distance} returning -2. | |
150 | ||
151 | @item | |
152 | @code{resolve_offset_ref} should be called in a more deterministic | |
153 | manner. Right now, it is called in some random contexts, like for | |
154 | arguments at @code{build_method_call} time, @code{default_conversion} | |
155 | time, @code{convert_arguments} time, @code{build_unary_op} time, | |
156 | @code{build_c_cast} time, @code{build_modify_expr} time, | |
157 | @code{convert_for_assignment} time, and | |
158 | @code{convert_for_initialization} time. | |
159 | ||
160 | But, there are still more contexts it needs to be called in, one was the | |
161 | ever simple: | |
162 | ||
163 | @example | |
164 | if (obj.*pmi != 7) | |
165 | @dots{} | |
166 | @end example | |
167 | ||
168 | Seems that the problems were due to the fact that @code{TREE_TYPE} of | |
169 | the @code{OFFSET_REF} was not a @code{OFFSET_TYPE}, but rather the type | |
170 | of the referent (like @code{INTEGER_TYPE}). This problem was fixed by | |
171 | changing @code{default_conversion} to check @code{TREE_CODE (x)}, | |
172 | instead of only checking @code{TREE_CODE (TREE_TYPE (x))} to see if it | |
173 | was @code{OFFSET_TYPE}. | |
174 | ||
175 | @end itemize | |
176 | ||
177 | @node Implementation Specifics, Glossary, Routines, Top | |
178 | @section Implementation Specifics | |
179 | ||
180 | @itemize @bullet | |
181 | @item Explicit Initialization | |
182 | ||
183 | The global list @code{current_member_init_list} contains the list of | |
184 | mem-initializers specified in a constructor declaration. For example: | |
185 | ||
186 | @example | |
187 | foo::foo() : a(1), b(2) @{@} | |
188 | @end example | |
189 | ||
190 | @noindent | |
191 | will initialize @samp{a} with 1 and @samp{b} with 2. | |
192 | @code{expand_member_init} places each initialization (a with 1) on the | |
193 | global list. Then, when the fndecl is being processed, | |
194 | @code{emit_base_init} runs down the list, initializing them. It used to | |
195 | be the case that g++ first ran down @code{current_member_init_list}, | |
196 | then ran down the list of members initializing the ones that weren't | |
197 | explicitly initialized. Things were rewritten to perform the | |
198 | initializations in order of declaration in the class. So, for the above | |
199 | example, @samp{a} and @samp{b} will be initialized in the order that | |
200 | they were declared: | |
201 | ||
202 | @example | |
203 | class foo @{ public: int b; int a; foo (); @}; | |
204 | @end example | |
205 | ||
206 | @noindent | |
207 | Thus, @samp{b} will be initialized with 2 first, then @samp{a} will be | |
208 | initialized with 1, regardless of how they're listed in the mem-initializer. | |
209 | ||
210 | @item Argument Matching | |
211 | ||
212 | In early 1993, the argument matching scheme in @sc{gnu} C++ changed | |
213 | significantly. The original code was completely replaced with a new | |
214 | method that will, hopefully, be easier to understand and make fixing | |
215 | specific cases much easier. | |
216 | ||
217 | The @samp{-fansi-overloading} option is used to enable the new code; at | |
218 | some point in the future, it will become the default behavior of the | |
219 | compiler. | |
220 | ||
221 | The file @file{cp-call.c} contains all of the new work, in the functions | |
222 | @code{rank_for_overload}, @code{compute_harshness}, | |
223 | @code{compute_conversion_costs}, and @code{ideal_candidate}. | |
224 | ||
225 | Instead of using obscure numerical values, the quality of an argument | |
226 | match is now represented by clear, individual codes. The new data | |
227 | structure @code{struct harshness} (it used to be an @code{unsigned} | |
228 | number) contains: | |
229 | ||
230 | @enumerate a | |
231 | @item the @samp{code} field, to signify what was involved in matching two | |
232 | arguments; | |
233 | @item the @samp{distance} field, used in situations where inheritance | |
234 | decides which function should be called (one is ``closer'' than | |
235 | another); | |
236 | @item and the @samp{int_penalty} field, used by some codes as a tie-breaker. | |
237 | @end enumerate | |
238 | ||
239 | The @samp{code} field is a number with a given bit set for each type of | |
240 | code, OR'd together. The new codes are: | |
241 | ||
242 | @itemize @bullet | |
243 | @item @code{EVIL_CODE} | |
244 | The argument was not a permissible match. | |
245 | ||
246 | @item @code{CONST_CODE} | |
247 | Currently, this is only used by @code{compute_conversion_costs}, to | |
248 | distinguish when a non-@code{const} member function is called from a | |
249 | @code{const} member function. | |
250 | ||
251 | @item @code{ELLIPSIS_CODE} | |
252 | A match against an ellipsis @samp{...} is considered worse than all others. | |
253 | ||
254 | @item @code{USER_CODE} | |
255 | Used for a match involving a user-defined conversion. | |
256 | ||
257 | @item @code{STD_CODE} | |
258 | A match involving a standard conversion. | |
259 | ||
260 | @item @code{PROMO_CODE} | |
261 | A match involving an integral promotion. For these, the | |
262 | @code{int_penalty} field is used to handle the ARM's rule (XXX cite) | |
263 | that a smaller @code{unsigned} type should promote to a @code{int}, not | |
264 | to an @code{unsigned int}. | |
265 | ||
266 | @item @code{QUAL_CODE} | |
267 | Used to mark use of qualifiers like @code{const} and @code{volatile}. | |
268 | ||
269 | @item @code{TRIVIAL_CODE} | |
270 | Used for trivial conversions. The @samp{int_penalty} field is used by | |
271 | @code{convert_harshness} to communicate further penalty information back | |
272 | to @code{build_overload_call_real} when deciding which function should | |
273 | be call. | |
274 | @end itemize | |
275 | ||
276 | The functions @code{convert_to_aggr} and @code{build_method_call} use | |
277 | @code{compute_conversion_costs} to rate each argument's suitability for | |
278 | a given candidate function (that's how we get the list of candidates for | |
279 | @code{ideal_candidate}). | |
280 | ||
281 | @end itemize | |
282 | ||
283 | @node Glossary, Macros, Implementation Specifics, Top | |
284 | @section Glossary | |
285 | ||
286 | @table @r | |
287 | @item binfo | |
288 | The main data structure in the compiler used to represent the | |
289 | inheritance relationships between classes. The data in the binfo can be | |
290 | accessed by the BINFO_ accessor macros. | |
291 | ||
292 | @item vtable | |
293 | @itemx virtual function table | |
294 | ||
295 | The virtual function table holds information used in virtual function | |
296 | dispatching. In the compiler, they are usually referred to as vtables, | |
297 | or vtbls. The first index is not used in the normal way, I believe it | |
298 | is probably used for the virtual destructor. | |
299 | ||
300 | @item vfield | |
301 | ||
302 | vfields can be thought of as the base information needed to build | |
303 | vtables. For every vtable that exists for a class, there is a vfield. | |
304 | See also vtable and virtual function table pointer. When a type is used | |
305 | as a base class to another type, the virtual function table for the | |
306 | derived class can be based upon the vtable for the base class, just | |
307 | extended to include the additional virtual methods declared in the | |
308 | derived class. The virtual function table from a virtual base class is | |
309 | never reused in a derived class. @code{is_normal} depends upon this. | |
310 | ||
311 | @item virtual function table pointer | |
312 | ||
313 | These are @code{FIELD_DECL}s that are pointer types that point to | |
314 | vtables. See also vtable and vfield. | |
315 | @end table | |
316 | ||
317 | @node Macros, Typical Behavior, Glossary, Top | |
318 | @section Macros | |
319 | ||
320 | This section describes some of the macros used on trees. The list | |
321 | should be alphabetical. Eventually all macros should be documented | |
322 | here. There are some postscript drawings that can be used to better | |
323 | understnad from of the more complex data structures, contact Mike Stump | |
324 | (@code{mrs@@cygnus.com}) for information about them. | |
325 | ||
326 | @table @code | |
327 | @item BINFO_BASETYPES | |
328 | A vector of additional binfos for the types inherited by this basetype. | |
329 | The binfos are fully unshared (except for virtual bases, in which | |
330 | case the binfo structure is shared). | |
331 | ||
332 | If this basetype describes type D as inherited in C, | |
333 | and if the basetypes of D are E anf F, | |
334 | then this vector contains binfos for inheritance of E and F by C. | |
335 | ||
336 | Has values of: | |
337 | ||
338 | TREE_VECs | |
339 | ||
340 | ||
341 | @item BINFO_INHERITANCE_CHAIN | |
342 | Temporarily used to represent specific inheritances. It usually points | |
343 | to the binfo associated with the lesser derived type, but it can be | |
344 | reversed by reverse_path. For example: | |
345 | ||
346 | @example | |
347 | Z ZbY least derived | |
348 | | | |
349 | Y YbX | |
350 | | | |
351 | X Xb most derived | |
352 | ||
353 | TYPE_BINFO (X) == Xb | |
354 | BINFO_INHERITANCE_CHAIN (Xb) == YbX | |
355 | BINFO_INHERITANCE_CHAIN (Yb) == ZbY | |
356 | BINFO_INHERITANCE_CHAIN (Zb) == 0 | |
357 | @end example | |
358 | ||
359 | Not sure is the above is really true, get_base_distance has is point | |
360 | towards the most derived type, opposite from above. | |
361 | ||
362 | Set by build_vbase_path, recursive_bounded_basetype_p, | |
363 | get_base_distance, lookup_field, lookup_fnfields, and reverse_path. | |
364 | ||
365 | What things can this be used on: | |
366 | ||
367 | TREE_VECs that are binfos | |
368 | ||
369 | ||
370 | @item BINFO_OFFSET | |
371 | The offset where this basetype appears in its containing type. | |
372 | BINFO_OFFSET slot holds the offset (in bytes) from the base of the | |
373 | complete object to the base of the part of the object that is allocated | |
374 | on behalf of this `type'. This is always 0 except when there is | |
375 | multiple inheritance. | |
376 | ||
377 | Used on TREE_VEC_ELTs of the binfos BINFO_BASETYPES (...) for example. | |
378 | ||
379 | ||
380 | @item BINFO_VIRTUALS | |
381 | A unique list of functions for the virtual function table. See also | |
382 | TYPE_BINFO_VIRTUALS. | |
383 | ||
384 | What things can this be used on: | |
385 | ||
386 | TREE_VECs that are binfos | |
387 | ||
388 | ||
389 | @item BINFO_VTABLE | |
390 | Used to find the VAR_DECL that is the virtual function table associated | |
391 | with this binfo. See also TYPE_BINFO_VTABLE. To get the virtual | |
392 | function table pointer, see CLASSTYPE_VFIELD. | |
393 | ||
394 | What things can this be used on: | |
395 | ||
396 | TREE_VECs that are binfos | |
397 | ||
398 | Has values of: | |
399 | ||
400 | VAR_DECLs that are virtual function tables | |
401 | ||
402 | ||
403 | @item BLOCK_SUPERCONTEXT | |
404 | In the outermost scope of each function, it points to the FUNCTION_DECL | |
405 | node. It aids in better DWARF support of inline functions. | |
406 | ||
407 | ||
408 | @item CLASSTYPE_TAGS | |
409 | CLASSTYPE_TAGS is a linked (via TREE_CHAIN) list of member classes of a | |
410 | class. TREE_PURPOSE is the name, TREE_VALUE is the type (pushclass scans | |
411 | these and calls pushtag on them.) | |
412 | ||
413 | finish_struct scans these to produce TYPE_DECLs to add to the | |
414 | TYPE_FIELDS of the type. | |
415 | ||
416 | It is expected that name found in the TREE_PURPOSE slot is unique, | |
417 | resolve_scope_to_name is one such place that depends upon this | |
418 | uniqueness. | |
419 | ||
420 | ||
421 | @item CLASSTYPE_METHOD_VEC | |
422 | The following is true after finish_struct has been called (on the | |
423 | class?) but not before. Before finish_struct is called, things are | |
424 | different to some extent. Contains a TREE_VEC of methods of the class. | |
425 | The TREE_VEC_LENGTH is the number of differently named methods plus one | |
426 | for the 0th entry. The 0th entry is always allocated, and reserved for | |
427 | ctors and dtors. If there are none, TREE_VEC_ELT(N,0) == NULL_TREE. | |
428 | Each entry of the TREE_VEC is a FUNCTION_DECL. For each FUNCTION_DECL, | |
429 | there is a DECL_CHAIN slot. If the FUNCTION_DECL is the last one with a | |
430 | given name, the DECL_CHAIN slot is NULL_TREE. Otherwise it is the next | |
431 | method that has the same name (but a different signature). It would | |
432 | seem that it is not true that because the DECL_CHAIN slot is used in | |
433 | this way, we cannot call pushdecl to put the method in the global scope | |
434 | (cause that would overwrite the TREE_CHAIN slot), because they use | |
435 | different _CHAINs. finish_struct_methods setups up one version of the | |
436 | TREE_CHAIN slots on the FUNCTION_DECLs. | |
437 | ||
438 | friends are kept in TREE_LISTs, so that there's no need to use their | |
439 | TREE_CHAIN slot for anything. | |
440 | ||
441 | Has values of: | |
442 | ||
443 | TREE_VECs | |
444 | ||
445 | ||
446 | @item CLASSTYPE_VFIELD | |
447 | Seems to be in the process of being renamed TYPE_VFIELD. Use on types | |
448 | to get the main virtual function table pointer. To get the virtual | |
449 | function table use BINFO_VTABLE (TYPE_BINFO ()). | |
450 | ||
451 | Has values of: | |
452 | ||
453 | FIELD_DECLs that are virtual function table pointers | |
454 | ||
455 | What things can this be used on: | |
456 | ||
457 | RECORD_TYPEs | |
458 | ||
459 | ||
460 | @item DECL_CLASS_CONTEXT | |
461 | Identifies the context that the _DECL was found in. For virtual function | |
462 | tables, it points to the type associated with the virtual function | |
463 | table. See also DECL_CONTEXT, DECL_FIELD_CONTEXT and DECL_FCONTEXT. | |
464 | ||
465 | The difference between this and DECL_CONTEXT, is that for virtuals | |
466 | functions like: | |
467 | ||
468 | @example | |
469 | struct A | |
470 | @{ | |
471 | virtual int f (); | |
472 | @}; | |
473 | ||
474 | struct B : A | |
475 | @{ | |
476 | int f (); | |
477 | @}; | |
478 | ||
479 | DECL_CONTEXT (A::f) == A | |
480 | DECL_CLASS_CONTEXT (A::f) == A | |
481 | ||
482 | DECL_CONTEXT (B::f) == A | |
483 | DECL_CLASS_CONTEXT (B::f) == B | |
484 | @end example | |
485 | ||
486 | Has values of: | |
487 | ||
488 | RECORD_TYPEs, or UNION_TYPEs | |
489 | ||
490 | What things can this be used on: | |
491 | ||
492 | TYPE_DECLs, _DECLs | |
493 | ||
494 | ||
495 | @item DECL_CONTEXT | |
496 | Identifies the context that the _DECL was found in. Can be used on | |
497 | virtual function tables to find the type associated with the virtual | |
498 | function table, but since they are FIELD_DECLs, DECL_FIELD_CONTEXT is a | |
499 | better access method. Internally the same as DECL_FIELD_CONTEXT, so | |
500 | don't us both. See also DECL_FIELD_CONTEXT, DECL_FCONTEXT and | |
501 | DECL_CLASS_CONTEXT. | |
502 | ||
503 | Has values of: | |
504 | ||
505 | RECORD_TYPEs | |
506 | ||
507 | ||
508 | What things can this be used on: | |
509 | ||
510 | @display | |
511 | VAR_DECLs that are virtual function tables | |
512 | _DECLs | |
513 | @end display | |
514 | ||
515 | ||
516 | @item DECL_FIELD_CONTEXT | |
517 | Identifies the context that the FIELD_DECL was found in. Internally the | |
518 | same as DECL_CONTEXT, so don't us both. See also DECL_CONTEXT, | |
519 | DECL_FCONTEXT and DECL_CLASS_CONTEXT. | |
520 | ||
521 | Has values of: | |
522 | ||
523 | RECORD_TYPEs | |
524 | ||
525 | What things can this be used on: | |
526 | ||
527 | @display | |
528 | FIELD_DECLs that are virtual function pointers | |
529 | FIELD_DECLs | |
530 | @end display | |
531 | ||
532 | ||
533 | @item DECL_NESTED_TYPENAME | |
534 | Holds the fully qualified type name. Example, Base::Derived. | |
535 | ||
536 | Has values of: | |
537 | ||
538 | IDENTIFIER_NODEs | |
539 | ||
540 | What things can this be used on: | |
541 | ||
542 | TYPE_DECLs | |
543 | ||
544 | ||
545 | @item DECL_NAME | |
546 | ||
547 | Has values of: | |
548 | ||
549 | @display | |
550 | 0 for things that don't have names | |
551 | IDENTIFIER_NODEs for TYPE_DECLs | |
552 | @end display | |
553 | ||
554 | @item DECL_IGNORED_P | |
555 | A bit that can be set to inform the debug information output routines in | |
556 | the backend that a certain _DECL node should be totally ignored. | |
557 | ||
558 | Used in cases where it is known that the debugging information will be | |
559 | output in another file, or where a sub-type is known not to be needed | |
560 | because the enclosing type is not needed. | |
561 | ||
562 | A compiler constructed virtual destructor in derived classes that do not | |
563 | define an exlicit destructor that was defined exlicit in a base class | |
564 | has this bit set as well. Also used on __FUNCTION__ and | |
565 | __PRETTY_FUNCTION__ to mark they are ``compiler generated.'' c-decl and | |
566 | c-lex.c both want DECL_IGNORED_P set for ``internally generated vars,'' | |
567 | and ``user-invisible variable.'' | |
568 | ||
569 | Functions built by the C++ front-end such as default destructors, | |
570 | virtual desctructors and default constructors want to be marked that | |
571 | they are compiler generated, but unsure why. | |
572 | ||
573 | Currently, it is used in an absolute way in the C++ front-end, as an | |
574 | optimization, to tell the debug information output routines to not | |
575 | generate debugging information that will be output by another separately | |
576 | compiled file. | |
577 | ||
578 | ||
579 | @item DECL_VIRTUAL_P | |
580 | A flag used on FIELD_DECLs and VAR_DECLs. (Documentation in tree.h is | |
581 | wrong.) Used in VAR_DECLs to indicate that the variable is a vtable. | |
582 | It is also used in FIELD_DECLs for vtable pointers. | |
583 | ||
584 | What things can this be used on: | |
585 | ||
586 | FIELD_DECLs and VAR_DECLs | |
587 | ||
588 | ||
589 | @item DECL_VPARENT | |
590 | Used to point to the parent type of the vtable if there is one, else it | |
591 | is just the type associated with the vtable. Because of the sharing of | |
592 | virtual function tables that goes on, this slot is not very useful, and | |
593 | is in fact, not used in the compiler at all. It can be removed. | |
594 | ||
595 | What things can this be used on: | |
596 | ||
597 | VAR_DECLs that are virtual function tables | |
598 | ||
599 | Has values of: | |
600 | ||
601 | RECORD_TYPEs maybe UNION_TYPEs | |
602 | ||
603 | ||
604 | @item DECL_FCONTEXT | |
605 | Used to find the first baseclass in which this FIELD_DECL is defined. | |
606 | See also DECL_CONTEXT, DECL_FIELD_CONTEXT and DECL_CLASS_CONTEXT. | |
607 | ||
608 | How it is used: | |
609 | ||
610 | Used when writing out debugging information about vfield and | |
611 | vbase decls. | |
612 | ||
613 | What things can this be used on: | |
614 | ||
615 | FIELD_DECLs that are virtual function pointers | |
616 | FIELD_DECLs | |
617 | ||
618 | ||
619 | @item DECL_REFERENCE_SLOT | |
620 | Used to hold the initialize for the reference. | |
621 | ||
622 | What things can this be used on: | |
623 | ||
624 | PARM_DECLs and VAR_DECLs that have a reference type | |
625 | ||
626 | ||
627 | @item DECL_VINDEX | |
628 | Used for FUNCTION_DECLs in two different ways. Before the structure | |
629 | containing the FUNCTION_DECL is laid out, DECL_VINDEX may point to a | |
630 | FUNCTION_DECL in a base class which is the FUNCTION_DECL which this | |
631 | FUNCTION_DECL will replace as a virtual function. When the class is | |
632 | laid out, this pointer is changed to an INTEGER_CST node which is | |
633 | suitable to find an index into the virtual function table. See | |
634 | get_vtable_entry as to how one can find the right index into the virtual | |
635 | function table. The first index 0, of a virtual function table it not | |
636 | used in the normal way, so the first real index is 1. | |
637 | ||
638 | DECL_VINDEX may be a TREE_LIST, that would seem to be a list of | |
639 | overridden FUNCTION_DECLs. add_virtual_function has code to deal with | |
640 | this when it uses the variable base_fndecl_list, but it would seem that | |
641 | somehow, it is possible for the TREE_LIST to pursist until method_call, | |
642 | and it should not. | |
643 | ||
644 | ||
645 | What things can this be used on: | |
646 | ||
647 | FUNCTION_DECLs | |
648 | ||
649 | ||
650 | @item DECL_SOURCE_FILE | |
651 | Identifies what source file a particular declaration was found in. | |
652 | ||
653 | Has values of: | |
654 | ||
655 | "<built-in>" on TYPE_DECLs to mean the typedef is built in | |
656 | ||
657 | ||
658 | @item DECL_SOURCE_LINE | |
659 | Identifies what source line number in the source file the declaration | |
660 | was found at. | |
661 | ||
662 | Has values of: | |
663 | ||
664 | @display | |
665 | 0 for an undefined label | |
666 | ||
667 | 0 for TYPE_DECLs that are internally generated | |
668 | ||
669 | 0 for FUNCTION_DECLs for functions generated by the compiler | |
670 | (not yet, but should be) | |
671 | ||
672 | 0 for ``magic'' arguments to functions, that the user has no | |
673 | control over | |
674 | @end display | |
675 | ||
676 | ||
677 | @item TREE_USED | |
678 | ||
679 | Has values of: | |
680 | ||
681 | 0 for unused labels | |
682 | ||
683 | ||
684 | @item TREE_ADDRESSABLE | |
685 | A flag that is set for any type that has a constructor. | |
686 | ||
687 | ||
688 | @item TREE_COMPLEXITY | |
689 | They seem a kludge way to track recursion, poping, and pushing. They only | |
690 | appear in cp-decl.c and cp-decl2.c, so the are a good candidate for | |
691 | proper fixing, and removal. | |
692 | ||
693 | ||
694 | @item TREE_PRIVATE | |
695 | Set for FIELD_DECLs by finish_struct. But not uniformly set. | |
696 | ||
697 | The following routines do something with PRIVATE access: | |
698 | build_method_call, alter_access, finish_struct_methods, | |
699 | finish_struct, convert_to_aggr, CWriteLanguageDecl, CWriteLanguageType, | |
700 | CWriteUseObject, compute_access, lookup_field, dfs_pushdecl, | |
701 | GNU_xref_member, dbxout_type_fields, dbxout_type_method_1 | |
702 | ||
703 | ||
704 | @item TREE_PROTECTED | |
705 | The following routines do something with PROTECTED access: | |
706 | build_method_call, alter_access, finish_struct, convert_to_aggr, | |
707 | CWriteLanguageDecl, CWriteLanguageType, CWriteUseObject, | |
708 | compute_access, lookup_field, GNU_xref_member, dbxout_type_fields, | |
709 | dbxout_type_method_1 | |
710 | ||
711 | ||
712 | @item TYPE_BINFO | |
713 | Used to get the binfo for the type. | |
714 | ||
715 | Has values of: | |
716 | ||
717 | TREE_VECs that are binfos | |
718 | ||
719 | What things can this be used on: | |
720 | ||
721 | RECORD_TYPEs | |
722 | ||
723 | ||
724 | @item TYPE_BINFO_BASETYPES | |
725 | See also BINFO_BASETYPES. | |
726 | ||
727 | @item TYPE_BINFO_VIRTUALS | |
728 | A unique list of functions for the virtual function table. See also | |
729 | BINFO_VIRTUALS. | |
730 | ||
731 | What things can this be used on: | |
732 | ||
733 | RECORD_TYPEs | |
734 | ||
735 | ||
736 | @item TYPE_BINFO_VTABLE | |
737 | Points to the virtual function table associated with the given type. | |
738 | See also BINFO_VTABLE. | |
739 | ||
740 | What things can this be used on: | |
741 | ||
742 | RECORD_TYPEs | |
743 | ||
744 | Has values of: | |
745 | ||
746 | VAR_DECLs that are virtual function tables | |
747 | ||
748 | ||
749 | @item TYPE_NAME | |
750 | Names the type. | |
751 | ||
752 | Has values of: | |
753 | ||
754 | @display | |
755 | 0 for things that don't have names. | |
756 | should be IDENTIFIER_NODE for RECORD_TYPEs UNION_TYPEs and | |
757 | ENUM_TYPEs. | |
758 | TYPE_DECL for RECORD_TYPEs, UNION_TYPEs and ENUM_TYPEs, but | |
759 | shouldn't be. | |
760 | TYPE_DECL for typedefs, unsure why. | |
761 | @end display | |
762 | ||
763 | What things can one use this on: | |
764 | ||
765 | @display | |
766 | TYPE_DECLs | |
767 | RECORD_TYPEs | |
768 | UNION_TYPEs | |
769 | ENUM_TYPEs | |
770 | @end display | |
771 | ||
772 | History: | |
773 | ||
774 | It currently points to the TYPE_DECL for RECORD_TYPEs, | |
775 | UNION_TYPEs and ENUM_TYPEs, but it should be history soon. | |
776 | ||
777 | ||
778 | @item TYPE_METHODS | |
779 | Synonym for @code{CLASSTYPE_METHOD_VEC}. Chained together with | |
780 | @code{TREE_CHAIN}. @file{dbxout.c} uses this to get at the methods of a | |
781 | class. | |
782 | ||
783 | ||
784 | @item TYPE_DECL | |
785 | Used to represent typedefs, and used to represent bindings layers. | |
786 | ||
787 | Components: | |
788 | ||
789 | DECL_NAME is the name of the typedef. For example, foo would | |
790 | be found in the DECL_NAME slot when @code{typedef int foo;} is | |
791 | seen. | |
792 | ||
793 | DECL_SOURCE_LINE identifies what source line number in the | |
794 | source file the declaration was found at. A value of 0 | |
795 | indicates that this TYPE_DECL is just an internal binding layer | |
796 | marker, and does not correspond to a user suppiled typedef. | |
797 | ||
798 | DECL_SOURCE_FILE | |
799 | ||
800 | @item TYPE_FIELDS | |
801 | A linked list (via @code{TREE_CHAIN}) of member types of a class. The | |
802 | list can contain @code{TYPE_DECL}s, but there can also be other things | |
803 | in the list apparently. See also @code{CLASSTYPE_TAGS}. | |
804 | ||
805 | ||
806 | @item TYPE_VIRTUAL_P | |
807 | A flag used on a @code{FIELD_DECL} or a @code{VAR_DECL}, indicates it is | |
808 | a virtual function table or a pointer to one. When used on a | |
809 | @code{FUNCTION_DECL}, indicates that it is a virtual function. When | |
810 | used on an @code{IDENTIFIER_NODE}, indicates that a function with this | |
811 | same name exists and has been declared virtual. | |
812 | ||
813 | When used on types, it indicates that the type has virtual functions, or | |
814 | is derived from one that does. | |
815 | ||
816 | Not sure if the above about virtual function tables is still true. See | |
817 | also info on @code{DECL_VIRTUAL_P}. | |
818 | ||
819 | What things can this be used on: | |
820 | ||
821 | FIELD_DECLs, VAR_DECLs, FUNCTION_DECLs, IDENTIFIER_NODEs | |
822 | ||
823 | ||
824 | @item VF_BASETYPE_VALUE | |
825 | Get the associated type from the binfo that caused the given vfield to | |
826 | exist. This is the least derived class (the most parent class) that | |
827 | needed a virtual function table. It is probably the case that all uses | |
828 | of this field are misguided, but they need to be examined on a | |
829 | case-by-case basis. See history for more information on why the | |
830 | previous statement was made. | |
831 | ||
832 | Set at @code{finish_base_struct} time. | |
833 | ||
834 | What things can this be used on: | |
835 | ||
836 | TREE_LISTs that are vfields | |
837 | ||
838 | History: | |
839 | ||
840 | This field was used to determine if a virtual function table's | |
841 | slot should be filled in with a certain virtual function, by | |
842 | checking to see if the type returned by VF_BASETYPE_VALUE was a | |
843 | parent of the context in which the old virtual function existed. | |
844 | This incorrectly assumes that a given type _could_ not appear as | |
845 | a parent twice in a given inheritance lattice. For single | |
846 | inheritance, this would in fact work, because a type could not | |
847 | possibly appear more than once in an inheritance lattice, but | |
848 | with multiple inheritance, a type can appear more than once. | |
849 | ||
850 | ||
851 | @item VF_BINFO_VALUE | |
852 | Identifies the binfo that caused this vfield to exist. If this vfield | |
853 | is from the first direct base class that has a virtual function table, | |
854 | then VF_BINFO_VALUE is NULL_TREE, otherwise it will be the binfo of the | |
855 | direct base where the vfield came from. Can use @code{TREE_VIA_VIRTUAL} | |
856 | on result to find out if it is a virtual base class. Related to the | |
857 | binfo found by | |
858 | ||
859 | @example | |
860 | get_binfo (VF_BASETYPE_VALUE (vfield), t, 0) | |
861 | @end example | |
862 | ||
863 | @noindent | |
864 | where @samp{t} is the type that has the given vfield. | |
865 | ||
866 | @example | |
867 | get_binfo (VF_BASETYPE_VALUE (vfield), t, 0) | |
868 | @end example | |
869 | ||
870 | @noindent | |
871 | will return the binfo for the the given vfield. | |
872 | ||
873 | May or may not be set at @code{modify_vtable_entries} time. Set at | |
874 | @code{finish_base_struct} time. | |
875 | ||
876 | What things can this be used on: | |
877 | ||
878 | TREE_LISTs that are vfields | |
879 | ||
880 | ||
881 | @item VF_DERIVED_VALUE | |
882 | Identifies the type of the most derived class of the vfield, excluding | |
883 | the the class this vfield is for. | |
884 | ||
885 | Set at @code{finish_base_struct} time. | |
886 | ||
887 | What things can this be used on: | |
888 | ||
889 | TREE_LISTs that are vfields | |
890 | ||
891 | ||
892 | @item VF_NORMAL_VALUE | |
893 | Identifies the type of the most derived class of the vfield, including | |
894 | the class this vfield is for. | |
895 | ||
896 | Set at @code{finish_base_struct} time. | |
897 | ||
898 | What things can this be used on: | |
899 | ||
900 | TREE_LISTs that are vfields | |
901 | ||
902 | ||
903 | @item WRITABLE_VTABLES | |
904 | This is a option that can be defined when building the compiler, that | |
905 | will cause the compiler to output vtables into the data segment so that | |
906 | the vtables maybe written. This is undefined by default, because | |
907 | normally the vtables should be unwritable. People that implement object | |
908 | I/O facilities may, or people that want to change the dynamic type of | |
909 | objects may want to have the vtables writable. Another way of achieving | |
910 | this would be to make a copy of the vtable into writable memory, but the | |
911 | drawback there is that that method only changes the type for one object. | |
912 | ||
913 | @end table | |
914 | ||
915 | @node Typical Behavior, Coding Conventions, Macros, Top | |
916 | @section Typical Behavior | |
917 | ||
918 | @cindex parse errors | |
919 | ||
920 | Whenever seemingly normal code fails with errors like | |
921 | @code{syntax error at `\@{'}, it's highly likely that grokdeclarator is | |
922 | returning a NULL_TREE for whatever reason. | |
923 | ||
924 | @node Coding Conventions, Templates, Typical Behavior, Top | |
925 | @section Coding Conventions | |
926 | ||
927 | It should never be that case that trees are modified in-place by the | |
928 | back-end, @emph{unless} it is guaranteed that the semantics are the same | |
929 | no matter how shared the tree structure is. @file{fold-const.c} still | |
930 | has some cases where this is not true, but rms hypothesizes that this | |
931 | will never be a problem. | |
932 | ||
933 | @node Templates, Access Control, Coding Conventions, Top | |
934 | @section Templates | |
935 | ||
936 | g++ uses the simple approach to instantiating templates: it blindly | |
937 | generates the code for each instantiation as needed. For class | |
938 | templates, g++ pushes the template parameters into the namespace for the | |
939 | duration of the instantiation; for function templates, it's a simple | |
940 | search and replace. | |
941 | ||
942 | This approach does not support any of the template definition-time error | |
943 | checking that is being bandied about by X3J16. It makes no attempt to deal | |
944 | with name binding in a consistent way. | |
945 | ||
946 | Instantiation of a class template is triggered by the use of a template | |
947 | class anywhere but in a straight declaration like @code{class A<int>}. | |
948 | This is wrong; in fact, it should not be triggered by typedefs or | |
949 | declarations of pointers. Now that explicit instantiation is supported, | |
950 | this misfeature is not necessary. | |
951 | ||
952 | Important functions: | |
953 | ||
954 | @table @code | |
955 | @item instantiate_class_template | |
956 | This function | |
957 | @end table | |
958 | ||
959 | @node Access Control, Error Reporting, Templates, Top | |
960 | @section Access Control | |
961 | The function compute_access returns one of three values: | |
962 | ||
963 | @table @code | |
964 | @item access_public | |
965 | means that the field can be accessed by the current lexical scope. | |
966 | ||
967 | @item access_protected | |
968 | means that the field cannot be accessed by the current lexical scope | |
969 | because it is protected. | |
970 | ||
971 | @item access_private | |
972 | means that the field cannot be accessed by the current lexical scope | |
973 | because it is private. | |
974 | @end table | |
975 | ||
976 | DECL_ACCESS is used for access declarations; alter_access creates a list | |
977 | of types and accesses for a given decl. | |
978 | ||
979 | Formerly, DECL_@{PUBLIC,PROTECTED,PRIVATE@} corresponded to the return | |
980 | codes of compute_access and were used as a cache for compute_access. | |
981 | Now they are not used at all. | |
982 | ||
983 | TREE_PROTECTED and TREE_PRIVATE are used to record the access levels | |
984 | granted by the containing class. BEWARE: TREE_PUBLIC means something | |
985 | completely unrelated to access control! | |
986 | ||
987 | @node Error Reporting, Concept Index, Access Control, Top | |
988 | @section Error Reporting | |
989 | ||
990 | The C++ frontend uses a call-back mechanism to allow functions to print | |
991 | out reasonable strings for types and functions without putting extra | |
992 | logic in the functions where errors are found. The interface is through | |
993 | the @code{cp_error} function (or @code{cp_warning}, etc.). The | |
994 | syntax is exactly like that of @code{error}, except that a few more | |
995 | conversions are supported: | |
996 | ||
997 | @itemize @bullet | |
998 | @item | |
999 | %C indicates a value of `enum tree_code'. | |
1000 | @item | |
1001 | %D indicates a *_DECL node. | |
1002 | @item | |
1003 | %E indicates a *_EXPR node. | |
1004 | @item | |
1005 | %L indicates a value of `enum languages'. | |
1006 | @item | |
1007 | %P indicates the name of a parameter (i.e. "this", "1", "2", ...) | |
1008 | @item | |
1009 | %T indicates a *_TYPE node. | |
1010 | @item | |
1011 | %O indicates the name of an operator (MODIFY_EXPR -> "operator ="). | |
1012 | ||
1013 | @end itemize | |
1014 | ||
1015 | There is some overlap between these; for instance, any of the node | |
1016 | options can be used for printing an identifier (though only @code{%D} | |
1017 | tries to decipher function names). | |
1018 | ||
1019 | For a more verbose message (@code{class foo} as opposed to just @code{foo}, | |
1020 | including the return type for functions), use @code{%#c}. | |
1021 | To have the line number on the error message indicate the line of the | |
1022 | DECL, use @code{cp_error_at} and its ilk; to indicate which argument you want, | |
1023 | use @code{%+D}, or it will default to the first. | |
1024 | ||
1025 | @node Concept Index, , Error Reporting, Top | |
1026 | @section Concept Index | |
1027 | ||
1028 | @printindex cp | |
1029 | ||
1030 | @bye |