cat > bug.d << CODE
import core.thread;
class TaskFiber : Fiber {
this() { super({}); }
State state() @trusted const nothrow { return super.state; }
}
CODE
dmd -c -o- bug
----
bug.d(7): Error: function bug.TaskFiber.state cannot override final function core.thread.Fiber.state
----
Introduced (triggered?) by changing the attributes on core.thread.Fiber.state().
https://github.com/dlang/druntime/pull/1726
Currently breaks vibe.d and a couple of projects on https://ci.dawg.eu.
Comment #1 by sludwig — 2017-02-01T09:56:06Z
It appears like all failures are due to vibe.d. Since the only reason why it overrides state() is to expose it as @safe, and it's very unlikely that anyone else did the same, I'd propose to just keep Druntime as it is in this case, but I would add a proper static-if within vibe.d.
Comment #2 by code — 2017-02-04T12:39:38Z
Not a huge fan of adapting packages to upstream breakages, b/c it requires every vibe.d user to update their dependencies.
But there doesn't seem to be a simple solution to this.
Can we do that in a vibe-d point release (i.e. 0.7.31)?
Still there seems to be a bug in the override checking of dmd, I think those should have never compiled since we don't allow overloads based on attributes.
----
cat > bug.d << CODE
class Base
{
final void foo() { }
}
class Derived : Base
{
final void foo() @trusted { }
}
CODE
dmd -c -o- bug
----
cat > bug.d << CODE
class K
{
void foo() { }
void foo() @trusted { }
}
CODE
dmd -c -o- bug
----
Comment #3 by sludwig — 2017-02-04T13:02:18Z
The workaround is in the 0.7.31-beta.2 release. I agree in general for such workarounds, but from a pragmatical point of view, the cost/benefit ratio seems to be quite favorable in this case. And most of the time it's necessary to make some changes for a new DMD release anyway, for example due to improved diagnostics.
Comment #4 by greeenify — 2017-02-21T05:46:17Z
> The workaround is in the 0.7.31-beta.2 release. I agree in general for such workarounds, but from a pragmatical point of view, the cost/benefit ratio seems to be quite favorable in this case.
FYI as far as I can tell DUB is still affected by this:
https://ci.dawg.eu/job/projects/1324/REPO=dlang%2Fdub/console
So what's the best way we can deal with this?
I guess there's no way around releasing a new DUB version with the updated vibe.d dependency?
Comment #5 by robert.schadek — 2024-12-07T13:37:13Z