From: Tom Tromey <tom@tromey.com>
To: Pedro Alves <palves@redhat.com>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [RFA 08/13] Use gdbpy_ref in python.c
Date: Mon, 28 Nov 2016 23:08:00 -0000 [thread overview]
Message-ID: <87d1hfxkxk.fsf@tromey.com> (raw)
In-Reply-To: <440c1b99-6cbe-5718-90f2-c7f0215be999@redhat.com> (Pedro Alves's message of "Tue, 22 Nov 2016 17:21:30 +0000")
>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
>> Additionally, previously gdbpy_apply_type_printers would return
>> EXT_LANG_RC_ERROR if a type printer returned None. However, that
>> doesn't seem correct to me; this patch changes it to return
>> EXT_LANG_RC_NOP in this case.
Pedro> Agreed, this is what the value printers do, AFAICT from
Pedro> gdbpy_apply_val_pretty_printer.
Pedro> Does that result in user/script-visible behavior? Should
Pedro> this be covered by some test?
The caller is apply_ext_lang_type_printers and it does:
ALL_ENABLED_EXTENSION_LANGUAGES (i, extlang)
...
switch (rc)
{
...
case EXT_LANG_RC_ERROR:
return NULL;
case EXT_LANG_RC_NOP:
break;
So, error means all the subsequent printer will be skipped, but nop
means they will be considered.
I think a test case would be reasonable, but I would rather not write
it. I'm going to push this series in, but if you think the test is
required, I will write a follow-up patch to just revert this bit to the
status quo ante.
Tom
next prev parent reply other threads:[~2016-11-28 23:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-20 20:42 [RFA 00/13] series #4 of c++ in python Tom Tromey
2016-11-20 20:41 ` [RFA 06/13] Use gdbpy_ref in py-inferior.c Tom Tromey
2016-11-20 20:41 ` [RFA 01/13] Use gdbpy_ref in archpy_disassemble Tom Tromey
2016-11-20 20:41 ` [RFA 02/13] Use gdbpy_ref in gdbpy_breakpoint_cond_says_stop Tom Tromey
2016-11-20 20:41 ` [RFA 05/13] Use gdbpy_ref in py_print_frame Tom Tromey
2016-11-20 20:42 ` [RFA 10/13] Use gdbpy_ref in py-utils.c Tom Tromey
2016-11-20 20:42 ` [RFA 03/13] Use gdbpy_ref in py-cmd.c Tom Tromey
2016-11-21 22:46 ` Tom Tromey
2016-11-20 20:42 ` [RFA 09/13] Use gdbpy_ref in pyuw_object_attribute_to_pointer Tom Tromey
2016-11-20 20:42 ` [RFA 12/13] Use gdbpy_ref rather than make_cleanup_py_decref Tom Tromey
2016-11-20 20:42 ` [RFA 13/13] Remove make_cleanup_py_decref and make_cleanup_py_xdecref Tom Tromey
2016-11-22 17:27 ` Pedro Alves
2016-11-20 20:42 ` [RFA 08/13] Use gdbpy_ref in python.c Tom Tromey
2016-11-22 17:21 ` Pedro Alves
2016-11-28 23:08 ` Tom Tromey [this message]
2016-11-20 20:42 ` [RFA 07/13] Use gdbpy_ref in py-param.c Tom Tromey
2016-11-20 20:42 ` [RFA 04/13] Use gdbpy_ref in bpfinishpy_out_of_scope Tom Tromey
2016-11-20 20:48 ` [RFA 11/13] Use gdbpy_ref in enumerate_args Tom Tromey
2016-11-21 22:44 ` [RFA 00/13] series #4 of c++ in python Tom Tromey
2016-11-22 17:28 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d1hfxkxk.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox