Request for review: Don't crash on self used before self.init in a call argument (#89615)

buildcomcarlos · November 7, 2026, 7:22pm

Hi everyone!

I'd like to ask for a review and a CI run on PR #89615:

[SILGen] Don't crash on self used before self.init in a call argument (#88991) (#89615)

main ← carloshpdoc:carloshpdoc/fix-88991-self-init-crash

carloshpdoc

opened 12:22AM - 02 Jun 26 UTC

+84 -4

## What this fixes Resolves #88991. Passing an uninitialized stored property di…rectly as an argument to a delegating `self.init(...)` call crashed the compiler in SILGen instead of diagnosing the misuse. ```swift class Crash { let value: Int init(_ value: Int) { self.value = value } convenience init() { self.init(value) // used to crash, now diagnosed } } ``` ## Current behavior SILGen aborts with an assertion failure in `emitRValueForSelfInDelegationInit` (`C.isGuaranteedPlusZeroOk()`) while lowering the constructor. The equivalent code that first binds the property to a local (`let v = value; self.init(v)`) already diagnoses correctly, so only the inline argument form crashes. ## New behavior In the `WillSharedBorrowSelf` and `DidSharedBorrowSelf` states, when guaranteed plus zero is not ok (the property is read as a call argument before `self.init`), return an owned copy instead of asserting. This mirrors the existing `DidExclusiveBorrowSelf` branch in the same function, which already documents this case. Definite initialization then emits the expected diagnostic: ``` error: 'self' used before 'self.init' call or assignment to 'self' ``` ## Testing * Added a regression test to `test/SILOptimizer/definite_init_diagnostics.swift`. * `test/SILGen` and `test/SILOptimizer` pass locally (2188 tests).

It fixes a compiler crash (issue #88991) when self is used as a call argument before self.init in a delegating initializer. Instead of crashing in SILGen, the compiler now emits the regular definite initialization diagnostic ("'self' used before 'self.init' call").

@kavon reviewed it back in June, and all of the feedback has been addressed: the SGFContext-honoring approach was kept, the suggested comment changes were applied, and regression tests were added for the move-only (~Copyable / consuming), failable-init, and @objc cases. The @objc case lives in a separate objc_interop-gated test so the cross-platform file stays clean on Linux and Windows.

The PR has since been rebased onto current main, but CI hasn't run since the rebase. The only earlier failure was on Windows, caused by a known flaky test (swiftlang/sourcekit-lsp#2687) that has since been fixed.

Could someone with CI access run @swift-ci please test (and please test Windows), or point me to the right person to review it? I'm happy to make any further changes.

Thanks!

tkremenek · November 7, 2026, 7:43pm

@kavon can you take a look when you have a moment?

tkremenek · November 7, 2026, 7:45pm

@buildcomcarlos I’ve also invited you to become a member of the Swiftlang organization, which will allow you to trigger CI.

buildcomcarlos · November 7, 2026, 8:06pm

Thank you so much, @tkremenek! I've accepted the invitation, and I really appreciate you kicking off CI and looping in Kavon so quickly.

I'll keep an eye on the CI results and follow up on the PR if anything needs attention.

Slava_Pestov · November 7, 2026, 8:11pm

It’s been a while since I worked on this code, but the fix looks reasonable to me. Since you also added new tests, I approved it. I also kicked off source compat testing since that occasionally uncovers issues. I’ll give Kavon a chance to take a look first, but if all the test pass I’m also happy to merge it.