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

Fix 21210: std.traits : isAssignable false positive on disabled copy struct #7612

Merged
merged 1 commit into from
Aug 31, 2020

Conversation

Geod24
Copy link
Member

@Geod24 Geod24 commented Aug 30, 2020

`isAssignable` would previously return `true` for non-copyable types,
even though code that tried to use an lvalue would not compile.
This behavior was originally found when implementing `-preview=in`.

With the new -preview=in check, the const-folding seemed to be a bit
too aggressive when an rvalue is passed, meaning that the check might
fail (probably due to the code that initialize the temporary).

The failure with SumType has been fixed.

…struct

`isAssignable` would previously return `true` for non-copyable types,
even though code that tried to use an lvalue would not compile.
This behavior was originally found when implementing `-preview=in`.

With the new -preview=in check, the const-folding seemed to be a bit
too aggressive when an rvalue is passed, meaning that the check might
fail (probably due to the code that initialize the temporary).
@dlang-bot
Copy link
Contributor

Thanks for your pull request, @Geod24!

Bugzilla references

Auto-close Bugzilla Severity Description
21210 normal std.traits : isAssignable false positive on disabled copy struct

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#7612"

@@ -5180,10 +5180,10 @@ enum isAssignable(Lhs, Rhs = Lhs) = isRvalueAssignable!(Lhs, Rhs) && isLvalueAss
}

// ditto
private enum isRvalueAssignable(Lhs, Rhs = Lhs) = __traits(compiles, lvalueOf!Lhs = rvalueOf!Rhs);
private enum isRvalueAssignable(Lhs, Rhs = Lhs) = __traits(compiles, { lvalueOf!Lhs = rvalueOf!Rhs; });
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't this a more of a workaround for a compiler issue?

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'm conflicted about this, because I'm not exactly sure of what code path is taken within the compiler.
However, I can see why this behavior (CTFE-ing the expression) would make sense. But it's also a fatal flaw with __traits(compiles, ...), which is not shared by is(typeof(...)). On a related not, I never understood why we added the former if we had the latter.

Copy link
Member

@wilzbach wilzbach left a comment

Choose a reason for hiding this comment

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

Fine by me (it's not the first "workaround" in Phobos and won't be the last)

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

Successfully merging this pull request may close these issues.

5 participants