Is corelibs-foundation still accepting fixes?

What's the current status of issues/PRs on swift-corelibs-foundation for fixing broken functionality (not implementing new functionality)? Are new changes being accepted?

I'm asking because I just bumped into a FileManager issue (FileManager.replaceItemAt(_:withItemAt:) doesn't appear to function · Issue #4655 · swiftlang/swift-corelibs-foundation · GitHub) which was filed & had a PR put up in 2022. It definitely reproduces on nightly docker images. But I don't want to go notifying everyone on the thread if there's no point!

Also: generally, what's the etiquette here? Is it to try and bump the original PR or is it to try and put up my own version of the fix?

Yes, but FileManager in particular was rewritten and moved over to swift-foundation, here. We should close the original PR and move it over (with needed changes) to the other repo.

1 Like

Ah interesting. I looked at swift-foundation but I don't think replaceItemAt made it into that rewrite (unless my GitHub search is missing something: Code search results · GitHub).

So I think I don't really understand how these repos connect then - how is it that I can call that method on FileManager in Linux if FileManager is implemented in the new repo without that method?

Starting with Swift 6 a couple years ago, swift-corelibs-foundation on linux was "re-cored" around swift-foundation, so several APIs like FileManager are now defined in the latter, with some former APIs like replaceItemAt() turned into extension methods.

The upshot is any changes for that method will indeed have to be made to swift-corelibs-foundation, which I see is still accepting pulls. I'd ping the old pull first, then open your own depending on their response.

1 Like

Ah duh, extensions.

For some reason I thought it was swift-foundation re-exporting swift-corelibs-foundation rather than the other way around. This makes a lot of sense - thanks for the explanation @Finagolfin !

I will ping the old PR

1 Like