In the following code, an alias is defined to allow all child classes to access the member "beep" by the name "boop." The code below compiles just fine, links just fine, and runs just fine.
abstract class Parent
{
alias boop = beep;
abstract string beep();
}
class Child : Parent
{
override string beep() { return "BEEP"; }
}
void main ()
{
import std.stdio : writeln;
writeln((new Child()).boop);
}
However, if the Child class is made "final," the generated object(s) is(are) unlinkable. From the command line, the error appears like so:
$ dmd ./sanity/test.d
Undefined symbols for architecture x86_64:
"_D4test6Parent4beepMFZAya", referenced from:
__Dmain in test.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error: linker exited with status 1
This is all in the same file, so the fact that I even get a linker error in the first place is pretty weird.
Is this expected behavior?
System information:
Uname -a: Darwin <hostname> 15.6.0 Darwin Kernel Version 15.6.0: Sun Jun 4 21:43:07 PDT 2017; root:xnu-3248.70.3~1/RELEASE_X86_64 x86_64
Operating System: Mac OS X El Capitan 10.11.6
Processor: 1.4 GHz Intel Core i5
DMD --version: DMD64 D Compiler v2.076.0-dirty
ld -v:
@(#)PROGRAM:ld PROJECT:ld64-274.1
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
LTO support using: LLVM version 8.0.0, (clang-800.0.38)
TAPI support using: Apple TAPI version 1.30
clang --version:
Apple LLVM version 8.0.0 (clang-800.0.38)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
I may be able to test this on a Windows or a Linux machine soon, and I will post the results if I do.
Comment #1 by simen.kjaras — 2017-10-17T12:58:35Z
Same results on Win32 and Win64.
Child.boop.mangleof gives the same result as Parent.boop.mangleof, regardless of final keyword, and matches the missing symbol.
Interestingly, taking the address of (new Child()).boop and calling that works fine:
writeln((&(new Child()).boop)());
No, this is not expected behavior.
Comment #2 by razvan.nitu1305 — 2023-07-19T11:06:32Z
Comment #3 by razvan.nitu1305 — 2023-07-19T11:49:42Z
Well, you are specifically trying to call a function that has no body, so I would argue that the linker error is correct behavior since you could potentially provide the implementation of Parent.beep in a different place. The fact that taking the address compiles is weird though.
Comment #4 by b2.temp — 2023-09-08T22:54:22Z
One possible fix could be to re-resolve the function using the scope given by `new Child()`
Comment #5 by robert.schadek — 2024-12-13T18:54:54Z