>>>>> "Jakub" == Jakub Jelinek <ja...@redhat.com> writes:
>> +GCC_METHOD7 (gcc_decl, build_decl, >> + const char */* name */, >> + enum gcc_c_symbol_kind /* sym_kind */, >> + gcc_type /* sym_type */, >> + const char */* substitution_name */, >> + gcc_address /* address */, >> + const char */* filename */, >> + unsigned int /* line_number */) >> >> I must say that I hate the embedded comments in the signatures. >> Especially when you end up with something like: It's not so bad with colorizing but not everybody likes fruit salad. I can see how it would be pretty painful without. Jakub> Why it can't be: Jakub> GCC_METHOD7 (gcc_decl, build_decl, Jakub> const char *name, Jakub> enum gfc_c_symbol_kind sym_kind, Jakub> ... Jakub> i.e. provide comments in the form of argument names Jakub> (sure, you can't use bool for the name of the parameter then...). It's important that just the types are there. For example the .def file is used to instantiate C++ templates: #define GCC_METHOD7(R, N, A, B, C, D, E, F, G) \ rpc<R, cc1_plugin::N, A, B, C, D, E, F, G>, Here we can't have a parameter name. I chose this commenting approach since it named the parameters, albeit in comments. The "/* bool */" comments are there because gdb doesn't have a bool type, but it still seemed worthwhile to document the intent. I could drop the names and extend the various introductory comments to explain argument ordering. What do you think of that? Tom
