swift

4f04f6b1 - [Concurrency] Honor task executor preference when default actor is involved

[Concurrency] Honor task executor preference when default actor is involved When a default actor and a custom task executor preference coexisted, the runtime dropped the preference in three places: - swift_task_enqueueImpl: only the generic-serial-executor branch honored a task executor preference, so jobs targeting a default actor lost it. - DefaultActorImpl::enqueue: the actor's enqueue loop only loaded the task executor preference when it thought it would need to schedule, so an already-scheduled actor would never hop to the requested task executor. - swift_job_runImpl: always force-unlocked the actor on switch out, which conflicted with a task executor that wanted to keep draining the actor. This patch routes default-actor + task-executor combos through the actor's own enqueue (which now always reads the preference and re-schedules a processing job when one is set), and leaves the actor lock held when a task executor is in play so the next pending job lands on the right executor. swift_task_immediateImpl gains a default-actor branch: an immediate task targeting a default actor must not run synchronously on the caller; it is enqueued on the actor so the actor's drain (with the preference applied) runs it on the right thread. Renames forSynchronousStart -> forImmediateTask and isForSynchronousStart -> isImmediateTask for clarity, and adds Task_IsImmediateTask job-flag plumbing so the runtime can distinguish immediate-task starts elsewhere. rdar://155596073