Thread overview | ||||||||
---|---|---|---|---|---|---|---|---|
|
February 01, 2017 [Issue 17131] [Reg 2.074] Fiber.state collides with differently attributed function in derived class | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=17131 --- Comment #1 from Sönke Ludwig <sludwig@outerproduct.org> --- 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. -- |
February 04, 2017 [Issue 17131] [Reg 2.074] Fiber.state collides with differently attributed function in derived class | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=17131 --- Comment #2 from Martin Nowak <code@dawg.eu> --- 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 ---- -- |
February 04, 2017 [Issue 17131] [Reg 2.074] Fiber.state collides with differently attributed function in derived class | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=17131 --- Comment #3 from Sönke Ludwig <sludwig@outerproduct.org> --- 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. -- |
February 10, 2017 [Issue 17131] [Reg 2.074] Fiber.state collides with differently attributed function in derived class | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=17131 ZombineDev <petar.p.kirov@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |petar.p.kirov@gmail.com -- |
February 21, 2017 [Issue 17131] [Reg 2.074] Fiber.state collides with differently attributed function in derived class | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=17131 greenify <greeenify@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |greeenify@gmail.com --- Comment #4 from greenify <greeenify@gmail.com> --- > 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? -- |
December 07 [Issue 17131] [Reg 2.074] Fiber.state collides with differently attributed function in derived class | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=17131 --- Comment #5 from dlangBugzillaToGithub <robert.schadek@posteo.de> --- THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17342 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB -- |
Copyright © 1999-2021 by the D Language Foundation