1 /* Generate information regarding function declarations and definitions based
2 on information stored in GCC's tree structure. This code implements the
4 Copyright (C) 1989, 91, 94, 95, 97, 1998 Free Software Foundation, Inc.
5 Contributed by Ron Guilmette (rfg@segfault.us.com).
7 This file is part of GNU CC.
9 GNU CC is free software; you can redistribute it and/or modify
10 it under the terms of the GNU General Public License as published by
11 the Free Software Foundation; either version 2, or (at your option)
14 GNU CC is distributed in the hope that it will be useful,
15 but WITHOUT ANY WARRANTY; without even the implied warranty of
16 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
17 GNU General Public License for more details.
19 You should have received a copy of the GNU General Public License
20 along with GNU CC; see the file COPYING. If not, write to
21 the Free Software Foundation, 59 Temple Place - Suite 330,
22 Boston, MA 02111-1307, USA. */
30 extern char *xmalloc ();
32 enum formals_style_enum
{
37 typedef enum formals_style_enum formals_style
;
40 static char *data_type
;
42 static char *concat
PROTO((char *, char *));
43 static char *concat3
PROTO((char *, char *, char *));
44 static char *affix_data_type
PROTO((char *));
45 static char *gen_formal_list_for_type
PROTO((tree
, formals_style
));
46 static int deserves_ellipsis
PROTO((tree
));
47 static char *gen_formal_list_for_func_def
PROTO((tree
, formals_style
));
48 static char *gen_type
PROTO((char *, tree
, formals_style
));
49 static char *gen_decl
PROTO((tree
, int, formals_style
));
51 /* Take two strings and mash them together into a newly allocated area. */
68 ret_val
= xmalloc (size1
+ size2
+ 1);
70 strcpy (&ret_val
[size1
], s2
);
74 /* Take three strings and mash them together into a newly allocated area. */
82 int size1
, size2
, size3
;
95 ret_val
= xmalloc (size1
+ size2
+ size3
+ 1);
97 strcpy (&ret_val
[size1
], s2
);
98 strcpy (&ret_val
[size1
+size2
], s3
);
102 /* Given a string representing an entire type or an entire declaration
103 which only lacks the actual "data-type" specifier (at its left end),
104 affix the data-type specifier to the left end of the given type
105 specification or object declaration.
107 Because of C language weirdness, the data-type specifier (which normally
108 goes in at the very left end) may have to be slipped in just to the
109 right of any leading "const" or "volatile" qualifiers (there may be more
110 than one). Actually this may not be strictly necessary because it seems
111 that GCC (at least) accepts `<data-type> const foo;' and treats it the
112 same as `const <data-type> foo;' but people are accustomed to seeing
113 `const char *foo;' and *not* `char const *foo;' so we try to create types
114 that look as expected. */
117 affix_data_type (type_or_decl
)
120 char *p
= type_or_decl
;
121 char *qualifiers_then_data_type
;
124 /* Skip as many leading const's or volatile's as there are. */
128 if (!strncmp (p
, "volatile ", 9))
133 if (!strncmp (p
, "const ", 6))
141 /* p now points to the place where we can insert the data type. We have to
142 add a blank after the data-type of course. */
144 if (p
== type_or_decl
)
145 return concat3 (data_type
, " ", type_or_decl
);
149 qualifiers_then_data_type
= concat (type_or_decl
, data_type
);
151 return concat3 (qualifiers_then_data_type
, " ", p
);
154 /* Given a tree node which represents some "function type", generate the
155 source code version of a formal parameter list (of some given style) for
156 this function type. Return the whole formal parameter list (including
157 a pair of surrounding parens) as a string. Note that if the style
158 we are currently aiming for is non-ansi, then we just return a pair
159 of empty parens here. */
162 gen_formal_list_for_type (fntype
, style
)
166 char *formal_list
= "";
172 formal_type
= TYPE_ARG_TYPES (fntype
);
173 while (formal_type
&& TREE_VALUE (formal_type
) != void_type_node
)
178 formal_list
= concat (formal_list
, ", ");
180 this_type
= gen_type ("", TREE_VALUE (formal_type
), ansi
);
182 = ((strlen (this_type
))
183 ? concat (formal_list
, affix_data_type (this_type
))
184 : concat (formal_list
, data_type
));
186 formal_type
= TREE_CHAIN (formal_type
);
189 /* If we got to here, then we are trying to generate an ANSI style formal
192 New style prototyped ANSI formal parameter lists should in theory always
193 contain some stuff between the opening and closing parens, even if it is
196 The brutal truth though is that there is lots of old K&R code out there
197 which contains declarations of "pointer-to-function" parameters and
198 these almost never have fully specified formal parameter lists associated
199 with them. That is, the pointer-to-function parameters are declared
200 with just empty parameter lists.
202 In cases such as these, protoize should really insert *something* into
203 the vacant parameter lists, but what? It has no basis on which to insert
204 anything in particular.
206 Here, we make life easy for protoize by trying to distinguish between
207 K&R empty parameter lists and new-style prototyped parameter lists
208 that actually contain "void". In the latter case we (obviously) want
209 to output the "void" verbatim, and that what we do. In the former case,
210 we do our best to give protoize something nice to insert.
212 This "something nice" should be something that is still valid (when
213 re-compiled) but something that can clearly indicate to the user that
214 more typing information (for the parameter list) should be added (by
215 hand) at some convenient moment.
217 The string chosen here is a comment with question marks in it. */
221 if (TYPE_ARG_TYPES (fntype
))
222 /* assert (TREE_VALUE (TYPE_ARG_TYPES (fntype)) == void_type_node); */
223 formal_list
= "void";
225 formal_list
= "/* ??? */";
229 /* If there were at least some parameters, and if the formals-types-list
230 petered out to a NULL (i.e. without being terminated by a
231 void_type_node) then we need to tack on an ellipsis. */
233 formal_list
= concat (formal_list
, ", ...");
236 return concat3 (" (", formal_list
, ")");
239 /* For the generation of an ANSI prototype for a function definition, we have
240 to look at the formal parameter list of the function's own "type" to
241 determine if the function's formal parameter list should end with an
242 ellipsis. Given a tree node, the following function will return non-zero
243 if the "function type" parameter list should end with an ellipsis. */
246 deserves_ellipsis (fntype
)
251 formal_type
= TYPE_ARG_TYPES (fntype
);
252 while (formal_type
&& TREE_VALUE (formal_type
) != void_type_node
)
253 formal_type
= TREE_CHAIN (formal_type
);
255 /* If there were at least some parameters, and if the formals-types-list
256 petered out to a NULL (i.e. without being terminated by a void_type_node)
257 then we need to tack on an ellipsis. */
259 return (!formal_type
&& TYPE_ARG_TYPES (fntype
));
262 /* Generate a parameter list for a function definition (in some given style).
264 Note that this routine has to be separate (and different) from the code that
265 generates the prototype parameter lists for function declarations, because
266 in the case of a function declaration, all we have to go on is a tree node
267 representing the function's own "function type". This can tell us the types
268 of all of the formal parameters for the function, but it cannot tell us the
269 actual *names* of each of the formal parameters. We need to output those
270 parameter names for each function definition.
272 This routine gets a pointer to a tree node which represents the actual
273 declaration of the given function, and this DECL node has a list of formal
274 parameter (variable) declarations attached to it. These formal parameter
275 (variable) declaration nodes give us the actual names of the formal
276 parameters for the given function definition.
278 This routine returns a string which is the source form for the entire
279 function formal parameter list. */
282 gen_formal_list_for_func_def (fndecl
, style
)
286 char *formal_list
= "";
289 formal_decl
= DECL_ARGUMENTS (fndecl
);
294 if (*formal_list
&& ((style
== ansi
) || (style
== k_and_r_names
)))
295 formal_list
= concat (formal_list
, ", ");
296 this_formal
= gen_decl (formal_decl
, 0, style
);
297 if (style
== k_and_r_decls
)
298 formal_list
= concat3 (formal_list
, this_formal
, "; ");
300 formal_list
= concat (formal_list
, this_formal
);
301 formal_decl
= TREE_CHAIN (formal_decl
);
305 if (!DECL_ARGUMENTS (fndecl
))
306 formal_list
= concat (formal_list
, "void");
307 if (deserves_ellipsis (TREE_TYPE (fndecl
)))
308 formal_list
= concat (formal_list
, ", ...");
310 if ((style
== ansi
) || (style
== k_and_r_names
))
311 formal_list
= concat3 (" (", formal_list
, ")");
315 /* Generate a string which is the source code form for a given type (t). This
316 routine is ugly and complex because the C syntax for declarations is ugly
317 and complex. This routine is straightforward so long as *no* pointer types,
318 array types, or function types are involved.
320 In the simple cases, this routine will return the (string) value which was
321 passed in as the "ret_val" argument. Usually, this starts out either as an
322 empty string, or as the name of the declared item (i.e. the formal function
325 This routine will also return with the global variable "data_type" set to
326 some string value which is the "basic" data-type of the given complete type.
327 This "data_type" string can be concatenated onto the front of the returned
328 string after this routine returns to its caller.
330 In complicated cases involving pointer types, array types, or function
331 types, the C declaration syntax requires an "inside out" approach, i.e. if
332 you have a type which is a "pointer-to-function" type, you need to handle
333 the "pointer" part first, but it also has to be "innermost" (relative to
334 the declaration stuff for the "function" type). Thus, is this case, you
335 must prepend a "(*" and append a ")" to the name of the item (i.e. formal
336 variable). Then you must append and prepend the other info for the
337 "function type" part of the overall type.
339 To handle the "innermost precedence" rules of complicated C declarators, we
340 do the following (in this routine). The input parameter called "ret_val"
341 is treated as a "seed". Each time gen_type is called (perhaps recursively)
342 some additional strings may be appended or prepended (or both) to the "seed"
343 string. If yet another (lower) level of the GCC tree exists for the given
344 type (as in the case of a pointer type, an array type, or a function type)
345 then the (wrapped) seed is passed to a (recursive) invocation of gen_type()
346 this recursive invocation may again "wrap" the (new) seed with yet more
347 declarator stuff, by appending, prepending (or both). By the time the
348 recursion bottoms out, the "seed value" at that point will have a value
349 which is (almost) the complete source version of the declarator (except
350 for the data_type info). Thus, this deepest "seed" value is simply passed
351 back up through all of the recursive calls until it is given (as the return
352 value) to the initial caller of the gen_type() routine. All that remains
353 to do at this point is for the initial caller to prepend the "data_type"
354 string onto the returned "seed". */
357 gen_type (ret_val
, t
, style
)
364 if (TYPE_NAME (t
) && DECL_NAME (TYPE_NAME (t
)))
365 data_type
= IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t
)));
368 switch (TREE_CODE (t
))
371 if (TYPE_READONLY (t
))
372 ret_val
= concat ("const ", ret_val
);
373 if (TYPE_VOLATILE (t
))
374 ret_val
= concat ("volatile ", ret_val
);
376 ret_val
= concat ("*", ret_val
);
378 if (TREE_CODE (TREE_TYPE (t
)) == ARRAY_TYPE
|| TREE_CODE (TREE_TYPE (t
)) == FUNCTION_TYPE
)
379 ret_val
= concat3 ("(", ret_val
, ")");
381 ret_val
= gen_type (ret_val
, TREE_TYPE (t
), style
);
386 if (TYPE_SIZE (t
) == 0 || TREE_CODE (TYPE_SIZE (t
)) != INTEGER_CST
)
387 ret_val
= gen_type (concat (ret_val
, "[]"), TREE_TYPE (t
), style
);
388 else if (int_size_in_bytes (t
) == 0)
389 ret_val
= gen_type (concat (ret_val
, "[0]"), TREE_TYPE (t
), style
);
392 int size
= (int_size_in_bytes (t
) / int_size_in_bytes (TREE_TYPE (t
)));
394 sprintf (buff
, "[%d]", size
);
395 ret_val
= gen_type (concat (ret_val
, buff
),
396 TREE_TYPE (t
), style
);
401 ret_val
= gen_type (concat (ret_val
, gen_formal_list_for_type (t
, style
)), TREE_TYPE (t
), style
);
404 case IDENTIFIER_NODE
:
405 data_type
= IDENTIFIER_POINTER (t
);
408 /* The following three cases are complicated by the fact that a
409 user may do something really stupid, like creating a brand new
410 "anonymous" type specification in a formal argument list (or as
411 part of a function return type specification). For example:
413 int f (enum { red, green, blue } color);
415 In such cases, we have no name that we can put into the prototype
416 to represent the (anonymous) type. Thus, we have to generate the
417 whole darn type specification. Yuck! */
421 data_type
= IDENTIFIER_POINTER (TYPE_NAME (t
));
425 chain_p
= TYPE_FIELDS (t
);
428 data_type
= concat (data_type
, gen_decl (chain_p
, 0, ansi
));
429 chain_p
= TREE_CHAIN (chain_p
);
430 data_type
= concat (data_type
, "; ");
432 data_type
= concat3 ("{ ", data_type
, "}");
434 data_type
= concat ("struct ", data_type
);
439 data_type
= IDENTIFIER_POINTER (TYPE_NAME (t
));
443 chain_p
= TYPE_FIELDS (t
);
446 data_type
= concat (data_type
, gen_decl (chain_p
, 0, ansi
));
447 chain_p
= TREE_CHAIN (chain_p
);
448 data_type
= concat (data_type
, "; ");
450 data_type
= concat3 ("{ ", data_type
, "}");
452 data_type
= concat ("union ", data_type
);
457 data_type
= IDENTIFIER_POINTER (TYPE_NAME (t
));
461 chain_p
= TYPE_VALUES (t
);
464 data_type
= concat (data_type
,
465 IDENTIFIER_POINTER (TREE_PURPOSE (chain_p
)));
466 chain_p
= TREE_CHAIN (chain_p
);
468 data_type
= concat (data_type
, ", ");
470 data_type
= concat3 ("{ ", data_type
, " }");
472 data_type
= concat ("enum ", data_type
);
476 data_type
= IDENTIFIER_POINTER (DECL_NAME (t
));
480 data_type
= IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t
)));
481 /* Normally, `unsigned' is part of the deal. Not so if it comes
482 with `const' or `volatile'. */
483 if (TREE_UNSIGNED (t
) && (TYPE_READONLY (t
) || TYPE_VOLATILE (t
)))
484 data_type
= concat ("unsigned ", data_type
);
488 data_type
= IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t
)));
496 data_type
= "[ERROR]";
503 if (TYPE_READONLY (t
))
504 ret_val
= concat ("const ", ret_val
);
505 if (TYPE_VOLATILE (t
))
506 ret_val
= concat ("volatile ", ret_val
);
510 /* Generate a string (source) representation of an entire entity declaration
511 (using some particular style for function types).
513 The given entity may be either a variable or a function.
515 If the "is_func_definition" parameter is non-zero, assume that the thing
516 we are generating a declaration for is a FUNCTION_DECL node which is
517 associated with a function definition. In this case, we can assume that
518 an attached list of DECL nodes for function formal arguments is present. */
521 gen_decl (decl
, is_func_definition
, style
)
523 int is_func_definition
;
528 if (DECL_NAME (decl
))
529 ret_val
= IDENTIFIER_POINTER (DECL_NAME (decl
));
533 /* If we are just generating a list of names of formal parameters, we can
534 simply return the formal parameter name (with no typing information
535 attached to it) now. */
537 if (style
== k_and_r_names
)
540 /* Note that for the declaration of some entity (either a function or a
541 data object, like for instance a parameter) if the entity itself was
542 declared as either const or volatile, then const and volatile properties
543 are associated with just the declaration of the entity, and *not* with
544 the `type' of the entity. Thus, for such declared entities, we have to
545 generate the qualifiers here. */
547 if (TREE_THIS_VOLATILE (decl
))
548 ret_val
= concat ("volatile ", ret_val
);
549 if (TREE_READONLY (decl
))
550 ret_val
= concat ("const ", ret_val
);
554 /* For FUNCTION_DECL nodes, there are two possible cases here. First, if
555 this FUNCTION_DECL node was generated from a function "definition", then
556 we will have a list of DECL_NODE's, one for each of the function's formal
557 parameters. In this case, we can print out not only the types of each
558 formal, but also each formal's name. In the second case, this
559 FUNCTION_DECL node came from an actual function declaration (and *not*
560 a definition). In this case, we do nothing here because the formal
561 argument type-list will be output later, when the "type" of the function
562 is added to the string we are building. Note that the ANSI-style formal
563 parameter list is considered to be a (suffix) part of the "type" of the
566 if (TREE_CODE (decl
) == FUNCTION_DECL
&& is_func_definition
)
568 ret_val
= concat (ret_val
, gen_formal_list_for_func_def (decl
, ansi
));
570 /* Since we have already added in the formals list stuff, here we don't
571 add the whole "type" of the function we are considering (which
572 would include its parameter-list info), rather, we only add in
573 the "type" of the "type" of the function, which is really just
574 the return-type of the function (and does not include the parameter
577 ret_val
= gen_type (ret_val
, TREE_TYPE (TREE_TYPE (decl
)), style
);
580 ret_val
= gen_type (ret_val
, TREE_TYPE (decl
), style
);
582 ret_val
= affix_data_type (ret_val
);
584 if (TREE_CODE (decl
) != FUNCTION_DECL
&& DECL_REGISTER (decl
))
585 ret_val
= concat ("register ", ret_val
);
586 if (TREE_PUBLIC (decl
))
587 ret_val
= concat ("extern ", ret_val
);
588 if (TREE_CODE (decl
) == FUNCTION_DECL
&& !TREE_PUBLIC (decl
))
589 ret_val
= concat ("static ", ret_val
);
594 extern FILE *aux_info_file
;
596 /* Generate and write a new line of info to the aux-info (.X) file. This
597 routine is called once for each function declaration, and once for each
598 function definition (even the implicit ones). */
601 gen_aux_info_record (fndecl
, is_definition
, is_implicit
, is_prototyped
)
607 if (flag_gen_aux_info
)
609 static int compiled_from_record
= 0;
611 /* Each output .X file must have a header line. Write one now if we
612 have not yet done so. */
614 if (! compiled_from_record
++)
616 /* The first line tells which directory file names are relative to.
617 Currently, -aux-info works only for files in the working
618 directory, so just use a `.' as a placeholder for now. */
619 fprintf (aux_info_file
, "/* compiled from: . */\n");
622 /* Write the actual line of auxiliary info. */
624 fprintf (aux_info_file
, "/* %s:%d:%c%c */ %s;",
625 DECL_SOURCE_FILE (fndecl
),
626 DECL_SOURCE_LINE (fndecl
),
627 (is_implicit
) ? 'I' : (is_prototyped
) ? 'N' : 'O',
628 (is_definition
) ? 'F' : 'C',
629 gen_decl (fndecl
, is_definition
, ansi
));
631 /* If this is an explicit function declaration, we need to also write
632 out an old-style (i.e. K&R) function header, just in case the user
633 wants to run unprotoize. */
637 fprintf (aux_info_file
, " /*%s %s*/",
638 gen_formal_list_for_func_def (fndecl
, k_and_r_names
),
639 gen_formal_list_for_func_def (fndecl
, k_and_r_decls
));
642 fprintf (aux_info_file
, "\n");