Description
Description
When using a function name to create a closure and trying to save that closure, the implicit capture of self seems to create a very confusing error message without a location, which for large modules can be very hard to find.
Reproduction
Add the following to test/Concurrency/transfernonsendable.swift
func something() {
class A {
var block: @MainActor () -> Void = {}
}
class B {
let a = A()
@MainActor
func b() {
a.block = c
}
@MainActor
func c() {}
}When executing the test, I get the following output (the first error is correctly reported, but I am concerned with the rest of the errors):
.../test/Concurrency/transfernonsendable.swift:23:21: error: unexpected warning produced: converting non-sendable function value to '@MainActor @Sendable () -> Void' may introduce data races
a.block = c
^
<unknown>:0: error: unexpected warning produced: sending 'self' risks causing data races; this is an error in the Swift 6 language mode
<unknown>:0: error: unexpected note produced: task-isolated 'self' is captured by a main actor-isolated closure. main actor-isolated uses in closure may race against later nonisolated uses
<unknown>:0: warning: diagnostic produced elsewhere: sending 'self' risks causing data races; this is an error in the Swift 6 language mode
<unknown>:0: note: diagnostic produced elsewhere: task-isolated 'self' is captured by a main actor-isolated closure. main actor-isolated uses in closure may race against later nonisolated uses
The reference to c seems to capture self, but the captures of self seems to not be correctly located for the diagnostics, and uses <unknown>:0: as location, which in a large piece of code is difficult to pin point (here the good error helps, but in the more complicated case I was investigating the <unknown>:0: were the only errors.
Expected behavior
The errors should at least point to the line a.block = c.
Environment
I was working on a branch recently synchronized with Swift 6.2, but I have been debugging where the errors seems to be produced and the code on main seems not have been changed in a while, so I am almost sure it still reproduces in main.
Additional information
@gottesmm you are the author of the code that generate those diagnostics, if you don't mind checking this issue. I have been trying to figure out where the invalid location is coming from, but this is not a part of the compiler I am very familiar with.