The problem is not in the logToFile, since as you mention, #file and #line do the right thing. The problem is on the OSLog side. The log.log("answer: \(42)") logs with the file and line number of the macro, not the calling site. So the linked code location is always in the macro, making the link useless.

Thanks for the background info, Quinn. What is your recommendation to solve the problem? Could we replicate the C macro from Swift, specifying the dso parameter? How could we set it to the macro invocation (rather than the macro implementation) location?

+1, seeing this in Xcode 15 beta 4 as well. I also need to have -ld64 in my Other Linker Flags to use the old linker because PLCrashReporter suffers from a linker error with the new linker (FB12592304). Not sure if that makes a difference.

@Rincewind I do think this is a serious oversight. Particularly with assets preserving vector data, we really should have fine-grained control over the button image size, irrespective of the image's native size. Imo, UIButton.Configuration.contentsInsets doesn't behave as advertised. It's defined as the distance from the button's content area to its bounds. So the image should be resized to fit in the content area. I've logged FB12471726.

Yes, I do use self-sizing cells and the code works fine 99% of the time. Seems like a race condition.