Comment #0 by verylonglogin.reg — 2016-05-02T13:35:09Z
This code should run fine:
---
interface I
{
void f(int i)
in { assert(i == 5); } // Fails
}
class C : I
{
void f(int i)
in { } // To call contract
body { }
}
void main()
{
I i = new C;
i.f(5);
}
---
Note: `(new C).f(5)` fails too but let's support correct contract implementation (i.e. contract is called based on static type) in testcase.
Comment #1 by verylonglogin.reg — 2016-05-02T13:45:23Z
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.
Comment #2 by verylonglogin.reg — 2016-05-02T13:51:10Z
(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.
Comment #3 by smjg — 2016-05-02T14:25:16Z
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
[email protected](14): Assertion failure
----------------
0x00402D3B
0x00402103
0x00403EA7
0x00403DA8
0x0040270F
0x769DD4D1 in BaseThreadInitThunk
0x77201593 in RtlInitializeExceptionChain
0x77201566 in RtlInitializeExceptionChain
----------
Comment #4 by verylonglogin.reg — 2016-05-02T15:01:45Z
(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.
Comment #5 by smjg — 2016-05-02T21:35:24Z
(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?
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);
}
---
Comment #8 by dfj1esp02 — 2016-09-29T14:09:07Z
*** Issue 16565 has been marked as a duplicate of this issue. ***
Comment #9 by dlang.org — 2016-11-02T13:10:51Z
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...
An analysis of the current state of affairs, took me a while to dig through the numerous hacks, related changes and PRs.
========== Context information ==========
- Accessing upvalues (variables from outer scopes) in nested functions is currently done via 2 different mechanisms, either by passing a pointer to a GC closure [¹] or by direct-stack access [²][³]. The layouts of those 2 are very different and it would be difficult to make them identical, the former is generated by the frontend the latter by the backend.
- frequire (in contracts) gets treated like a nested function and would therefor also uses either of the access variants. At the moment frequire also supports escaping of parameters (triggers a GC closure allocation), just like a normal nested function.
- frequire of base classes/interfaces are also called as nested functions, but from the class implementing/overriding the method. So currently Derived.foo is calling Base.foo.frequire (nested in Base.foo), but uses the access method (passes sclosure or sthis pointer) for Derived.foo.frequire.
- Code for Base.foo is generated independent of any derived classes, thus the current implementation requires that all nested frequire implementations use the same access method, or that both access methods have the same memory layout. Furthermore the offsets of all accessed variables must be identical.
- Whether or not a closure for parameters and variables is allocated, depends on the individual and separately compiled, i.e. invisible, implementation of each implementing/overriding method (see issue 9383).
[¹]: [buildClosure](https://github.com/dlang/dmd/blob/e087760eda0dd0242d6edb1c4acdfea36bce8821/src/toir.d#L779)
[²]: [getEthis](https://github.com/dlang/dmd/blob/0e4152265a2e16ca49ea8ea34a82109ce6c59cbc/src/toir.d#L99)
[³]: [e2ir/SymbolExp](https://github.com/dlang/dmd/blob/e087760eda0dd0242d6edb1c4acdfea36bce8821/src/e2ir.d#L1049))
========== Recent attempts at fixing the problem ==========
Issue 9383 was somewhat fixed by https://github.com/dlang/dmd/pull/4788. This is a hack that tried to make frequire a special nested function, that will always access upvalues directly through the stack [¹].
It relies on very specific and fragile backend details of the function prologue.
- As a first step in a function with GC closure, memory will be allocated. Before calling _d_allocmemory, all parameters need to be saved to the stack.
So indeed anything that could be referenced from a nested frequire is already on the stack.
- But frequire is only called after the closure allocation has been completed, so all parameters (and variables) have already been moved to the GC closure, and the variable offsets in the frontend are adjusted accordingly.
- The forceStackAccess hack ignores those offsets, and instead uses the now stale backend offsets for the initial parameter spilling [²].
- Nobody ever told the backend, that those initial stack locations are referenced by the frontend.
This of course led to subtle bugs when trying to bend (in the frontend) how parameters are accessed (https://github.com/dlang/dmd/pull/5420/files).https://github.com/dlang/dmd/pull/5765 tries to fix `this` usage in interfaces, b/c accessing that was bend to the spilled `this` parameter in some class' function implementation. The idea of that PR is to pass the class-to-interface offset as "hidden" argument to the nested frequire function.
[¹]: https://github.com/dlang/dmd/pull/4788/files#diff-6e3ab8a500e476994f345ede433811bbR961
[²]: https://github.com/dlang/dmd/pull/4788/files#diff-6e3ab8a500e476994f345ede433811bbR982
========== Currently remaining issues ==========
- When the parameters aren't used in the implementation class, they won't get saved on the stack and the nested frequire function will find garbage instead.
This works for normal nested functions, so likely some of the frequire hacks break this.
- Adjusting the this pointer for interfaces isn't yet solved, the PR adds a lot more hacks to an already hard to maintain implementation.
- Escaping parameters in frequire, e.g. by using them in a delegate, will no longer work when being forced to use the stack access.
========== Proposed resolution ==========
- We make frequire a special nested function that always get's called with a closure. When no GC closure is needed, the closure can be allocated with the same layout on the stack.
- Allows to get rid of existing Ffakeeh, frame pointer, and function prolog hacks.
- The variable locations in the closure (on the stack) can replace any other stack location of that variable, so no overhead on stack space should be necessary. It might be somewhat tricky to get the backend to enregister variables after the frequire contracts have been validated.
- One way to support interfaces would be to set a 'this' pointer in the closure to the correct offset before each frequire call in the chain. Somewhat similar to what's already been done here [¹].
[¹]: https://github.com/dlang/dmd/blob/91f0c943368d50efe70816bc499bb8cbcbd5c9b5/src/toir.d#L171
Comment #12 by dfj1esp02 — 2017-02-06T11:00:44Z
AFAIK, normal nested function doesn't trigger closure allocation if it's only called and its delegate is not taken.
Comment #13 by code — 2017-03-28T14:03:58Z
(In reply to anonymous4 from comment #12)
> AFAIK, normal nested function doesn't trigger closure allocation if it's
> only called and its delegate is not taken.
That's why it said "special nested function", although changing all nested functions to use closures allocated on the stack or GC (depending on escaping) would get rid of the tricky direct addressing in the stacks of parent functions.
Comment #14 by kinke — 2017-03-28T21:52:48Z
> changing all nested functions to use closures allocated on the stack or GC (depending on escaping)
FWIW, that's what LDC does.
Comment #15 by robin.kupper — 2017-11-10T12:19:49Z
While the first example works now, parameters in out contracts on interface functions are still garbage.
See example https://run.dlang.io/is/c5XDwJ.
Placing the contract on the implementing function currently seems to be the only workaround.
Comment #16 by dlang.org — 2017-11-28T07:42:09Z
(In reply to robin.kupper from comment #15)
> While the first example works now, parameters in out contracts on interface
> functions are still garbage.
>
> See example https://run.dlang.io/is/c5XDwJ.
Thaynes Example is a little shorter and also still fails, including incorrect values in the "in" contract.
> Placing the contract on the implementing function currently seems to be the
> only workaround.
Is this really an issue that purely occurs with interfaces? I was under the impression that inheritance can trigger this as well, but I may be mistaken.
If you're right, then can we - pending a "real" solution - have the compiler just ignore interface contracts (and emit a warning), rather than generating bad code?
Comment #17 by default_357-line — 2018-10-25T15:16:57Z
Helpful reminder that it's Q4 2018 and DMD still generates crashing code with no warning when using a simple, officially documented and advertised language feature.