Thread overview
Why this function just decides to not call another function and do its thing instead?
Sep 17, 2022
solidstate1991
Sep 17, 2022
frame
Sep 17, 2022
Ali Çehreli
September 17, 2022

Code found here: https://github.com/ZILtoid1991/newxml/blob/main/source/newxml/domimpl.d#L1984

Even changing the code to this:

auto res = firstAttr;
    while (res)
    {
        if (res.localName != localName || res.namespaceURI != namespaceURI)
            res = res._nextAttr;
        else
            break;
    }
    return res;

Does not always seem to call this: https://github.com/ZILtoid1991/newxml/blob/main/source/newxml/domstring.d#L252

And then instead just decides that the localName and namespaceURI pairs are not equal, and in those cases the Visual Studio debugger doesn't detect any entering into any of the DOMString.equals overrides, all while the debugger shows those strings are equal.

September 17, 2022

On Saturday, 17 September 2022 at 15:04:48 UTC, solidstate1991 wrote:

>

And then instead just decides that the localName and namespaceURI pairs are not equal, and in those cases the Visual Studio debugger doesn't detect any entering into any of the DOMString.equals overrides, all while the debugger shows those strings are equal.

opEquals probably was not called if an operand was null. It seems that Attr.localName can return null.

September 17, 2022
On 9/17/22 10:14, frame wrote:
> On Saturday, 17 September 2022 at 15:04:48 UTC, solidstate1991 wrote:
> 
>> And then instead just decides that the `localName` and `namespaceURI` pairs are not equal, and in those cases the Visual Studio debugger doesn't detect any entering into any of the `DOMString.equals` overrides, all while the debugger shows those strings are equal.
> 
> `opEquals` probably was not called if an operand was null. It seems that `Attr.localName` can return null.

Indeed. Copying from my /usr/include/dlang/dmd/object.d:

/++
    Implementation for class opEquals override. Calls the class-defined methods after a null check.
    Please note this is not nogc right now, even if your implementation is, because of
    the typeinfo name string compare. This is because of dmd's dll implementation. However,
    it can infer to @safe if your class' opEquals is.
+/
bool opEquals(LHS, RHS)(LHS lhs, RHS rhs) if (is(LHS : const Object) && is(RHS : const Object))
{
    static if (__traits(compiles, lhs.opEquals(rhs)) && __traits(compiles, rhs.opEquals(lhs)))
    {
        // If aliased to the same object or both null => equal
        if (lhs is rhs) return true;

        // If either is null => non-equal
        if (lhs is null || rhs is null) return false;

        if (!lhs.opEquals(rhs)) return false;

        // If same exact type => one call to method opEquals
        if (typeid(lhs) is typeid(rhs) ||
            !__ctfe && typeid(lhs).opEquals(typeid(rhs)))
                /* CTFE doesn't like typeid much. 'is' works, but opEquals doesn't
                (issue 7147). But CTFE also guarantees that equal TypeInfos are
                always identical. So, no opEquals needed during CTFE. */
        {
            return true;
        }

        // General case => symmetric calls to method opEquals
        return rhs.opEquals(lhs);
    }
    else
    {
        // this is a compatibility hack for the old const cast behavior
        // if none of the new overloads compile, we'll go back plain Object,
        // including casting away const. It does this through the pointer
        // to bypass any opCast that may be present on the original class.
        return .opEquals!(Object, Object)(*cast(Object*) &lhs, *cast(Object*) &rhs);

    }
}

Ali