Drop Foundation dependency #92
Conversation
kateinoigakukun
force-pushed
the
katei/drop-foundation
branch
from
16d9b39
to
c10f94a
Compare
Co-authored-by: Kabir Oberai <[email protected]>
kateinoigakukun
force-pushed
the
katei/drop-foundation
branch
from
c10f94a
to
396a16e
Compare
| import ucrt | ||
| #else | ||
| #error("Unsupported Platform") | ||
| #endif |
There was a problem hiding this comment.
How come we need to use libc here? Seems like the only use site is open(..., O_DIRECTORY) — can we not use SystemPackage.FileDescriptor.OpenOptions.directory instead?
There was a problem hiding this comment.
I wanted to keep using memchr because llvm recognizes the lib call and optimizes it.
There was a problem hiding this comment.
I see, what do you think about making a memchr shim in SystemExtras? Might be nice to isolate the C library stuff to that one spot. We can do the same for O_DIRECTORY, which seems like it might need to be re-declared by us on Windows (other platforms define .directory in SystemPackage).
There was a problem hiding this comment.
Yes, importing it through a C shim could be an option. Actually memchr is not a syscall and SystemExtras will be upstreamed to swift-system later, so SystemExtras might not be an appropriate place.
Once we upgrade the minimum supported Swift version to 6.0, we can import it via @_extern(c) without C module, but it's not feasible right now.
There was a problem hiding this comment.
Ah interesting, I would've assumed that UnsafeRawBufferPointer.firstIndex(of:) could be optimized to memchr under the hood but it looks like that isn't being done yet. It's being tracked via swiftlang/swift#63200.
There was a problem hiding this comment.
Yeah, it's unfortunate situation now 🥲
No description provided.