@@ -431,6 +431,44 @@ in the callee.
431
431
`@sil_isolated` since a function cannot be isolated to multiple
432
432
actors at the same time.
433
433
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
+
434
472
### Async Functions
435
473
436
474
SIL function types may be `@async`. `@async` functions run inside async
0 commit comments