[Typecheck] Failing to compile inlinable function with enable-library-evolution

[LucianoPAlmeida]

Description
For the following test case we fail to compile and get 'let' property 'i' may not be initialized directly; use "self.init(...)" or "self = ..." instead only in inlinable init and with enable-library-evolution mode. Not sure why it shouldn't compile

// RUN: %target-typecheck-verify-swift -enable-library-evolution -debug-constraints

public struct A {
  public let i: Int
  
  @inlinable
  public init() {
    self.i = 0
  }
}

The problem seems to be with the bindings for member that for some reason with library evolution enabled find a r-value for member type, causing the failure:

  (overload set choice binding $T0 := @lvalue A)
  (overload set choice binding $T1 := Int)

Without it thing seems to be fine

  (overload set choice binding $T0 := @lvalue A)
  (overload set choice binding $T1 := @lvalue Int)

Where $T0 is the base and $T1 member type.

Steps to reproduce
Run test case above with lit

Expected behavior
This code should compile, I don't see why it would behave differently with enable-library-evolution

Environment

• Swift compiler version info main @45cd83d73e00230725849603d143ece95bc74467

[LucianoPAlmeida]

@xedin This seems to be here since 5.1. Is that by design?
I'm just starting to look into it and go through the code to have more context, but with my current understanding this looks like a bug.

[AnthonyLatsis]

This feels intentional in the sense that it is not safe to have an inlinable public initializer that initializes storage directly in a non-@frozen struct, namely, the library author might add a new property in a future release and cause memory corruption in clients that already inlined the init.

[LucianoPAlmeida]

This feels intentional in the sense that it is not safe to have an inlinable public initializer that initializes storage directly in a non-@frozen struct, namely, the library author might add a new property in a future release and cause memory corruption in clients that already inlined the init.

Yeah, that makes sense.
Just found debugging the code that this is indeed an intentional rule.
Closing this then, thank you for the input @AnthonyLatsis!

Ah just for context this comes from this issue apple/swift-algorithms#189