I have a piece of code that looks like this:

https://github.com/jacob-carlborg/dstep/blob/master/clang/Visitor.d#L168

If I change that "first" function to look like this:

@property ParamCursor first ()
{
    assert(any, "Cannot get the first parameter of an empty parameter list");

    foreach (c ; this)
        return c;

    assert(0);
}

Then the last assert is hit. The return statement ends the foreach-loop but it doesn't return from the function. I have not been able to create a small test case for this.

Have I done a mistake somewhere or is this a bug in DMD?

Mac OS X, DMD 2.059 or 2.060.

-- 
/Jacob Carlborg

On 8/4/12, Jacob Carlborg <doob@me.com> wrote:
> Have I done a mistake somewhere or is this a bug in DMD?

Could be related to: http://d.puremagic.com/issues/show_bug.cgi?id=7453

IOW, maybe your opApply function needs fixing?

On 08/04/2012 06:23 PM, Jacob Carlborg wrote:
> I have a piece of code that looks like this:
>
> https://github.com/jacob-carlborg/dstep/blob/master/clang/Visitor.d#L168
>
> If I change that "first" function to look like this:
>
> @property ParamCursor first ()
> {
> assert(any, "Cannot get the first parameter of an empty parameter list");
>
> foreach (c ; this)
> return c;
>
> assert(0);
> }
>
> Then the last assert is hit. The return statement ends the foreach-loop
> but it doesn't return from the function. I have not been able to create
> a small test case for this.
>
> Have I done a mistake somewhere or is this a bug in DMD?
>
> Mac OS X, DMD 2.059 or 2.060.
>

int opApply (Delegate dg)
{
    auto result = clang_visitChildren(cursor, &visitorFunction,cast(CXClientData) &dg);
    return result == CXChildVisitResult.CXChildVisit_Break ? 1 : 0; // culprit
}

On 2012-08-04 19:08, Timon Gehr wrote:

> int opApply (Delegate dg)
> {
>      auto result = clang_visitChildren(cursor,
> &visitorFunction,cast(CXClientData) &dg);
>      return result == CXChildVisitResult.CXChildVisit_Break ? 1 : 0; //
> culprit
> }

Yes, right. I forgot about that. The Clang API doesn't really have a way to represent the difference between "break" and "return" in D. The Clang API works like this:

* Return 0 - Stop visiting children
* Return 1 - Continue visiting children
* Return 2 - Recursively visit the children

It doesn't really seem to be a way to map the difference between the break and return codes that D uses to the Clang API.

Anyone got an idea for a workaround or should I just continue to use "break" and never use "return"?

-- 
/Jacob Carlborg

On 08/04/2012 08:54 PM, Jacob Carlborg wrote:
> On 2012-08-04 19:08, Timon Gehr wrote:
>
>> int opApply (Delegate dg)
>> {
>>     auto result = clang_visitChildren(cursor,
>>     &visitorFunction,cast(CXClientData) &dg);
>>     return result == CXChildVisitResult.CXChildVisit_Break ? 1 : 0; // culprit
>> }
>
> Yes, right. I forgot about that. The Clang API doesn't really have a way
> to represent the difference between "break" and "return" in D. The Clang
> API works like this:
>
> * Return 0 - Stop visiting children
> * Return 1 - Continue visiting children
> * Return 2 - Recursively visit the children
>
> It doesn't really seem to be a way to map the difference between the
> break and return codes that D uses to the Clang API.
>
> Anyone got an idea for a workaround

bugfix.

> or should I just continue to use "break" and never use "return"?
>

Return the exit code by reference:
Pass a tuple of delegate and return value to the visitorFunction per
the CXClientData pointer and make the visitorFunction store the exit code inside the return code field. Then return that from opApply.

On 2012-08-04 22:01, Timon Gehr wrote:

> Return the exit code by reference:
> Pass a tuple of delegate and return value to the visitorFunction per
> the CXClientData pointer and make the visitorFunction store the exit
> code inside the return code field. Then return that from opApply.

That worked, thanks :)

-- 
/Jacob Carlborg