On 06/04/14 14:39, Tom Tromey wrote:
"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.
Yea, maybe I need different colors, but anytime something colorizes my
first reaction is to get annoyed because I can't find what I'm looking
for. Probably a consequence of my white-on-black terminals not playing
well with the default colors.
[ OK, not entirely true, when looking at diffs a trailing whitespace
gets colorized, so I tend not to have those leak through in my own
patches anymore. ]
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?
Seems reasonable to me.
jeff
