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

[SR-2690] Bad code generated for FileManager.enumerator(at:includingPropertiesForKeys:options:errorHandler:) #45295

Open
swift-ci opened this issue Sep 19, 2016 · 4 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-2690
Radar None
Original Reporter hexdreamer (JIRA User)
Type Bug
Additional Detail from JIRA
Votes 1
Component/s
Labels Bug
Assignee None
Priority Medium

md5: 2cb02e6b428903f7d8079ad01987a3e2

is duplicated by:

  • SR-2872 Crash when FileManager's enumerate(at:...) tries to report an error

Issue Description:

If you call FileManager.enumerator(at:includingPropertiesForKeys:options:errorHandler:) with either a nonexistent directory or a symlink, and then try to iterate through the enumerator using FastEnumeration, you get a crash like this:

thread #1: tid = 0x6c49d, 0x0000000104e17d55 libswiftFoundation.dylib`static Foundation.DateComponents.unconditionallyBridgeFromObjectiveC (Swift.Optional<_ObjC.NSDateComponents>) -> Foundation.DateComponents with unmangled suffix "_merged" + 85, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x0000000104e17d55 libswiftFoundation.dylib`static Foundation.DateComponents.unconditionallyBridgeFromObjectiveC (Swift.Optional<_ObjC.NSDateComponents>) -> Foundation.DateComponents with unmangled suffix "_merged" + 85
frame #1: 0x000000010f57426b SwinvestigationsTests`thunk + 59 at FileManagerTests.swift:0
frame #2: 0x000000010267534c Foundation`-[NSURLDirectoryEnumerator nextObject] + 101
frame #3: 0x0000000105659645 CoreFoundation`-[NSEnumerator countByEnumeratingWithState:objects:count:] + 53
frame #4: 0x0000000104e50e89 libswiftFoundation.dylib`function signature specialization <Arg[1] = Owned To Guaranteed> of Foundation.NSFastEnumerationIterator.(refresh () -> ()).(closure #1) + 153
frame #5: 0x0000000104de3334 libswiftFoundation.dylib`Foundation.NSFastEnumerationIterator.next () -> Swift.Optional<Any> + 164

I would expect it to return nil for the optional enumerator, but it does not. The equivalent code in Objective-C works.

You can find a code example here: https://github.com/hexdreamer/Swinvestigations/blob/master/SwinvestigationsTests/FileManagerTests.swift

And the Objective-C version here: https://github.com/hexdreamer/Swinvestigations/blob/master/SwinvestigationsTests/NSFileManagerTests.m

@belkadan
Copy link
Contributor

The underlying issue is bad nullability on the error handler's arguments. I'm not sure what we can do about this on the Swift side.

@belkadan
Copy link
Contributor

The underlying issue is tracked by rdar://problem/27749845 (and should be mentioned in the release notes for Xcode 8).

@swift-ci
Copy link
Collaborator Author

Comment by Kenny Leung (JIRA)

Can you clarify? Do you mean that the callback handler has non-optional arguments, but the ObjC side is making the call with nil arguments?

@belkadan
Copy link
Contributor

Yep, that's correct. The header mis-declares the interface, but the compiler has no way to know that.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.
Projects
None yet
Development

No branches or pull requests

2 participants