@@ -431,6 +431,44 @@ in the callee.
431431 `@sil_isolated` since a function cannot be isolated to multiple
432432 actors at the same time.
433433
434+ - SIL functions may optionally mark a function parameter as
435+ `@sil_implicit_leading_param`. A SIL generator places this on a parameter
436+ that is used to represent a parameter that is implicitly generated by the
437+ generator at a full call site. Since they can only appear at the full call
438+ site, a `@sil_implicit_leading_param` can only appear in between the
439+ indirect result parameters and the direct parameters. For example the
440+ following swift code that uses `nonisolated(nonsending)`:
441+
442+ ```
443+ nonisolated(nonsending)
444+ func f(_ x: DirectParam) -> IndirectResult {
445+ ...
446+ }
447+ ```
448+
449+ would translate to the following SIL:
450+
451+ ```
452+ sil [ossa] @f : $@convention(thin) @async (
453+ @sil_isolated @sil_implicit_leading_param @guaranteed Optional<any Actor>,
454+ @guaranteed DirectParam
455+ ) -> @out IndirectResult {
456+ bb0(%0 : $*IndirectResult, %1 : @guaranteed $Optional<Actor>, %2 : @guaranteed $DirectParam):
457+ ... use %0 ...
458+ }
459+ ```
460+
461+ Notice how there is an `@sil_isolated` `@sil_implicit_leading_param`
462+ parameter that was inserted by SILGen to implicitly take in the caller's
463+ actor of f.
464+
465+ NOTE: By design SILOptimizer passes should ignore
466+ `@sil_implicit_leading_param`. Instead, it should only be analyzed as a
467+ normal parameter. So as an example, in f above the implicit parameter should
468+ be treated by the optimizer just as any other isolated parameter. This is
469+ solely SILGen using SIL as a data structure. TODO: Can this be removed by
470+ SILGen so SILOptimizer passes cannot even see it?
471+
434472### Async Functions
435473
436474SIL function types may be `@async`. `@async` functions run inside async
0 commit comments