Automatic link generation by doxygen
Commit Message
Nowadays, we have one page on "GDB Types" generated by doxygen, but types
and macros referenced in doc are not linked to their definitions. This
patch tweaks the comments a little to use doxygen syntax so that these
types and macros are linked their definitions.
Is it OK?
gdb:
2014-03-13 Yao Qi <yao@codesourcery.com>
* gdbtypes.h: Update comments to link to types and macros'
definitions.
---
gdb/gdbtypes.h | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
Comments
On 3/12/14 11:13 PM, Yao Qi wrote:
> Nowadays, we have one page on "GDB Types" generated by doxygen, but types
> and macros referenced in doc are not linked to their definitions. This
> patch tweaks the comments a little to use doxygen syntax so that these
> types and macros are linked their definitions.
>
> Is it OK?
Yes, this is good, thanks!
(I was a little hesitant at first, as adding '#' to every macro
reference in GDB seems pretty invasive :-) , but this is just the
overview block comment, for which additional markup seems reasonable.)
Stan
stan@codesourcery.com
>
> gdb:
>
> 2014-03-13 Yao Qi <yao@codesourcery.com>
>
> * gdbtypes.h: Update comments to link to types and macros'
> definitions.
> ---
> gdb/gdbtypes.h | 15 ++++++++-------
> 1 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/gdb/gdbtypes.h b/gdb/gdbtypes.h
> index c6943ef..9c9423e 100644
> --- a/gdb/gdbtypes.h
> +++ b/gdb/gdbtypes.h
> @@ -28,18 +28,19 @@
> languages using a common representation defined in gdbtypes.h.
>
> The main data structure is main_type; it consists of a code (such
> - as TYPE_CODE_ENUM for enumeration types), a number of
> + as #TYPE_CODE_ENUM for enumeration types), a number of
> generally-useful fields such as the printable name, and finally a
> - field type_specific that is a union of info specific to particular
> - languages or other special cases (such as calling convention).
> + field main_type::type_specific that is a union of info specific to
> + particular languages or other special cases (such as calling
> + convention).
>
> - The available type codes are defined in enum type_code. The enum
> + The available type codes are defined in enum #type_code. The enum
> includes codes both for types that are common across a variety
> of languages, and for types that are language-specific.
>
> - Most accesses to type fields go through macros such as TYPE_CODE
> - and TYPE_FN_FIELD_CONST. These are written such that they can be
> - used as both rvalues and lvalues.
> + Most accesses to type fields go through macros such as
> + #TYPE_CODE(thistype) and #TYPE_FN_FIELD_CONST(thisfn, n). These are
> + written such that they can be used as both rvalues and lvalues.
> */
>
> #include "hashtab.h"
>
@@ -28,18 +28,19 @@
languages using a common representation defined in gdbtypes.h.
The main data structure is main_type; it consists of a code (such
- as TYPE_CODE_ENUM for enumeration types), a number of
+ as #TYPE_CODE_ENUM for enumeration types), a number of
generally-useful fields such as the printable name, and finally a
- field type_specific that is a union of info specific to particular
- languages or other special cases (such as calling convention).
+ field main_type::type_specific that is a union of info specific to
+ particular languages or other special cases (such as calling
+ convention).
- The available type codes are defined in enum type_code. The enum
+ The available type codes are defined in enum #type_code. The enum
includes codes both for types that are common across a variety
of languages, and for types that are language-specific.
- Most accesses to type fields go through macros such as TYPE_CODE
- and TYPE_FN_FIELD_CONST. These are written such that they can be
- used as both rvalues and lvalues.
+ Most accesses to type fields go through macros such as
+ #TYPE_CODE(thistype) and #TYPE_FN_FIELD_CONST(thisfn, n). These are
+ written such that they can be used as both rvalues and lvalues.
*/
#include "hashtab.h"