Skip to content

The Ventura Core Foundation Merge #4633

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

Closed
wants to merge 1 commit into from
Closed

The Ventura Core Foundation Merge #4633

wants to merge 1 commit into from

Conversation

iCharlesHu
Copy link
Contributor

This PR brings the FOSS portions of Core Foundation on par with with macOS Ventura, iOS 16, watchOS 9 and tvOS 16. This includes the changes shipped during the previous releases.

Most of the changes include bug fixes and performance improvements, but some are useful to highlight:

  • Updated Unicode definitions of CFString and NSString-based methods, including a new method of generating and storing this information by producing headers rather than bundling binary blobs.
  • Updated CFURLComponents to support Internationalized Domain Names (IDNs) via Punycode encoding.
  • Updates to calendrical calculation correctness.
  • Improved performance in several spots throughout the framework.

Some development notes:

  • CF_CROSS_PLATFORM_EXPORT has been renamed to CF_EXPORT_NONOBJC_ONLY to make its use clearer.
  • Development has continued using primarily os_*_lock_* functions rather than CFLock or CFMutex. To avoid the codebase diverging too far and make future merges easier, this patch uses os_unfair_lock and similar facilities where they were previously replaced by CFLock. These types shim to CFLock implementations outside of Darwin.

@iCharlesHu
Copy link
Contributor Author

@swift-ci please test

@iCharlesHu
Copy link
Contributor Author

cc @parkera

@iCharlesHu
Copy link
Contributor Author

cc @compnerd - Similar to previous merges, can we kick off a Windows build to see if there's anything breaks?

@AZero13
Copy link
Contributor

AZero13 commented Oct 16, 2022

@iCharlesHu I thought this was the source compiled at Apple for macOS?

Comment on lines -139 to +138
char asciiBuf[CFMaxPathSize] = {0};
int res = WideCharToMultiByte(CP_UTF8, 0, buf, rlen, asciiBuf, sizeof(asciiBuf) / sizeof(asciiBuf[0]), NULL, NULL);
if (0 < res) {
char asciiBuf[CFMaxPathSize] = {0};
int res = WideCharToMultiByte(CP_UTF8, 0, buf, rlen, asciiBuf, sizeof(asciiBuf) / sizeof(asciiBuf[0]), NULL, NULL);
if (0 < res) {
Copy link
Contributor

Choose a reason for hiding this comment

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

It is hard to judge because tabs are replaced with spaces, but indentation looks weird here and in some code below.

@@ -1367,7 +1383,7 @@ CF_PRIVATE Boolean _CFReadMappedFromFile(CFStringRef path, Boolean map, Boolean
if (0LL == statBuf.st_size) {
bytes = malloc(8); // don't return constant string -- it's freed!
length = 0;
#if TARGET_OS_MAC || TARGET_OS_LINUX || TARGET_OS_BSD || TARGET_OS_WASI
Copy link
Contributor

Choose a reason for hiding this comment

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

I see major loss of code under TARGET_OS_WASI and TARGET_OS_BSD. Probably, @MaxDesiatov could point if those are important changes for Swift WASM support. And @3405691582 did most of effort for OpenBSD support.

@@ -451,290 +447,12 @@ CF_INLINE kern_return_t __CFPortSetRemove(__CFPort port, __CFPortSet portSet) {
CF_INLINE void __CFPortSetFree(__CFPortSet portSet) {
close(portSet);
}
#elif TARGET_OS_BSD
Copy link
Member

Choose a reason for hiding this comment

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

The changes from #3004 and #4622 need to be merged back in here.

Copy link
Member

@3405691582 3405691582 left a comment

Choose a reason for hiding this comment

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

I was going to add more finer grained review comments but I just did the needful anyway in #4648 -- feel free to pick those commits on this pr, since I don't know off the top of my head if I can chain prs. The comments about malloc introspection need to be addressed separately though, because it's not immediately apparent how to resolve that issue.

string = CFStringCreateMutableCopy(allocator, 0, string);
CFRelease(tmp);
}
} else if (string && backingDataForNoCopy && malloc_size((void *)string) != 0) {
Copy link
Member

Choose a reason for hiding this comment

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

Avoid unconditional malloc introspection. Can we safely ignore this branch if the platform doesn't support malloc_size?

string = CFStringCreateMutableCopy(allocator, 0, string);
CFRelease(tmp);
}
} else if (string && backingDataForNoCopy && malloc_size((void *)string) != 0) {
Copy link
Member

Choose a reason for hiding this comment

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

Avoid unconditional malloc introspection. Can we safely ignore this branch if the platform doesn't support malloc_size?

@iCharlesHu iCharlesHu closed this by deleting the head repository Apr 30, 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.

4 participants