Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue 11169 - __traits(isAbstractClass) prematurely sets a class to be abstract #5695

Merged
merged 1 commit into from Apr 27, 2016

Conversation

9rnsr
Copy link
Contributor

@9rnsr 9rnsr commented Apr 23, 2016

__traits(isAbstractClass) should resolve forward references of all class member functions, in order to return stable result.

@dlang-bot
Copy link
Contributor

Fix Bugzilla Description
11169 __traits(isAbstractClass) prematurely sets a class to be abstract

@@ -273,7 +273,7 @@ class ClassDeclaration : public AggregateDeclaration
bool com; // true if this is a COM class (meaning it derives from IUnknown)
bool cpp; // true if this is a C++ interface
bool isscope; // true if this is a scope class
bool isabstract; // true if abstract class
int isabstract; // 0: fwdref, 1: is abstract class, 2: not abstract
Copy link
Member

Choose a reason for hiding this comment

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

Whenever a value has more than two states, I'd really prefer it to be an enum.

Copy link
Member

Choose a reason for hiding this comment

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

Also, isabstract becomes a bad name when it is tri-state, because if (isabstract) will be true even if isabstract is 2 !

Copy link
Contributor Author

@9rnsr 9rnsr Apr 24, 2016

Choose a reason for hiding this comment

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

Changed to use enum.

@9rnsr 9rnsr force-pushed the fix11169 branch 2 times, most recently from 54392cc to 860c01e Compare April 25, 2016 01:17
@@ -8715,6 +8715,25 @@ public:
return 0;
}

override int apply2(Dsymbol_apply_ft_t fp, void* param)
Copy link
Member

Choose a reason for hiding this comment

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

My problem with this PR is the addition of apply2 which is the same only different from apply. I don't know why one should work on TemplateMixins and the other not. The fact that there's a difference needs to be explained, it looks like a bug.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK I checked whole dmd code. Now Dsymbol.apply is used only in:

AggregateDeclaration.determineFields
AggregateDeclaration.searchCtor()

And they are usually invoked after the scope members' semantic finished, so today they would already see resolved template mixin members.

Therefore, resolving TemplateMixin in its apply would have low risk to introduce new forward reference issues.

Let's wait auto-tester result.

Copy link
Member

Choose a reason for hiding this comment

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

Thank you. This is more like it!

…to be abstract

__traits(isAbstractClass) should resolve forward references of all class member functions, in order to return stable result.
@WalterBright
Copy link
Member

Auto-merge toggled on

@WalterBright WalterBright merged commit 1bc9bad into dlang:master Apr 27, 2016
@9rnsr 9rnsr deleted the fix11169 branch April 27, 2016 11:41
@aG0aep6G
Copy link
Contributor

Digger says this introduced a regression: https://issues.dlang.org/show_bug.cgi?id=16273

return 0;

if (fd._scope)
fd.semantic(null);
Copy link
Member

Choose a reason for hiding this comment

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

This causes a forward reference bug, https://issues.dlang.org/show_bug.cgi?id=16273

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants