Skip to content

Switch to lossy UTF8 decoding for dependency scanner diagnostic result strings#2080

Open
artemcm wants to merge 1 commit intoswiftlang:mainfrom
artemcm:FixForceUnwrapOnInvalidUTF8
Open

Switch to lossy UTF8 decoding for dependency scanner diagnostic result strings#2080
artemcm wants to merge 1 commit intoswiftlang:mainfrom
artemcm:FixForceUnwrapOnInvalidUTF8

Conversation

@artemcm
Copy link
Contributor

@artemcm artemcm commented Feb 11, 2026

The toSwiftString code currently force-unwraps a String initializer which attempts to decode the input buffer as valid UTF-8. We have seen a crash on this force-unwrap.

This change switches toSwiftString to use the Swift standard library's String(decoding:,as:) instead of Foundation's String(data:,encoding:). The former returns a non-optional value which replaces non-UTF-8 characters with a Unicode replacement character, instead of failing and returning nil.

This will not only resolve the crash, but also result in us emitting these potentially-corrupted strings for the user to see.

Resolves rdar://157486211

…t strings

The 'toSwiftString' code currently force-unwraps a 'String' initializer which attempts to decode the input buffer as valid UTF-8. We have seen a crash on this force-unwrap.

This change switches 'toSwiftString' to use the Swift standard library's 'String(decoding:,as:)' instead of Foundation's 'String(data:,encoding:)'. The former returns a non-optional value which replaces non-UTF-8 characters with a Unicode replacement character, instead of failing and returning 'nil'.

This will not only resolve the crash, but also result in us emitting these potentially-corrupted strings for the user to see.

Resolves rdar://157486211
@artemcm
Copy link
Contributor Author

artemcm commented Feb 11, 2026

@swift-ci test

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.

1 participant