Inherited aliases produce unlinkable objects in final classes

[dlangBugzillaToGithub]

Jonathan Wilbur reported this on 2017-10-17T12:27:53Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=17909

CC List

• basile-z
• Jonathan Wilbur
• RazvanN
• Simen Kjaeraas

Description

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.

[dlangBugzillaToGithub]

simen.kjaras commented on 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.

[dlangBugzillaToGithub]

razvan.nitu1305 commented on 2023-07-19T11:06:32Z

Regression introduced by: https://github.com/dlang/dmd/pull/4427

[dlangBugzillaToGithub]

razvan.nitu1305 commented on 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.

[dlangBugzillaToGithub]

b2.temp commented on 2023-09-08T22:54:22Z

One possible fix could be to re-resolve the function using the scope given by `new Child()`