Skip to content

Commit

Permalink
fix Issue 1918 - __traits(getVirtualFunctions) returns final functions
Browse files Browse the repository at this point in the history
  • Loading branch information
WalterBright committed Jan 22, 2012
1 parent 9d33103 commit d096698
Showing 1 changed file with 2 additions and 0 deletions.
2 changes: 2 additions & 0 deletions traits.dd
Original file line number Diff line number Diff line change
Expand Up @@ -152,6 +152,7 @@ $(H2 $(GNAME isVirtualFunction))

$(P Takes one argument. If that argument is a virtual function,
$(B true) is returned, otherwise $(B false).
Note that final functions are virtual.
)

---
Expand Down Expand Up @@ -375,6 +376,7 @@ $(H2 $(GNAME getVirtualFunctions))
The second argument is a string that matches the name of
one of the functions of that class.
The result is a tuple of the virtual overloads of that function.
Note that final functions are virtual.
)

---
Expand Down

16 comments on commit d096698

@andralex
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's that supposed to mean? Final functions aren't virtual unless they override something!

@yebblies
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, final functions will always have a vtable slot in D.

@andralex
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ouch. This is a bug. Has it been submitted yet?

@yebblies
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume it is, and the code just dates from when there was no final attribute. But then again, judging by Walter's commit above...?
No bug report I've ever seen. I only ran into it with my c++ linking experiments. The compiler always uses a direct call on final functions, so it's strictly an abi problem. (and __traits(getVirtualFunctions) is correct in returning final functions)

@andralex
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's also a program size issue - if a function is in the vtable it will be transitively linked in even if never used.

@andralex
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We definitely must fix this.

@yebblies
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'll adapt my patch tomorrow. It's worth pointing out that the new getVIrtualFunctions will do exactly the same thing as the new getVirtualMethods once this change is made.

@andralex
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's perfect for backward compatibility. Thanks!

@WalterBright
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Final functions that do not override anything do not get a vtbl[] slot.

@andralex
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK so should we roll this in as is?

@WalterBright
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. The changes are incorrect. Final functions are virtual if they override something. Not if they do not.

@andralex
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But wait, I recall you argued to keep this as is for backwards compatibility. (I'm referring strictly to the doc changes.)

@WalterBright
Copy link
Member Author

@WalterBright WalterBright commented on d096698 Feb 5, 2012 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andralex
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK so my understanding is that I merge this doc change.

@WalterBright
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would write it as: "Note that non-overriding final functions are considered virtual by this trait. Use getVirtualMethods and isVirtualMethod instead."

@yebblies
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My mistake, looking at the object files it seems final functions that don't override anything indeed don't get a vtbl slot. The error I found was just a problem c++ non-virtual member functions, which are not currently supported anyway.

Please sign in to comment.