Skip to content

Enable Span-based URL implementation#1857

Open
jrflat wants to merge 1 commit intoswiftlang:mainfrom
jrflat:enable-swift-url-v2
Open

Enable Span-based URL implementation#1857
jrflat wants to merge 1 commit intoswiftlang:mainfrom
jrflat:enable-swift-url-v2

Conversation

@jrflat
Copy link
Copy Markdown
Contributor

@jrflat jrflat commented Mar 26, 2026

Enables the faster Span-based URL implementation from #1844 by removing the FOUNDATION_SWIFT_URL_V2 build guard. See more implementation details in #1844

Motivation:

Many common URL operations such as path manipulation or resolution (currently) involve repeated string allocations, percent-decoding, and re-parsing. By working directly with Span(s) of the underlying bytes and replacing just the encoded path during path manipulation (ensuring that nearby ranges and path-related flags are updated correctly), we see 5-8x speedup in use cases like appending or deleting path components.

The new backing type also consolidates and shares code from the Swift NSURL/CFURL implementation, which improves parsing, validation, encoding, and resolution performance (2-3x speedup), and makes it easier to maintain consistent behavior across all the types.

Modifications:

Remove FOUNDATION_SWIFT_URL_V2 guard so that the _URL backing class is used.

Result:

Ubuntu 24.04 URL Performance vs. Baseline Swift URL v2 vs v1 Performance Linux

URL operations are significantly faster, and URL, NSURL, and CFURL share the same Swift code for parsing, percent-encoding, file path initialization, and resolution.

Bug fixes/compatibility behaviors:

  • Prevents double-encoding of already-percent-encoded characters when another invalid character exists in the component (deviating from URLComponents encoding to match original CFURL byte encoding behavior and the behavior of most other RFC 3986 and WHATWG parsers). Resolves Double encoding of query component #1190.
  • Allows [ and ] unencoded in the path, query, and fragment via Allow square brackets in Swift CFURL path, query, and fragment #1802, matching WHATWG behavior.
  • standardized now preserves leading .. segments in relative paths so they're not removed until resolution.
  • File path colon-encoding in the first relative path segment is more lenient when the character preceding the colon cannot be part of a scheme (e.g. %43: is not mistaken for a scheme).
  • appendingPathExtension rejects extensions containing invalid characters that would be problematic when decoded (e.g. spaces or Unicode directional override characters) instead of storing them percent-encoded.

Testing:

  • Benchmarks for file and non-file URL path manipulation.
  • Unit tests on Darwin, Linux, and Windows.

@jrflat jrflat requested a review from a team as a code owner March 26, 2026 23:31
@jrflat
Copy link
Copy Markdown
Contributor Author

jrflat commented Mar 26, 2026

@swift-ci please test

@jrflat
Copy link
Copy Markdown
Contributor Author

jrflat commented Mar 27, 2026

@swift-ci please test

@jrflat jrflat force-pushed the enable-swift-url-v2 branch from 88ee31c to 1a0bb3c Compare April 7, 2026 23:13
@jrflat
Copy link
Copy Markdown
Contributor Author

jrflat commented Apr 7, 2026

Squashed and rebased to pick up bug fixes for cross-repo testing

@jrflat
Copy link
Copy Markdown
Contributor Author

jrflat commented Apr 7, 2026

@swift-ci please test

@jrflat jrflat force-pushed the enable-swift-url-v2 branch from 1a0bb3c to 7b38ef5 Compare April 9, 2026 21:12
@jrflat
Copy link
Copy Markdown
Contributor Author

jrflat commented Apr 9, 2026

@swift-ci please 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.

Double encoding of query component

2 participants