1 /* Generate information regarding function declarations and definitions based
2 on information stored in GCC's tree structure. This code implements the
5 This code was written by Ron Guilmette (rfg@mcc.com).
7 Copyright (C) 1989, 1991 Free Software Foundation, Inc.
9 This file is part of GNU CC.
11 GNU CC is free software; you can redistribute it and/or modify
12 it under the terms of the GNU General Public License as published by
13 the Free Software Foundation; either version 2, or (at your option)
16 GNU CC is distributed in the hope that it will be useful,
17 but WITHOUT ANY WARRANTY; without even the implied warranty of
18 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
19 GNU General Public License for more details.
21 You should have received a copy of the GNU General Public License
22 along with GNU CC; see the file COPYING. If not, write to
23 the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */
26 #include <sys/param.h>
37 extern char* xmalloc ();
39 enum formals_style_enum
{
44 typedef enum formals_style_enum formals_style
;
47 static char* data_type
;
49 static char * concat ();
50 static char * concat3 ();
51 static char * gen_formal_list_for_type ();
52 static int deserves_ellipsis ();
53 static char * gen_formal_list_for_func_def ();
54 static char * gen_type ();
55 static char * gen_decl ();
56 void gen_aux_info_record ();
58 /* Take two strings and mash them together into a newly allocated area. */
75 ret_val
= xmalloc (size1
+ size2
+ 1);
77 strcpy (&ret_val
[size1
], s2
);
81 /* Take three strings and mash them together into a newly allocated area. */
89 int size1
, size2
, size3
;
102 ret_val
= xmalloc (size1
+ size2
+ size3
+ 1);
103 strcpy (ret_val
, s1
);
104 strcpy (&ret_val
[size1
], s2
);
105 strcpy (&ret_val
[size1
+size2
], s3
);
109 /* Given a string representing an entire type or an entire declaration
110 which only lacks the actual "data-type" specifier (at its left end),
111 affix the data-type specifier to the left end of the given type
112 specification or object declaration.
114 Because of C language weirdness, the data-type specifier (which normally
115 goes in at the very left end) may have to be slipped in just to the
116 right of any leading "const" or "volatile" qualifiers (there may be more
117 than one). Actually this may not be strictly necessary because it seems
118 that GCC (at least) accepts `<data-type> const foo;' and treats it the
119 same as `const <data-type> foo;' but people are accustomed to seeing
120 `const char *foo;' and *not* `char const *foo;' so we try to create types
121 that look as expected. */
124 affix_data_type (type_or_decl
)
127 char *p
= type_or_decl
;
128 char *qualifiers_then_data_type
;
131 /* Skip as many leading const's or volatile's as there are. */
135 if (!strncmp (p
, "volatile", 8))
140 if (!strncmp (p
, "const", 5))
148 /* p now points to the place where we can insert the data type. We have to
149 add a blank after the data-type of course. */
151 if (p
== type_or_decl
)
152 return concat3 (data_type
, " ", type_or_decl
);
156 qualifiers_then_data_type
= concat (type_or_decl
, data_type
);
158 return concat3 (qualifiers_then_data_type
, " ", p
);
161 /* Given a tree node which represents some "function type", generate the
162 source code version of a formal parameter list (of some given style) for
163 this function type. Return the whole formal parameter list (including
164 a pair of surrounding parens) as a string. Note that if the style
165 we are currently aiming for is non-ansi, then we just return a pair
166 of empty parens here. */
169 gen_formal_list_for_type (fntype
, style
)
173 char* formal_list
= "";
179 formal_type
= TYPE_ARG_TYPES (fntype
);
180 while (formal_type
&& TREE_VALUE (formal_type
) != void_type_node
)
185 formal_list
= concat (formal_list
, ", ");
187 this_type
= gen_type ("", TREE_VALUE (formal_type
), ansi
);
190 ? concat (formal_list
, affix_data_type (this_type
))
191 : concat (formal_list
, data_type
);
193 formal_type
= TREE_CHAIN (formal_type
);
196 /* If we got to here, then we are trying to generate an ANSI style formal
199 New style prototyped ANSI formal parameter lists should in theory always
200 contain some stuff between the opening and closing parens, even if it is
203 The brutal truth though is that there is lots of old K&R code out there
204 which contains declarations of "pointer-to-function" parameters and
205 these almost never have fully specified formal parameter lists associated
206 with them. That is, the pointer-to-function parameters are declared
207 with just empty parameter lists.
209 In cases such as these, protoize should really insert *something* into
210 the vacant parameter lists, but what? It has no basis on which to insert
211 anything in particular.
213 Here, we make life easy for protoize by trying to distinguish between
214 K&R empty parameter lists and new-style prototyped parameter lists
215 that actually contain "void". In the latter case we (obviously) want
216 to output the "void" verbatim, and that what we do. In the former case,
217 we do our best to give protoize something nice to insert.
219 This "something nice" should be something that is still legal (when
220 re-compiled) but something that can clearly indicate to the user that
221 more typing information (for the parameter list) should be added (by
222 hand) at some convenient moment.
224 The string chosen here is a comment with question marks in it. */
228 if (TYPE_ARG_TYPES (fntype
))
229 /* assert (TREE_VALUE (TYPE_ARG_TYPES (fntype)) == void_type_node); */
230 formal_list
= "void";
232 formal_list
= "/* ??? */";
236 /* If there were at least some parameters, and if the formals-types-list
237 petered out to a NULL (i.e. without being terminated by a
238 void_type_node) then we need to tack on an ellipsis. */
240 formal_list
= concat (formal_list
, ", ...");
243 return concat3 (" (", formal_list
, ")");
246 /* For the generation of an ANSI prototype for a function definition, we have
247 to look at the formal parameter list of the function's own "type" to
248 determine if the function's formal parameter list should end with an
249 ellipsis. Given a tree node, the following function will return non-zero
250 if the "function type" parameter list should end with an ellipsis. */
253 deserves_ellipsis (fntype
)
258 formal_type
= TYPE_ARG_TYPES (fntype
);
259 while (formal_type
&& TREE_VALUE (formal_type
) != void_type_node
)
260 formal_type
= TREE_CHAIN (formal_type
);
262 /* If there were at least some parameters, and if the formals-types-list
263 petered out to a NULL (i.e. without being terminated by a void_type_node)
264 then we need to tack on an ellipsis. */
266 return (!formal_type
&& TYPE_ARG_TYPES (fntype
));
269 /* Generate a parameter list for a function definition (in some given style).
271 Note that this routine has to be separate (and different) from the code that
272 generates the prototype parameter lists for function declarations, because
273 in the case of a function declaration, all we have to go on is a tree node
274 representing the function's own "function type". This can tell us the types
275 of all of the formal parameters for the function, but it cannot tell us the
276 actual *names* of each of the formal parameters. We need to output those
277 parameter names for each function definition.
279 This routine gets a pointer to a tree node which represents the actual
280 declaration of the given function, and this DECL node has a list of formal
281 parameter (variable) declarations attached to it. These formal parameter
282 (variable) declaration nodes give us the actual names of the formal
283 parameters for the given function definition.
285 This routine returns a string which is the source form for the entire
286 function formal parameter list. */
289 gen_formal_list_for_func_def (fndecl
, style
)
293 char* formal_list
= "";
296 formal_decl
= DECL_ARGUMENTS (fndecl
);
301 if (*formal_list
&& ((style
== ansi
) || (style
== k_and_r_names
)))
302 formal_list
= concat (formal_list
, ", ");
303 this_formal
= gen_decl (formal_decl
, 0, style
);
304 if (style
== k_and_r_decls
)
305 formal_list
= concat3 (formal_list
, this_formal
, "; ");
307 formal_list
= concat (formal_list
, this_formal
);
308 formal_decl
= TREE_CHAIN (formal_decl
);
312 if (!DECL_ARGUMENTS (fndecl
))
313 formal_list
= concat (formal_list
, "void");
314 if (deserves_ellipsis (TREE_TYPE (fndecl
)))
315 formal_list
= concat (formal_list
, ", ...");
317 if ((style
== ansi
) || (style
== k_and_r_names
))
318 formal_list
= concat3 (" (", formal_list
, ")");
322 /* Generate a string which is the source code form for a given type (t). This
323 routine is ugly and complex because the C syntax for declarations is ugly
324 and complex. This routine is straightforward so long as *no* pointer types,
325 array types, or function types are involved.
327 In the simple cases, this routine will return the (string) value which was
328 passed in as the "ret_val" argument. Usually, this starts out either as an
329 empty string, or as the name of the declared item (i.e. the formal function
332 This routine will also return with the global variable "data_type" set to
333 some string value which is the "basic" data-type of the given complete type.
334 This "data_type" string can be concatenated onto the front of the returned
335 string after this routine returns to its caller.
337 In complicated cases involving pointer types, array types, or function
338 types, the C declaration syntax requires an "inside out" approach, i.e. if
339 you have a type which is a "pointer-to-function" type, you need to handle
340 the "pointer" part first, but it also has to be "innermost" (relative to
341 the declaration stuff for the "function" type). Thus, is this case, you
342 must prepend a "(*" and append a ")" to the name of the item (i.e. formal
343 variable). Then you must append and prepend the other info for the
344 "function type" part of the overall type.
346 To handle the "innermost precedence" rules of complicated C declarators, we
347 do the following (in this routine). The input parameter called "ret_val"
348 is treated as a "seed". Each time gen_type is called (perhaps recursively)
349 some additional strings may be appended or prepended (or both) to the "seed"
350 string. If yet another (lower) level of the GCC tree exists for the given
351 type (as in the case of a pointer type, an array type, or a function type)
352 then the (wrapped) seed is passed to a (recursive) invocation of gen_type()
353 this recursive invocation may again "wrap" the (new) seed with yet more
354 declarator stuff, by appending, prepending (or both). By the time the
355 recursion bottoms out, the "seed value" at that point will have a value
356 which is (almost) the complete source version of the declarator (except
357 for the data_type info). Thus, this deepest "seed" value is simply passed
358 back up through all of the recursive calls until it is given (as the return
359 value) to the initial caller of the gen_type() routine. All that remains
360 to do at this point is for the initial caller to prepend the "data_type"
361 string onto the returned "seed". */
364 gen_type (ret_val
, t
, style
)
371 if (TYPE_NAME (t
) && DECL_NAME (TYPE_NAME (t
)))
372 data_type
= IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t
)));
375 switch (TREE_CODE (t
))
378 if (TYPE_READONLY (t
))
379 ret_val
= concat ("const ", ret_val
);
380 if (TYPE_VOLATILE (t
))
381 ret_val
= concat ("volatile ", ret_val
);
383 ret_val
= concat ("*", ret_val
);
385 if (TREE_CODE (TREE_TYPE (t
)) == ARRAY_TYPE
|| TREE_CODE (TREE_TYPE (t
)) == FUNCTION_TYPE
)
386 ret_val
= concat3 ("(", ret_val
, ")");
388 ret_val
= gen_type (ret_val
, TREE_TYPE (t
), style
);
393 ret_val
= gen_type (concat (ret_val
, "[]"), TREE_TYPE (t
), style
);
397 ret_val
= gen_type (concat (ret_val
, gen_formal_list_for_type (t
, style
)), TREE_TYPE (t
), style
);
400 case IDENTIFIER_NODE
:
401 data_type
= IDENTIFIER_POINTER (t
);
404 /* The following three cases are complicated by the fact that a
405 user may do something really stupid, like creating a brand new
406 "anonymous" type specification in a formal argument list (or as
407 part of a function return type specification). For example:
409 int f (enum { red, green, blue } color);
411 In such cases, we have no name that we can put into the prototype
412 to represent the (anonymous) type. Thus, we have to generate the
413 whole darn type specification. Yuck! */
417 data_type
= IDENTIFIER_POINTER (TYPE_NAME (t
));
421 chain_p
= TYPE_FIELDS (t
);
424 data_type
= concat (data_type
, gen_decl (chain_p
, 0, ansi
));
425 chain_p
= TREE_CHAIN (chain_p
);
426 data_type
= concat (data_type
, "; ");
428 data_type
= concat3 ("{ ", data_type
, "}");
430 data_type
= concat ("struct ", data_type
);
435 data_type
= IDENTIFIER_POINTER (TYPE_NAME (t
));
439 chain_p
= TYPE_FIELDS (t
);
442 data_type
= concat (data_type
, gen_decl (chain_p
, 0, ansi
));
443 chain_p
= TREE_CHAIN (chain_p
);
444 data_type
= concat (data_type
, "; ");
446 data_type
= concat3 ("{ ", data_type
, "}");
448 data_type
= concat ("union ", data_type
);
453 data_type
= IDENTIFIER_POINTER (TYPE_NAME (t
));
457 chain_p
= TYPE_VALUES (t
);
460 data_type
= concat (data_type
,
461 IDENTIFIER_POINTER (TREE_PURPOSE (chain_p
)));
462 chain_p
= TREE_CHAIN (chain_p
);
464 data_type
= concat (data_type
, ", ");
466 data_type
= concat3 ("{ ", data_type
, " }");
468 data_type
= concat ("enum ", data_type
);
472 data_type
= IDENTIFIER_POINTER (DECL_NAME (t
));
476 data_type
= IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t
)));
477 /* Normally, `unsigned' is part of the deal. Not so if it comes
478 with `const' or `volatile'. */
479 if (TREE_UNSIGNED (t
) && (TYPE_READONLY (t
) || TYPE_VOLATILE (t
)))
480 data_type
= concat ("unsigned ", data_type
);
484 data_type
= IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t
)));
495 if (TYPE_READONLY (t
))
496 ret_val
= concat ("const ", ret_val
);
497 if (TYPE_VOLATILE (t
))
498 ret_val
= concat ("volatile ", ret_val
);
502 /* Generate a string (source) representation of an entire entity declaration
503 (using some particular style for function types).
505 The given entity may be either a variable or a function.
507 If the "is_func_definition" parameter is non-zero, assume that the thing
508 we are generating a declaration for is a FUNCTION_DECL node which is
509 associated with a function definition. In this case, we can assume that
510 an attached list of DECL nodes for function formal arguments is present. */
513 gen_decl (decl
, is_func_definition
, style
)
515 int is_func_definition
;
519 char* outer_modifier
= "";
521 if (DECL_NAME (decl
))
522 ret_val
= IDENTIFIER_POINTER (DECL_NAME (decl
));
526 /* If we are just generating a list of names of formal parameters, we can
527 simply return the formal parameter name (with no typing information
528 attached to it) now. */
530 if (style
== k_and_r_names
)
533 /* Note that for the declaration of some entity (either a function or a
534 data object, like for instance a parameter) if the entity itself was
535 declared as either const or volatile, then const and volatile properties
536 are associated with just the declaration of the entity, and *not* with
537 the `type' of the entity. Thus, for such declared entities, we have to
538 generate the qualifiers here. */
540 if (TREE_THIS_VOLATILE (decl
))
541 ret_val
= concat ("volatile ", ret_val
);
542 if (TREE_READONLY (decl
))
543 ret_val
= concat ("const ", ret_val
);
547 /* For FUNCTION_DECL nodes, there are two possible cases here. First, if
548 this FUNCTION_DECL node was generated from a function "definition", then
549 we will have a list of DECL_NODE's, one for each of the function's formal
550 parameters. In this case, we can print out not only the types of each
551 formal, but also each formal's name. In the second case, this
552 FUNCTION_DECL node came from an actual function declaration (and *not*
553 a definition). In this case, we do nothing here because the formal
554 argument type-list will be output later, when the "type" of the function
555 is added to the string we are building. Note that the ANSI-style formal
556 parameter list is considered to be a (suffix) part of the "type" of the
559 if (TREE_CODE (decl
) == FUNCTION_DECL
&& is_func_definition
)
561 ret_val
= concat (ret_val
, gen_formal_list_for_func_def (decl
, ansi
));
563 /* Since we have already added in the formals list stuff, here we don't
564 add the whole "type" of the function we are considering (which
565 would include its parameter-list info), rather, we only add in
566 the "type" of the "type" of the function, which is really just
567 the return-type of the function (and does not include the parameter
570 ret_val
= gen_type (ret_val
, TREE_TYPE (TREE_TYPE (decl
)), style
);
573 ret_val
= gen_type (ret_val
, TREE_TYPE (decl
), style
);
575 ret_val
= affix_data_type (ret_val
);
577 if (TREE_REGDECL (decl
))
578 ret_val
= concat ("register ", ret_val
);
579 if (TREE_PUBLIC (decl
))
580 ret_val
= concat ("extern ", ret_val
);
581 if (TREE_CODE (decl
) == FUNCTION_DECL
&& !TREE_PUBLIC (decl
))
582 ret_val
= concat ("static ", ret_val
);
587 extern FILE* aux_info_file
;
589 /* Generate and write a new line of info to the aux-info (.X) file. This
590 routine is called once for each function declaration, and once for each
591 function definition (even the implicit ones). */
594 gen_aux_info_record (fndecl
, is_definition
, is_implicit
, is_prototyped
)
600 if (flag_gen_aux_info
)
602 static int compiled_from_record
= 0;
604 /* Each output .X file must have a header line. Write one now if we
605 have not yet done so. */
607 if (! compiled_from_record
++)
609 /* The first line tells which directory file names are relative to.
610 Currently, -fgen-aux-info works only for files in the working
611 directory, so just use a `.' as a placeholder for now. */
612 fprintf (aux_info_file
, "/* compiled from: . */\n");
615 /* Write the actual line of auxiliary info. */
617 fprintf (aux_info_file
, "/* %s:%d:%c%c */ %s;",
618 DECL_SOURCE_FILE (fndecl
),
619 DECL_SOURCE_LINE (fndecl
),
620 (is_implicit
) ? 'I' : (is_prototyped
) ? 'N' : 'O',
621 (is_definition
) ? 'F' : 'C',
622 gen_decl (fndecl
, is_definition
, ansi
));
624 /* If this is an explicit function declaration, we need to also write
625 out an old-style (i.e. K&R) function header, just in case the user
626 wants to run unprotoize. */
630 fprintf (aux_info_file
, " /*%s %s*/",
631 gen_formal_list_for_func_def (fndecl
, k_and_r_names
),
632 gen_formal_list_for_func_def (fndecl
, k_and_r_decls
));
635 fprintf (aux_info_file
, "\n");