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-2015 Free Software Foundation, Inc.
5 Contributed by Ron Guilmette (rfg@segfault.us.com).
7 This file is part of GCC.
9 GCC is free software; you can redistribute it and/or modify it under
10 the terms of the GNU General Public License as published by the Free
11 Software Foundation; either version 3, or (at your option) any later
14 GCC is distributed in the hope that it will be useful, but WITHOUT ANY
15 WARRANTY; without even the implied warranty of MERCHANTABILITY or
16 FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
19 You should have received a copy of the GNU General Public License
20 along with GCC; see the file COPYING3. If not see
21 <http://www.gnu.org/licenses/>. */
25 #include "coretypes.h"
33 #include "double-int.h"
39 enum formals_style_enum
{
44 typedef enum formals_style_enum formals_style
;
47 static const char *data_type
;
49 static char *affix_data_type (const char *) ATTRIBUTE_MALLOC
;
50 static const char *gen_formal_list_for_type (tree
, formals_style
);
51 static const char *gen_formal_list_for_func_def (tree
, formals_style
);
52 static const char *gen_type (const char *, tree
, formals_style
);
53 static const char *gen_decl (tree
, int, formals_style
);
55 /* Given a string representing an entire type or an entire declaration
56 which only lacks the actual "data-type" specifier (at its left end),
57 affix the data-type specifier to the left end of the given type
58 specification or object declaration.
60 Because of C language weirdness, the data-type specifier (which normally
61 goes in at the very left end) may have to be slipped in just to the
62 right of any leading "const" or "volatile" qualifiers (there may be more
63 than one). Actually this may not be strictly necessary because it seems
64 that GCC (at least) accepts `<data-type> const foo;' and treats it the
65 same as `const <data-type> foo;' but people are accustomed to seeing
66 `const char *foo;' and *not* `char const *foo;' so we try to create types
67 that look as expected. */
70 affix_data_type (const char *param
)
72 char *const type_or_decl
= ASTRDUP (param
);
73 char *p
= type_or_decl
;
74 char *qualifiers_then_data_type
;
77 /* Skip as many leading const's or volatile's as there are. */
81 if (!strncmp (p
, "volatile ", 9))
86 if (!strncmp (p
, "const ", 6))
94 /* p now points to the place where we can insert the data type. We have to
95 add a blank after the data-type of course. */
97 if (p
== type_or_decl
)
98 return concat (data_type
, " ", type_or_decl
, NULL
);
102 qualifiers_then_data_type
= concat (type_or_decl
, data_type
, NULL
);
104 return reconcat (qualifiers_then_data_type
,
105 qualifiers_then_data_type
, " ", p
, NULL
);
108 /* Given a tree node which represents some "function type", generate the
109 source code version of a formal parameter list (of some given style) for
110 this function type. Return the whole formal parameter list (including
111 a pair of surrounding parens) as a string. Note that if the style
112 we are currently aiming for is non-ansi, then we just return a pair
113 of empty parens here. */
116 gen_formal_list_for_type (tree fntype
, formals_style style
)
118 const char *formal_list
= "";
124 formal_type
= TYPE_ARG_TYPES (fntype
);
125 while (formal_type
&& TREE_VALUE (formal_type
) != void_type_node
)
127 const char *this_type
;
130 formal_list
= concat (formal_list
, ", ", NULL
);
132 this_type
= gen_type ("", TREE_VALUE (formal_type
), ansi
);
134 = ((strlen (this_type
))
135 ? concat (formal_list
, affix_data_type (this_type
), NULL
)
136 : concat (formal_list
, data_type
, NULL
));
138 formal_type
= TREE_CHAIN (formal_type
);
141 /* If we got to here, then we are trying to generate an ANSI style formal
144 New style prototyped ANSI formal parameter lists should in theory always
145 contain some stuff between the opening and closing parens, even if it is
148 The brutal truth though is that there is lots of old K&R code out there
149 which contains declarations of "pointer-to-function" parameters and
150 these almost never have fully specified formal parameter lists associated
151 with them. That is, the pointer-to-function parameters are declared
152 with just empty parameter lists.
154 In cases such as these, protoize should really insert *something* into
155 the vacant parameter lists, but what? It has no basis on which to insert
156 anything in particular.
158 Here, we make life easy for protoize by trying to distinguish between
159 K&R empty parameter lists and new-style prototyped parameter lists
160 that actually contain "void". In the latter case we (obviously) want
161 to output the "void" verbatim, and that what we do. In the former case,
162 we do our best to give protoize something nice to insert.
164 This "something nice" should be something that is still valid (when
165 re-compiled) but something that can clearly indicate to the user that
166 more typing information (for the parameter list) should be added (by
167 hand) at some convenient moment.
169 The string chosen here is a comment with question marks in it. */
173 if (prototype_p (fntype
))
174 /* assert (TREE_VALUE (TYPE_ARG_TYPES (fntype)) == void_type_node); */
175 formal_list
= "void";
177 formal_list
= "/* ??? */";
181 /* If there were at least some parameters, and if the formals-types-list
182 petered out to a NULL (i.e. without being terminated by a
183 void_type_node) then we need to tack on an ellipsis. */
185 formal_list
= concat (formal_list
, ", ...", NULL
);
188 return concat (" (", formal_list
, ")", NULL
);
191 /* Generate a parameter list for a function definition (in some given style).
193 Note that this routine has to be separate (and different) from the code that
194 generates the prototype parameter lists for function declarations, because
195 in the case of a function declaration, all we have to go on is a tree node
196 representing the function's own "function type". This can tell us the types
197 of all of the formal parameters for the function, but it cannot tell us the
198 actual *names* of each of the formal parameters. We need to output those
199 parameter names for each function definition.
201 This routine gets a pointer to a tree node which represents the actual
202 declaration of the given function, and this DECL node has a list of formal
203 parameter (variable) declarations attached to it. These formal parameter
204 (variable) declaration nodes give us the actual names of the formal
205 parameters for the given function definition.
207 This routine returns a string which is the source form for the entire
208 function formal parameter list. */
211 gen_formal_list_for_func_def (tree fndecl
, formals_style style
)
213 const char *formal_list
= "";
216 formal_decl
= DECL_ARGUMENTS (fndecl
);
219 const char *this_formal
;
221 if (*formal_list
&& ((style
== ansi
) || (style
== k_and_r_names
)))
222 formal_list
= concat (formal_list
, ", ", NULL
);
223 this_formal
= gen_decl (formal_decl
, 0, style
);
224 if (style
== k_and_r_decls
)
225 formal_list
= concat (formal_list
, this_formal
, "; ", NULL
);
227 formal_list
= concat (formal_list
, this_formal
, NULL
);
228 formal_decl
= TREE_CHAIN (formal_decl
);
232 if (!DECL_ARGUMENTS (fndecl
))
233 formal_list
= concat (formal_list
, "void", NULL
);
234 if (stdarg_p (TREE_TYPE (fndecl
)))
235 formal_list
= concat (formal_list
, ", ...", NULL
);
237 if ((style
== ansi
) || (style
== k_and_r_names
))
238 formal_list
= concat (" (", formal_list
, ")", NULL
);
242 /* Generate a string which is the source code form for a given type (t). This
243 routine is ugly and complex because the C syntax for declarations is ugly
244 and complex. This routine is straightforward so long as *no* pointer types,
245 array types, or function types are involved.
247 In the simple cases, this routine will return the (string) value which was
248 passed in as the "ret_val" argument. Usually, this starts out either as an
249 empty string, or as the name of the declared item (i.e. the formal function
252 This routine will also return with the global variable "data_type" set to
253 some string value which is the "basic" data-type of the given complete type.
254 This "data_type" string can be concatenated onto the front of the returned
255 string after this routine returns to its caller.
257 In complicated cases involving pointer types, array types, or function
258 types, the C declaration syntax requires an "inside out" approach, i.e. if
259 you have a type which is a "pointer-to-function" type, you need to handle
260 the "pointer" part first, but it also has to be "innermost" (relative to
261 the declaration stuff for the "function" type). Thus, is this case, you
262 must prepend a "(*" and append a ")" to the name of the item (i.e. formal
263 variable). Then you must append and prepend the other info for the
264 "function type" part of the overall type.
266 To handle the "innermost precedence" rules of complicated C declarators, we
267 do the following (in this routine). The input parameter called "ret_val"
268 is treated as a "seed". Each time gen_type is called (perhaps recursively)
269 some additional strings may be appended or prepended (or both) to the "seed"
270 string. If yet another (lower) level of the GCC tree exists for the given
271 type (as in the case of a pointer type, an array type, or a function type)
272 then the (wrapped) seed is passed to a (recursive) invocation of gen_type()
273 this recursive invocation may again "wrap" the (new) seed with yet more
274 declarator stuff, by appending, prepending (or both). By the time the
275 recursion bottoms out, the "seed value" at that point will have a value
276 which is (almost) the complete source version of the declarator (except
277 for the data_type info). Thus, this deepest "seed" value is simply passed
278 back up through all of the recursive calls until it is given (as the return
279 value) to the initial caller of the gen_type() routine. All that remains
280 to do at this point is for the initial caller to prepend the "data_type"
281 string onto the returned "seed". */
284 gen_type (const char *ret_val
, tree t
, formals_style style
)
288 /* If there is a typedef name for this type, use it. */
289 if (TYPE_NAME (t
) && TREE_CODE (TYPE_NAME (t
)) == TYPE_DECL
)
290 data_type
= IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t
)));
293 switch (TREE_CODE (t
))
297 ret_val
= concat ("_Atomic ", ret_val
, NULL
);
298 if (TYPE_READONLY (t
))
299 ret_val
= concat ("const ", ret_val
, NULL
);
300 if (TYPE_VOLATILE (t
))
301 ret_val
= concat ("volatile ", ret_val
, NULL
);
303 ret_val
= concat ("*", ret_val
, NULL
);
305 if (TREE_CODE (TREE_TYPE (t
)) == ARRAY_TYPE
|| TREE_CODE (TREE_TYPE (t
)) == FUNCTION_TYPE
)
306 ret_val
= concat ("(", ret_val
, ")", NULL
);
308 ret_val
= gen_type (ret_val
, TREE_TYPE (t
), style
);
313 if (!COMPLETE_TYPE_P (t
) || TREE_CODE (TYPE_SIZE (t
)) != INTEGER_CST
)
314 ret_val
= gen_type (concat (ret_val
, "[]", NULL
),
315 TREE_TYPE (t
), style
);
316 else if (int_size_in_bytes (t
) == 0)
317 ret_val
= gen_type (concat (ret_val
, "[0]", NULL
),
318 TREE_TYPE (t
), style
);
322 sprintf (buff
, "[" HOST_WIDE_INT_PRINT_DEC
"]",
323 int_size_in_bytes (t
)
324 / int_size_in_bytes (TREE_TYPE (t
)));
325 ret_val
= gen_type (concat (ret_val
, buff
, NULL
),
326 TREE_TYPE (t
), style
);
331 ret_val
= gen_type (concat (ret_val
,
332 gen_formal_list_for_type (t
, style
),
334 TREE_TYPE (t
), style
);
337 case IDENTIFIER_NODE
:
338 data_type
= IDENTIFIER_POINTER (t
);
341 /* The following three cases are complicated by the fact that a
342 user may do something really stupid, like creating a brand new
343 "anonymous" type specification in a formal argument list (or as
344 part of a function return type specification). For example:
346 int f (enum { red, green, blue } color);
348 In such cases, we have no name that we can put into the prototype
349 to represent the (anonymous) type. Thus, we have to generate the
350 whole darn type specification. Yuck! */
354 data_type
= IDENTIFIER_POINTER (TYPE_NAME (t
));
358 chain_p
= TYPE_FIELDS (t
);
361 data_type
= concat (data_type
, gen_decl (chain_p
, 0, ansi
),
363 chain_p
= TREE_CHAIN (chain_p
);
364 data_type
= concat (data_type
, "; ", NULL
);
366 data_type
= concat ("{ ", data_type
, "}", NULL
);
368 data_type
= concat ("struct ", data_type
, NULL
);
373 data_type
= IDENTIFIER_POINTER (TYPE_NAME (t
));
377 chain_p
= TYPE_FIELDS (t
);
380 data_type
= concat (data_type
, gen_decl (chain_p
, 0, ansi
),
382 chain_p
= TREE_CHAIN (chain_p
);
383 data_type
= concat (data_type
, "; ", NULL
);
385 data_type
= concat ("{ ", data_type
, "}", NULL
);
387 data_type
= concat ("union ", data_type
, NULL
);
392 data_type
= IDENTIFIER_POINTER (TYPE_NAME (t
));
396 chain_p
= TYPE_VALUES (t
);
399 data_type
= concat (data_type
,
400 IDENTIFIER_POINTER (TREE_PURPOSE (chain_p
)), NULL
);
401 chain_p
= TREE_CHAIN (chain_p
);
403 data_type
= concat (data_type
, ", ", NULL
);
405 data_type
= concat ("{ ", data_type
, " }", NULL
);
407 data_type
= concat ("enum ", data_type
, NULL
);
411 data_type
= IDENTIFIER_POINTER (DECL_NAME (t
));
415 case FIXED_POINT_TYPE
:
416 data_type
= IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t
)));
417 /* Normally, `unsigned' is part of the deal. Not so if it comes
418 with a type qualifier. */
419 if (TYPE_UNSIGNED (t
) && TYPE_QUALS (t
))
420 data_type
= concat ("unsigned ", data_type
, NULL
);
424 data_type
= IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t
)));
432 data_type
= "[ERROR]";
440 ret_val
= concat ("_Atomic ", ret_val
, NULL
);
441 if (TYPE_READONLY (t
))
442 ret_val
= concat ("const ", ret_val
, NULL
);
443 if (TYPE_VOLATILE (t
))
444 ret_val
= concat ("volatile ", ret_val
, NULL
);
445 if (TYPE_RESTRICT (t
))
446 ret_val
= concat ("restrict ", ret_val
, NULL
);
450 /* Generate a string (source) representation of an entire entity declaration
451 (using some particular style for function types).
453 The given entity may be either a variable or a function.
455 If the "is_func_definition" parameter is nonzero, assume that the thing
456 we are generating a declaration for is a FUNCTION_DECL node which is
457 associated with a function definition. In this case, we can assume that
458 an attached list of DECL nodes for function formal arguments is present. */
461 gen_decl (tree decl
, int is_func_definition
, formals_style style
)
465 if (DECL_NAME (decl
))
466 ret_val
= IDENTIFIER_POINTER (DECL_NAME (decl
));
470 /* If we are just generating a list of names of formal parameters, we can
471 simply return the formal parameter name (with no typing information
472 attached to it) now. */
474 if (style
== k_and_r_names
)
477 /* Note that for the declaration of some entity (either a function or a
478 data object, like for instance a parameter) if the entity itself was
479 declared as either const or volatile, then const and volatile properties
480 are associated with just the declaration of the entity, and *not* with
481 the `type' of the entity. Thus, for such declared entities, we have to
482 generate the qualifiers here. */
484 if (TREE_THIS_VOLATILE (decl
))
485 ret_val
= concat ("volatile ", ret_val
, NULL
);
486 if (TREE_READONLY (decl
))
487 ret_val
= concat ("const ", ret_val
, NULL
);
491 /* For FUNCTION_DECL nodes, there are two possible cases here. First, if
492 this FUNCTION_DECL node was generated from a function "definition", then
493 we will have a list of DECL_NODE's, one for each of the function's formal
494 parameters. In this case, we can print out not only the types of each
495 formal, but also each formal's name. In the second case, this
496 FUNCTION_DECL node came from an actual function declaration (and *not*
497 a definition). In this case, we do nothing here because the formal
498 argument type-list will be output later, when the "type" of the function
499 is added to the string we are building. Note that the ANSI-style formal
500 parameter list is considered to be a (suffix) part of the "type" of the
503 if (TREE_CODE (decl
) == FUNCTION_DECL
&& is_func_definition
)
505 ret_val
= concat (ret_val
, gen_formal_list_for_func_def (decl
, ansi
),
508 /* Since we have already added in the formals list stuff, here we don't
509 add the whole "type" of the function we are considering (which
510 would include its parameter-list info), rather, we only add in
511 the "type" of the "type" of the function, which is really just
512 the return-type of the function (and does not include the parameter
515 ret_val
= gen_type (ret_val
, TREE_TYPE (TREE_TYPE (decl
)), style
);
518 ret_val
= gen_type (ret_val
, TREE_TYPE (decl
), style
);
520 ret_val
= affix_data_type (ret_val
);
522 if (TREE_CODE (decl
) != FUNCTION_DECL
&& C_DECL_REGISTER (decl
))
523 ret_val
= concat ("register ", ret_val
, NULL
);
524 if (TREE_PUBLIC (decl
))
525 ret_val
= concat ("extern ", ret_val
, NULL
);
526 if (TREE_CODE (decl
) == FUNCTION_DECL
&& !TREE_PUBLIC (decl
))
527 ret_val
= concat ("static ", ret_val
, NULL
);
532 extern FILE *aux_info_file
;
534 /* Generate and write a new line of info to the aux-info (.X) file. This
535 routine is called once for each function declaration, and once for each
536 function definition (even the implicit ones). */
539 gen_aux_info_record (tree fndecl
, int is_definition
, int is_implicit
,
542 if (flag_gen_aux_info
)
544 static int compiled_from_record
= 0;
545 expanded_location xloc
= expand_location (DECL_SOURCE_LOCATION (fndecl
));
547 /* Each output .X file must have a header line. Write one now if we
548 have not yet done so. */
550 if (!compiled_from_record
++)
552 /* The first line tells which directory file names are relative to.
553 Currently, -aux-info works only for files in the working
554 directory, so just use a `.' as a placeholder for now. */
555 fprintf (aux_info_file
, "/* compiled from: . */\n");
558 /* Write the actual line of auxiliary info. */
560 fprintf (aux_info_file
, "/* %s:%d:%c%c */ %s;",
561 xloc
.file
, xloc
.line
,
562 (is_implicit
) ? 'I' : (is_prototyped
) ? 'N' : 'O',
563 (is_definition
) ? 'F' : 'C',
564 gen_decl (fndecl
, is_definition
, ansi
));
566 /* If this is an explicit function declaration, we need to also write
567 out an old-style (i.e. K&R) function header, just in case the user
568 wants to run unprotoize. */
572 fprintf (aux_info_file
, " /*%s %s*/",
573 gen_formal_list_for_func_def (fndecl
, k_and_r_names
),
574 gen_formal_list_for_func_def (fndecl
, k_and_r_decls
));
577 fprintf (aux_info_file
, "\n");