Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Iain Buclaw <ibuclaw@gdcproject.org>
To: Doug Evans <xdje42@gmail.com>
Cc: Pedro Alves <palves@redhat.com>,
	GDB Patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 2/2] [D] Remove search_parents parameter from d_lookup_symbol_imports
Date: Sat, 30 Jan 2016 13:50:00 -0000	[thread overview]
Message-ID: <CABOHX+cZd8w5D4Y8aw49otr+1yL3w0obxkG73UzS32RNMAMe9w@mail.gmail.com> (raw)
In-Reply-To: <CABOHX+c+8AJvAWzrCTpJcEHu_CU08XaP1zN9=2azVuhV9jH3WA@mail.gmail.com>

On 29 October 2015 at 16:32, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 26 October 2015 at 01:17, Doug Evans <xdje42@gmail.com> wrote:
>>> On 19 October 2015 at 17:42, Pedro Alves <palves@redhat.com> wrote:
>>>>
>>>> On 10/11/2015 01:01 PM, Iain Buclaw wrote:
>>>> > Whilst looking at part one, a moment of insight came to me and I
>>>> > realized this code is completely nonsensical.
>>>> >
>>>> > For a start, when importing modules, you don't gain access to all
>>>> > parent packages of the given module.
>>>> >
>>>> > To add some confusion, even the comment was wrong.  It doesn't even
>>>> > cater for the example given (it's d_lookup_symbol_module that walks up
>>>> > each block scope).
>>>> >
>>>> > I feel embarrassed it didn't come to me before. :-)
>>>>
>>>> The usual penance is writing test cases.  :-)
>>>>
>>>
>>> It helps if there is a compiler readily available to compile said
>>> tests.  However, there likely is a way to get around this that I'm not
>>> aware of. (Skip certain tests if a compiler doesn't exist?  ;-)
>>>
>>> With this patch though, it's all dead code.  Hard to write a test for
>>> something that is unreachable.
>>
>> Would the testsuite's DWARF assembler help here?
>> IOW, write the test in DWARF, not D.
>
> Yes, that too, it's just a process that I can foresee taking a while
> to get right.
>
> Iain.

[Apologies for the necromancing]

I've managed to finally get round to producing a reduced DWARF test
for 1/2 in this series.  However I'm not able to produce one for this,
as it's just a refactor of dead code.

Iain.


  reply	other threads:[~2016-01-30 13:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-11 12:01 Iain Buclaw
2015-10-19 15:42 ` Pedro Alves
2015-10-25 11:19   ` Iain Buclaw
2015-10-26  3:47     ` Doug Evans
2015-10-29 17:10       ` Iain Buclaw
2016-01-30 13:50         ` Iain Buclaw [this message]
2015-10-26 21:35     ` Pedro Alves
2015-10-29 17:10       ` Iain Buclaw

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=CABOHX+cZd8w5D4Y8aw49otr+1yL3w0obxkG73UzS32RNMAMe9w@mail.gmail.com \
    --to=ibuclaw@gdcproject.org \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=xdje42@gmail.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