Bug 17968 – [REG 2.073] object initializer omitted when it should be included.

Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2017-11-06T01:34:12Z
Last change time
2018-06-03T18:30:14Z
Keywords
link-failure, pull
Assigned to
No Owner
Creator
Steven Schveighoffer
See also
https://issues.dlang.org/show_bug.cgi?id=18833

Comments

Comment #0 by schveiguy — 2017-11-06T01:34:12Z
I need to reduce this more. But I can't figure out easily what the trigger is. It has something to do with the auto return. Just wanting to put a bug in place so it's not forgotten. Here is the gist of the situation: I have one library that depends on another. In the first library I have a function like so: auto openDev(int fd) { return ioObject(File(fd)); } ioObject is from another library that looks like this: IOObject!IO ioObject(IO)(IO io) { return new IOObject!IO(io.move); } Where IOObject is a templated class. In a program I am compiling, I have a statement that uses openDev(0). If I compile this, I get a missing symbol, which is this: _D50TypeInfo_xC3std2io__T8IOObjectTSQvQt4file4FileZQBa6__initZ This is the initializer for the IOObject!File, that the ioObject is instantiating. However, it is never instantiated in either library. If I change the auto return to returning IOObject!File, it links and compiles. At that point, the object file of the executable (not either of the libraries) *defines* the symbol (in one case, nm says the symbol is undefined, in the successful case, it says it's defined). I'm not sure what the difference is, but clearly it should define it either way, it shouldn't look to the libraries to define it. I tried reducing to a simple 2-library solution with some simplified code. This did not exhibit the problem. The libraries in question don't compile on anything earlier than 2.076.0, so I am going to work around these issues to see if this ever worked.
Comment #1 by schveiguy — 2017-11-06T01:43:56Z
2.075.0 still has the same problem.
Comment #2 by schveiguy — 2017-11-06T04:19:40Z
Used dustmite to reduce, then hand-reduced further. Does not require 2 libs, but it does require the 2 calls into the lib (both openDev and bufd). openDev must return auto. Files are as follows: mod1.d: module mod1; struct File { } class IOObject(IO) { } /// IFTI construction helper for `IOObject` IOObject!IO ioObject(IO)() { return new IOObject!IO; } struct BufferedInputSource(Source) { Source dev; } BufferedInputSource!Source bufd(Source)(Source s) { return BufferedInputSource!Source(); } auto openDev(int ) { return ioObject!File(); } app.d: import mod1; void main() { openDev(0).bufd; } execute these commands: dmd -lib -ofthelib.a mod1.d dmd app.d thelib.a This fails as of 2.073.0. Version 2.072.2 compiles and links.
Comment #3 by schveiguy — 2017-11-06T14:42:46Z
Further reduced mod1: module mod1; class IOObject(IO) { } struct BufferedInputSource(Source) { Source dev; } BufferedInputSource!Source bufd(Source)(Source s) { return BufferedInputSource!Source(); } auto openDev(int ) { return new IOObject!int; }
Comment #4 by razvan.nitu1305 — 2018-05-04T08:58:51Z
Also, if IOObject is not templated, the code compiles.
Comment #5 by schveiguy — 2018-05-06T08:44:35Z
PR: https://github.com/dlang/dmd/pull/8222 This does not fix the root cause, I will file a new issue on that.
Comment #6 by github-bugzilla — 2018-06-03T18:30:13Z
Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/6fefecf21994bab869e2f281a4d2815a6884117a Fix issue 17968 - When generating xtoHash function for a struct, use typeid(const(Object)) for class members instead of the derived type to avoid pulling in ungenerated symbols https://github.com/dlang/dmd/commit/c69c5663d0a035ee1aacc1a1201a6de5ae6c25a4 Merge pull request #8222 from schveiguy/fix17968 Fix issue 17968 - Use typeid(Object) instead of typeid(T) to avoid pulling in unused symbols merged-on-behalf-of: unknown