-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Casting function pointer directly to void and then a function pointer type causes crash. #44489
Comments
Thanks, I'll take a look at this. It's certainly not valid code no matter what: an address of expression has no type and cannot be cast to |
No problem, thanks for looking into it! I'm pretty excited for this feature.
The proposed spec says otherwise, so it might need to be updated. Specifically this part from Allow address-of to target methods:
There's a handful of code examples using this too. I specifically ran into this issue following along with the code at the end of the NativeCallableAttribute section. void* v = &CloseHandle;
delegate* cdecl<IntPtr, bool> f1 = (delegate* cdecl<IntPtr, bool>)v; |
Huh. I wrote that, but have no memory of adding it, and certainly never intended for it to be in there. |
😬 March Fred seemed to like the idea, he even mentioned it in the PR summary. Happens to the best of us. If it were up to me it'd be an error too since I'd want an error if the method signature changed. |
Why wouldn't that be legal? It works for other pointer types:
I agree it isn't necessarily "good" practice, but given pointers are implicitly convertible to
And that the speclet explicitly declares that the type of
I would fully expect |
I don't know why March Fred thought that. It's a terrible idea, it means that even introducing a non-conflicting overload could be a source-breaking change, which is just awful.
Other pointer types have a natural type. Function pointers, like other method groups, do not, therefore until there is a function pointer type we don't have a type to convert to |
Wouldn't the natural type be Otherwise, how does the language rationalize that
|
The language rationalizes it in the same way it rationalizes every method group conversion: overload resolution against a known target type. |
This may be a bit premature, but I stumbled upon it while checking out the function pointers branch. Since it only happens when you cast all on one line I thought it might be worth mentioning.
Attn: @333fred
Version Used: Current features/function-pointers head (64d1878d61ac27d5273d8277c786c375fa5c38e8) via Roslyn CI.
Steps to Reproduce:
Build this code (SharpLab)
Expected Behavior: No crash
Actual Behavior: Compiler goes bang:
Probably unnecessary, but here's the doozy of a command that MSBuild generated:
The text was updated successfully, but these errors were encountered: