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
WIP: bridge BOOL to Bool #24240
WIP: bridge BOOL to Bool #24240
Conversation
CC: @DougGregor @jrose-apple - would you guys mind providing early feedback for this? It requires some tests still, but, I think will hugely improve ergonomics on Windows. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a good idea to me!
f0ea852
to
935b84c
Compare
935b84c
to
589aa12
Compare
This is largely ready for review. I want to do a re-test on my Windows machine for the tests and more importantly verify that I don't break the Foundation build with this. The latter would be a follow parallel commit to Foundation. |
589aa12
to
7bf0a75
Compare
@swift-ci please test |
Build failed |
Build failed |
7bf0a75
to
e6382e1
Compare
@swift-ci please test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excited for this improvement. Just a few commenting nits. (Note that publicly facing documentation in the Swift standard library capitalizes “Boolean,” because Boole.)
Ah, didn't know that it was being capitalised in reference to Boole - not really certain if that is proper or not, but I've changed it anyways. I didn't accept the changes since I was afraid it was going to create individual commits for the accepts. |
e6382e1
to
e0edc2f
Compare
@swift-ci please test |
lib/SIL/Bridging.cpp
Outdated
@@ -140,6 +140,9 @@ Type TypeConverter::getLoweredCBridgedType(AbstractionPattern pattern, | |||
return t; | |||
if (builtinTy->getKind() == clang::BuiltinType::UChar) | |||
return getDarwinBooleanType(); | |||
if (builtinTy->getKind() == clang::BuiltinType::Int) | |||
return getWindowsBOOLType(); | |||
// TODO(compnerd) do we need to map BOOL? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd look and see what we do for DarwinBoolean, unless you want Bool
to be exported back to Windows as BOOL
in @cdecl
functions, in which case you should look for ObjCBool. The way to test this is to try to use WindowsBool
in a @cdecl
function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I do want Bool
to be exported back to Windows as BOOL
. I will see if I can find that!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe let's do that in a follow-up patch, actually? It's not like we say @_cdecl
works anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I like that idea.
This allows the conversion of the Windows `BOOL` type to be converted to `Bool` implicitly. The implicit bridging allows for a more ergonomic use of the native Windows APIs in Swift. Due to the ambiguity between the Objective C `BOOL` and the Windows `BOOL`, we must manually map the `BOOL` type to the appropriate type. This required lifting the mapping entry for `ObjCBool` from the mapped types XMACRO definition into the inline definition in the importer. Take the opportunity to simplify the mapping code. Adjust the standard library usage of the `BOOL` type which is now eclipsed by the new `WindowsBool` type, preferring to use `Bool` whenever possible. Thanks to Jordan Rose for the suggestion to do this and a couple of hints along the way.
e0edc2f
to
83b2904
Compare
@swift-ci please test |
Build failed |
@swift-ci please test macOS platform |
Build failed |
@swift-ci please test macOS platform |
@@ -0,0 +1,30 @@ | |||
// RUN: %target-swift-frontend -typecheck %s -I %clang-importer-sdk-path/usr/include -verify | |||
// REQUIRES: OS=windows-msvc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of a REQUIRES here, can you make a fake overlay and use an explicit triple? That way we can make sure not to break this from other platforms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was trying to do that, but, I could not get enough of Bool
to make that work. I end up having to implement Bool
, Int8
, the operator groups, etc. Because the bridged type is in WinSDK, we need to build a WinSDK
module, which requires the Swift
module which requires the standard library for Windows to be stubbed out. Is there an easy trick for that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, right. We probably should have a way to do that at some point, but right now we don't. All right, never mind.
Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.
Resolves SR-NNNN.