This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC/RFA] Introduce new struct parse_context


I would like to introduce a new structure called "struct parse_context"
which, for now, would contain the language and radix to use when doing
some parsing. This is something that we already discussed in a more
general way.

This patch introduces:

  - struct parse_context

  - A function called "build_parse_context" that builds a parse_context
    structure from a language and radix. Eventually, when the struct
    grows, we will add more parameters to that function.

  - A macro: current_parse_context which returns a parse context using
    the current_language and the input_radix.  This is the context that
    we should be using when parsing from a function that is a "command"
    (that is a function that implements a command)

  - A macro: wrong_parse_context, which is an alias to current_parse_context.
    This macro is useful to help breaking this task into incremental changes
    and is temporary, as the FIXME explains. I am using this macro when
    I am in a context where I don't have the parse_context to be used (yet),
    to make sure that I don't forget to fix it later. Will be removed
    when the task is complete.

2007-12-17  Joel Brobecker  <>

        * expression.h (parse_context): New struct.
        (build_parse_context): Add declaration.
        (current_parse_context, wrong_parse_context): New macros.
        * parse.c (build_parse_context): New function.

Tested on x86-linux.

Depending on this patch is the following one, which introduces the
use of that structure in the parse routines.  I am putting that second
patch with the first one in order to show how all this is going to be

2007-12-17  Joel Brobecker  <>

        * expression.h (parse_expression): Add parse_context parameter.
        (parse_expression_in_context, parse_exp_1): Likewise.
        * parse.c (parse_exp_1): Add new parameter parse_context and use it.
        (parse_exp_in_context, parse_expression, parse_expression_in_context):
        * ada-lang.c: Update calls to parse_expression and parse_exp_1.
        * objc-lang.c: Likewise.
        * breakpoint.c: Likewise.
        * value.c: Likewise.
        * ax-gdb.c: Likewise.
        * tracepoint.c: Likewise.
        * wrapper.c: Likewise.
        * eval.c: Likewise.
        * varobj.c: Likewise.
        * printcmd.c: Likewise.
        * cli/cli-script.c: Likewise.
        * mi/mi-main.c: Likewise.
        * typeprint.c (whatis_exp): Add new parameter parse_context.
        Update call to parse_expression.
        (whatis_command, ptype_command): Update call to whatis_exp.
        (maintenance_print_type): Update call to parse_expression.

Also tested on x86-linux.

I would like to commit these two patches now, and work progressively
directly in the HEAD branch.  All the changes that I am making should
either not change the behavior, or make it better.  Working on HEAD
directly allows me to work progressively as time permits - I can always
find 10-15 mins to work on one "wrong_parse_context" everyday. Finding
a couple of hours is not always that easy.  Also, I think that people
will be able to follow the changes a little more easily rather than
being bombarded by a truckload of patches.

Would it be OK if I worked directly on HEAD?


Attachment: parse_context.diff
Description: Text document

Attachment: param_parse.diff
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]