@swift-ci please smoke test

@swift-ci please build toolchain Windows platform

@swift-ci please test

@swift-ci please test Linux platform

Thank you for the great contribution, @calda!

Thank you for the quick reviews and thorough feedback @xedin! Really appreciate it. This was my first non-trivial compiler change so your input was really helpful.

@calda The language workgroup discussed the problem and came to the conclusion that the compiler should:

1. Keep existing lookup behavior in Swift 5 (so no changes there);
2. Produce a tailored warning about guard let and if let statements that introduce self would be used in Swift 6 mode but isn't in Swift 5 - it has to describe the issue and avoid the fix-it to remove the statement. (We can brainstorm on the actual text).
3. Produce a new warning in < Swift 6 modes that detects an incorrect use of implicit self in non-escaping closures and suggests to add guard let statement if there isn't one.

Would you be interested in working on changes?

Sure! I can work on these changes

Produce a tailored warning about guard let and if let statements that introduce self would be used in Swift 6 mode but isn't in Swift 5

In what situations should this warning be emitted, and how would the warning be silenced?

In what situations should this warning be emitted, and how would the warning be silenced?

The same situations where the warning about "unused self" had to be suppressed in Swift 5 mode because it picks self from [weak self] instead of guard let/if let statements.

If we want a warning and this case:

closure { [weak self] in
  // warning: self is not unwrapped, add `guard let self else { return }`
  method() 
}

and this case:

closure { [weak self] in
  // warning: guard condition is unused in Swift 5, but used in Swift 6
  guard let self else { return }
  method() 
}

then how do you write a weak self closure without triggering a warning?

It seems like we'd want a way to suppress the first warning without introducing a new warning. Thoughts?

Probably the only way is to write explicit self. in this case?

Should the fix-it suggest using explicit self instead of adding a guard statement?

As far as I understand the guard/if let statements have to stay to produce self unwrap for the Swift 6 mode, so all the fix-it would do is to add self. which is going to silence the warning in Swift 5 mode and not going to break code in Swift 6 mode. Does that make sense?

Do we need a warning at all in this case, since the code is well-formed in Swift 6?

closure { [weak self] in
  guard let self else { return }
  method() 
}

Allowing this without a warning may be better than having multiple warnings that needs to be suppressed in stages.

This warning should be emitted only for language modes < 6 because in 6 and on it would pickup the right self :) We just need to warn people that okay previous the behavior here wasn't ideal and we are going to change it.

Sorry, I just want to make sure any new warning we add here has an actionable fix-it that silences it.

For the warning in this example, what fixit would we use?

closure { [weak self] in
  // Warning: guard statement condition is unused in Swift 5 language mode
  guard let self else { return }
  method()
  otherMethod()
}

Would we emit the warning any time there's an implicit self reference that had its lookup behavior changed by Swift 6? e.g. would this case emit a warning?

closure { [weak self] in
  // warning?
  guard let self else { return }
  self.method()
  otherMethod() // still implicit
}

(the guard statement is not unused, but there's still an implicit self call that has its behavior changed in Swift 6)

Would we emit the warning any time there's an implicit self reference that had its lookup behavior changed by Swift 6?

Yes, guard statement gets one warning and both method() and otherMethod() would emit a warning and ask to add explicit self.. In other later case only otherMethod() would get a warning.

We could also go in a direction where guard let self and if let self trigger a special diagnostic walker that only emits a single warning attached to the statement and a bunch of notes with fix-its per incorrect use of self, so your first example would be diagnosed something like this:

error: declaring self in guard statement has to effect on implicit self use in this closure, this behavior is an error in Swift 6
guard let self else { return }
          ^~~

note: use of weak implicit 'self'
   method()
   ^
   self.

note: use of weak implicit 'self'
   ohterMethod()
   ^
  self.

Ok, this makes sense to me -- we emit a warning for each these implicit self calls that will have their behavior changed with a fix-it to use explicit self. This also silences the "unused guard statement" warning, since that is no longer unused after applying the fixits. Does that sound right?

Take a look at my previous comment (i might have posted it while you where writing this message), you might find that a more interesting approach which reduces number of warnings produced.

Thanks for the in-depth discussion! I think your suggestion of having a single warning with multiple notes would work really nicely here.

Absolutely! Let's try to make it happen then, if it turns out too hard there is always a fallback to multiple warnings.

Here you go: #61513 -- turned out to be pretty straightforward!