https://issues.dlang.org/show_bug.cgi?id=15984

Denis Shelomovskij <verylonglogin.reg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |regression

--- Comment #1 from Denis Shelomovskij <verylonglogin.reg@gmail.com> ---
vibe.d 0.7.28+ now fails in non-release builds because of this issue. It didn't fail before, so there is a REGRESSION is dmd 2.071. Probably these contracts wasn't called before and current issue isn't really a REGRESSION but I will still temporary change this issue importance until correct REGRESSION behavior case issue is filed.

--

https://issues.dlang.org/show_bug.cgi?id=15984

--- Comment #2 from Denis Shelomovskij <verylonglogin.reg@gmail.com> ---
(In reply to Denis Shelomovskij from comment #1)
> Probably these
> contracts wasn't called before and current issue isn't really a REGRESSION
> but I will still temporary change this issue importance until correct
> REGRESSION behavior case issue is filed.

This issue is a REGRESSION, dmd 2.070 correctly passes parameters to interface contracts.

--

https://issues.dlang.org/show_bug.cgi?id=15984

Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com

--- Comment #3 from Stewart Gordon <smjg@iname.com> ---
The posted code doesn't show the problem as I try (DMD 2.071.0 Windows).  In
order to test it, one needs to make sure C's contract fails.  (Though this is
down to another issue, bug 6857.)

But even better would be to add debugging output to I's in contract.

----------
import std.stdio;

interface I
{
    void f(int i)
    in {
        writeln(i);
        assert(i == 5);
    }
}

class C : I
{
    void f(int i)
    in { assert (false); }
    body { }
}

void main()
{
    I i = new C;
    i.f(5);
}
----------
4202755

core.exception.AssertError@bz15984.d(14): Assertion failure
----------------
0x00402D3B
0x00402103
0x00403EA7
0x00403DA8
0x0040270F
0x769DD4D1 in BaseThreadInitThunk
0x77201593 in RtlInitializeExceptionChain
0x77201566 in RtlInitializeExceptionChain
----------

--

https://issues.dlang.org/show_bug.cgi?id=15984

--- Comment #4 from Denis Shelomovskij <verylonglogin.reg@gmail.com> ---
(In reply to Stewart Gordon from comment #3)
> The posted code doesn't show the problem as I try (DMD 2.071.0 Windows).  In
> order to test it, one needs to make sure C's contract fails.  (Though this
> is down to another issue, bug 6857.)

Thanks, I still can't remember how does current implementation of D contracts work.

> But even better would be to add debugging output to I's in contract.

Parameter contains garbage, I don't think there is any need to print it.

--

https://issues.dlang.org/show_bug.cgi?id=15984

--- Comment #5 from Stewart Gordon <smjg@iname.com> ---
(In reply to Denis Shelomovskij from comment #4)
> Thanks, I still can't remember how does current implementation of D contracts work.

It looks like it calls the base class's in contract and, if that fails, calls the derived class's in contract?

>> But even better would be to add debugging output to I's in contract.
> 
> Parameter contains garbage, I don't think there is any need to print it.

How do you establish that the parameter contains garbage (as opposed to any other possible cause of what we're observing) without printing it?

--

https://issues.dlang.org/show_bug.cgi?id=15984

Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull
            Summary|Interface contracts         |[REG2.071] Interface
                   |retrieve garbage instead of |contracts retrieve garbage
                   |parameters                  |instead of parameters

--- Comment #6 from Kenji Hara <k.hara.pg@gmail.com> ---
https://github.com/dlang/dmd/pull/5765

--

https://issues.dlang.org/show_bug.cgi?id=15984

Thayne <astrothayne@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |astrothayne@gmail.com

--- Comment #7 from Thayne <astrothayne@gmail.com> ---
I still see this in dmd 2.071.1, and I see similar behavior for out contracts:

---
import std.stdio;
import std.conv;
import std.algorithm : canFind;

interface I {
    string foo(int input)
        in {
            writefln("In in, input = %s", input);
        }
        out (result) {
            writefln("In out, input = %s", input);
            writefln("Result = %s", result);
            assert(result.canFind(to!string(input)));
        }
}

class C : I {
    string foo(int input) in { assert(false); } body {
        writefln("Input = %s", input);
        return "Foo " ~ to!string(input);
    }
}

void main() {
    auto c = new C;

    c.foo(5);
}
---

--

https://issues.dlang.org/show_bug.cgi?id=15984

anonymous4 <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |belka@caraus.de

--- Comment #8 from anonymous4 <dfj1esp02@sneakemail.com> ---
*** Issue 16565 has been marked as a duplicate of this issue. ***

--

https://issues.dlang.org/show_bug.cgi?id=15984

MichaelZ <dlang.org@bregalad.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dlang.org@bregalad.de

--

https://issues.dlang.org/show_bug.cgi?id=15984

--- Comment #9 from MichaelZ <dlang.org@bregalad.de> ---
If this can't be readily fixed, then what exactly must we do (or rather, not do) in our code to avoid triggering the issue?

Must we avoid using pre- (and post?) conditions in an interface at all?
Or must we avoid using pre- (and post?) conditions on 'override' functions?
Or something else entirely?

So far we've had the issue pop up roughly 4 times, some of those after making apparently unrelated changes; cleaning up the problematic places once and for all now that we have the issue in mind, will avoid frustrating bug hunting in the future...

--