Skip to content

[android] fix the LP32 armv7/i686 android build #846

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

Merged
merged 3 commits into from
Aug 14, 2024

Conversation

hyp
Copy link
Contributor

@hyp hyp commented Aug 12, 2024

This fixes the errors related to the st_mode structure being operated on with mode_t values, and the use of pw_gecos error.

@hyp
Copy link
Contributor Author

hyp commented Aug 12, 2024

cc @compnerd

@hyp
Copy link
Contributor Author

hyp commented Aug 12, 2024

@swift-ci please test

@hyp
Copy link
Contributor Author

hyp commented Aug 13, 2024

CC @jmschonfeld

@@ -52,7 +52,7 @@ internal struct BuiltInUnicodeScalarSet {

// CFUniCharIsMemberOf
func contains(_ scalar: Unicode.Scalar) -> Bool {
let planeNo = Int((scalar.value >> 16) & 0xFF)
let planeNo = Int((scalar.value >> 16) & UInt32(0xFF))
Copy link
Contributor

Choose a reason for hiding this comment

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

Does Unicode.Scalar.value have a different type on Android than on other platforms?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, it's just that the new operator conflicts during overload resolution, with this specific instance of using & on a constant that is not typed.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, based on that it seems like the new operator has the possibility of a widespread affect across the project, and I worry that changes like this which appear arbitrary to someone not knowledgeable of the android build are likely to cause the android build to be broken quite frequently. Is there anything we can do to target that operator to just the uses we want? How unruly would it be to perform that at each bitwise-and with a mode_t rather than using a global operator?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

that should work too, let me see how invasive such change would be.

Co-authored-by: Jeremy Schonfeld <1004103+jmschonfeld@users.noreply.github.com>
@hyp
Copy link
Contributor Author

hyp commented Aug 13, 2024

@swift-ci please test

@hyp
Copy link
Contributor Author

hyp commented Aug 13, 2024

@swift-ci please test

@hyp
Copy link
Contributor Author

hyp commented Aug 13, 2024

@jmschonfeld I dropped the operator & overload, how does it look now?

@hyp
Copy link
Contributor Author

hyp commented Aug 14, 2024

@jmschonfeld could you take another look please 🙏 , we would like to get this in to make further build progress

@jmschonfeld jmschonfeld merged commit ad6ca71 into swiftlang:main Aug 14, 2024
3 checks passed
@hyp
Copy link
Contributor Author

hyp commented Aug 14, 2024

Thanks!

cthielen pushed a commit to cthielen/swift-foundation that referenced this pull request Nov 8, 2024
* [android] fix the LP32 armv7/i686 android build

* Update Sources/FoundationEssentials/Android+Extensions.swift

Co-authored-by: Jeremy Schonfeld <1004103+jmschonfeld@users.noreply.github.com>

* drop the android Lp32 specific operator &

---------

Co-authored-by: Jeremy Schonfeld <1004103+jmschonfeld@users.noreply.github.com>
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.

3 participants