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

Android: add better nullability checks for nullability annotations added in NDK 26 #444

Merged
merged 1 commit into from
Jan 3, 2024

Conversation

finagolfin
Copy link
Member

This is needed because Bionic recently added a bunch of these annotations. I made sure this pull doesn't break anything by testing it on linux x86_64 and with the previous NDK 25c also. I used this patch with others to build the Swift toolchain for my Android CI, finagolfin/swift-android-sdk#122, and the Termux app for Android, which now uses NDK 26b.

@@ -790,7 +790,11 @@ public final class LocalFileOutputByteStream: FileOutputByteStream {
override final func writeImpl(_ bytes: ArraySlice<UInt8>) {
bytes.withUnsafeBytes { bytesPtr in
while true {
#if os(Android)
let n = fwrite(bytesPtr.baseAddress!, 1, bytesPtr.count, filePointer)
Copy link
Member Author

Choose a reason for hiding this comment

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

This force-unwrap works fine on linux too, but I separated it out anyway in case there is concern it breaks other platforms.

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 see this done elsewhere in this repo so should be fine, doing the force unwrap on all platforms now.

Copy link

Choose a reason for hiding this comment

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

ArraySlice currently never passes a buffer with a nil baseAddress. It's arguably an implementation detail, but we rely on it in many places.

Copy link
Member Author

Choose a reason for hiding this comment

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

OK, I only modified this because the compiler complained and errored. Is there something you'd like me to change here?

Copy link

Choose a reason for hiding this comment

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

No, I just wanted to further clarify why the force unwrap is correct here.

@@ -24,7 +24,7 @@ public final class PseudoTerminal {
if openpty(&primary, &secondary, nil, nil, nil) != 0 {
return nil
}
guard let outStream = try? LocalFileOutputByteStream(filePointer: fdopen(secondary, "w"), closeOnDeinit: false) else {
guard let outStream = try? LocalFileOutputByteStream(filePointer: fdopen(secondary, "w")!, closeOnDeinit: false) else {
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 didn't bother separating this out into a guard let since it's just for the tests, can do so if wanted.

Comment on lines 494 to 495
let fpo = fopen(path.pathString, "rb")
guard let fp = fpo else {
Copy link
Member

Choose a reason for hiding this comment

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

Why not merge these two lines?

Suggested change
let fpo = fopen(path.pathString, "rb")
guard let fp = fpo else {
guard let fp = fopen(path.pathString, "rb") else {

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point, will change.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

Comment on lines 524 to 525
let fpo = fopen(path.pathString, "wb")
guard let fp = fpo else {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
let fpo = fopen(path.pathString, "wb")
guard let fp = fpo else {
guard let fp = fopen(path.pathString, "wb") else {

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

@@ -147,6 +147,9 @@ public final class Process {

/// The current OS does not support the workingDirectory API.
case workingDirectoryNotSupported

/// The stdin could not be opened.
case stdinNotOpening
Copy link
Member

Choose a reason for hiding this comment

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

What about stdinUnavailable? "not opening" is not particularly descriptive, and makes you question what happened.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

@finagolfin
Copy link
Member Author

Rebased and made the changes asked for, plus fixed an Android test.

@finagolfin
Copy link
Member Author

@kateinoigakukun, can I get a CI run here?

@kateinoigakukun
Copy link
Member

@swift-ci Please test

@neonichu neonichu merged commit 990afca into swiftlang:main Jan 3, 2024
3 checks passed
@finagolfin finagolfin deleted the droid branch January 3, 2024 18:19
finagolfin added a commit to finagolfin/swift-tools-support-core that referenced this pull request Jan 10, 2024
shahmishal pushed a commit that referenced this pull request May 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants