Does partial_apply not take ownership of @inout_aliasable arguments?

Development Compiler
1

I have a question about partial_apply's semantics and whether docs should be updated.

It appears that partial_apply is not taking ownership of @inout_aliasable arguments, for example, destroy_value %3 isn't destroying self in the following code.

struct Foo {
  mutating func f() {
    _ = { () -> () in _ = self }
  }
}

// Foo.f()
sil hidden [ossa] @$s13partial_apply3FooV1fyyF : $@convention(method) (@inout Foo) -> () {
// %0                                             // users: %3, %1
bb0(%0 : $*Foo):
  debug_value_addr %0 : $*Foo, var, name "self", argno 1 // id: %1
  // function_ref closure #1 in Foo.f()
  %2 = function_ref @$s13partial_apply3FooV1fyyFyycfU_ : $@convention(thin) (@inout_aliasable Foo) -> () // user: %3
  %3 = partial_apply [callee_guaranteed] %2(%0) : $@convention(thin) (@inout_aliasable Foo) -> () // user: %4
  destroy_value %3 : $@callee_guaranteed () -> () // id: %4
  %5 = tuple ()                                   // user: %6
  return %5 : $()                                 // id: %6
} // end sil function '$s13partial_apply3FooV1fyyF'

So if partial_apply is not taking ownership of @inout_aliasable arguments, should the SIL doc section on partial_apply be updated?

1 Like
2

@Joe_Groff

3

That is correct, @inout_aliasable arguments are only captured by address, because it is not allowed to refer to an inout argument in an escaping closure. (With the exclusivity model, maybe we can even capture them @inout now?)

4

I created PR #26523 to clarify this in SIL.rst.

1 Like