swift

9f4f1cda - [Concurrency] withDeadline: skip installation when subsumed by outer deadline

[Concurrency] withDeadline: skip installation when subsumed by outer deadline Add a Swift-side fast path at the top of `withDeadline`: before pushing a `TaskDeadlineStatusRecord`, opening a `TaskCancellationScope`, and spawning a detached timer `Task`, check whether an outer withDeadline for the same clock is already active with a deadline at or before ours. If so, just run `operation()` inline. The runtime already had a subsumption check in `swift_task_pushDeadlineImpl` that avoids installing the record, but the Swift caller still allocated a `_ClockIDBox` (for custom clocks), opened a cancellation scope, and spawned a detached timer. Those are now skipped entirely on the subsumed path. The pre-check reuses two existing building blocks: - `_findNearestDeadline(clock:)` returns the tightest existing deadline for a given clock, allocation-free for system clocks and cheap for custom clocks (`passUnretained` box). - `_instantComponents(_:clock:)` decomposes the caller-provided instant into the (seconds, attoseconds) form the record stores. The comparison is a lexicographic `<=` on those two-word tuples, matching `compareDeadline` in TaskStatus.cpp. The runtime-side check stays as defense-in-depth for callers going through `Builtin.taskPushDeadline` directly and for the (extremely narrow) race where another path installs a tighter deadline for the same clock between our fast-path check and our push - the runtime will still observe the tighter record and skip our install. Also brings in the `withDeadline(in:)` shorthand overloads that had accumulated in the working tree: a generic one taking any `Clock & Identifiable` and a concrete `ContinuousClock` disambiguator for calls like `withDeadline(in: .seconds(5)) { ... }` where the clock: argument is defaulted. Runtime test `test_outer_deadline_subsumes_inner_no_scope` verifies: - Nesting a looser withDeadline inside a tighter one on the same clock does not install a fresh record (`_findNearestDeadline` still shows the outer deadline while inside the inner). - The inner operation still runs to completion normally. Deviations from SE-0526 in this change: parameter name is `operation:` rather than the proposed `body:` - matches the stdlib convention for "decorator over work" APIs (withTaskCancellationHandler etc.). The other API-shape items from SE-0526 (CancellationError.Reason, Task.cancel(reason:), Task.hasActiveDeadline, Task.activeDeadline(for:), withTaskCancellationHandler onCancel with reason argument) are not part of this change.