-
Notifications
You must be signed in to change notification settings - Fork 191
[android] fix the android build #999
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
Conversation
@swift-ci please test |
build failures without the fix:
|
we need to import full Android module to import sub-module |
@@ -172,31 +171,46 @@ extension Platform { | |||
|
|||
static func name(forUID uid: uid_t) -> String? { | |||
withUserGroupBuffer(uid, passwd(), sizeProperty: Int32(_SC_GETPW_R_SIZE_MAX), operation: getpwuid_r) { | |||
String(cString: $0.pw_name) | |||
// Android's pw_name `char *`` is nullable, so always coerce to a nullable pointer |
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.
Just to confirm: is this property nullable on Android
because it has different semantics than the Darwin/Glibc definition (i.e. it is valid to be null whereas it's not valid on Darwin/Linux)? Or is this a potential issue with the Android module/swift overlay that we could address there to make it non-optional like Darwin/Linux?
If the difference is intentional then this seems like the best way to account for it, just want to make sure we shouldn't try to make this change to the Android module before we add complexity to this code that we don't have much unit testing for
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.
Good question! I looked over the sources for Android's libc and it looks like the situation is mixed:
pw_name
doesn't seem to be nullable , so I think it should be _Nonnull instead.pw_gecos
is typically null, so it's correct for it to be _Nullable.gr_name
doesn't seem to be nullable, so I think it should be _Nonnull instead.pw_dir
doesn't seem to be nullable, so I think it should be _Nonnul linstead.
I'll update the patch to only account for nullability in pw_gecos
in that case, and will try to re-annotate the other fields using API notes instead.
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.
Also pw_gecos
isn't available on 32 bit android, as it's a macro in headers, so I'll handle that case too.
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.
the trouble with fields like this is "when are making your claim?". even if one particular function guarantees the field won't be null, other code can pass you an instance of this struct with a null field. there's no prohibition against user code creating/mutating instances of any libc type (nor could there be, in C).
tbh, i don't think there's any particularly satisfactory answer to this question. afaik no other libc has tried adding annotations, so we can't even compare notes to be "at least consistently wrong"...
i'm listening, but this feels "WAI" to me, given that insufficient expressivity of the existing annotations.
(and if you think this is bad, check out the places where we've shrugged and said __BIONIC_COMPLICATED_NULLNESS
where the answer is "it depends on the values of other arguments" :-( )
d504ec7
to
dfc3d9d
Compare
@jmschonfeld unfortunately, it looks like Clang's API Notes do not support changing the nullability of a field in a C struct :( , and I would be unable to use API notes to fix the nullability for fields I mentioned above. I'm going to file an issue on the NDK so that they can fix it in source, but in the mean time, do you think it would be ok to land this instead, with fixed up comments that mention that we're waiting on the NDK fix? |
} | ||
} | ||
|
||
static func fullName(forUID uid: uid_t) -> String? { | ||
withUserGroupBuffer(uid, passwd(), sizeProperty: Int32(_SC_GETPW_R_SIZE_MAX), operation: getpwuid_r) { | ||
String(cString: $0.pw_gecos) | ||
#if os(Android) && (arch(i386) || arch(arm)) |
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.
Small comment: should we use _pointerBitWidth(_32)
here just so we don't have to maintain a list of 32bit architectures if this ever changes?
Unfortunate but yeah this is probably the best resolution to keep Android building in the meantime. Left one small comment but otherwise this is looking good to me based on that. |
Platform.swift regressed after 71eefee
dfc3d9d
to
dacaf23
Compare
@jmschonfeld Updated the PR as requested, and linked to the NDK issue. |
@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.
Awesome, thanks!
Platform.swift regressed after 71eefee
Platform.swift regressed after 71eefee