I'm working on fix-its for SR-10218 and was wondering if there is a syntax for expecting a note on line n
, say, with an attached fix-it which inserts something on line m
(where n != m
). I couldn't easily locate any examples in the existing tests, but errors like adding the @objc
attribute exhibit this behavior. Does this functionality exist the testing setup, and if so how do I use it?
Looking at the DiagnosticVerifier
code, it appears that fix-its are matched based solely on column number. I'll file a bug to Is the appropriate thing to do in this case omit the fix-it, or match the fix-it based on column numbers and ignore the line numbers?
It's generally discouraged to have a fix-it on a different line from a diagnostic anyway, unless there's a particular reason for it, because it won't show up in textual output on the command line. I think it'd be better to put that note at the same place you'd insert the new capture.
That said, you can look at the tests in test/FixIt that do before/after comparisons of applying fix-its, if I recall correctly.
That makes sense. Was a little concerned that divorcing the capture fix-it from the problematic member reference would result in a surprising note if the closure was particularly large. I guess we already do this with redeclaration diagnostics and others, though.
I'd expect "warning" at the use site, "note" with "self." fix at the use site, "note" with capture fix at the closure start site.
Are there conventions around emitting the same diagnostic on a line multiple times (or a good way to avoid doing that)? If someone uses implicit self
several times in a closure they would get a diagnostic for each one. Is that expected with this kind of diagnostic?
I think so, since one possible fix is to add self.
before each one. The column location and highlight ranges keep it from being completely indistinguishable.
Sorry, my phrasing was unclear. I was more referring to the note that will fall on the closure opening. Is it appropriate to have multiple diagnostics there that are all identical?
Ah, yeah. It's not wonderful but it's better than diagnostics that behave differently in the presence of other diagnostics. (The intent is that notes are attached to the warning, meaning that notes on separate warnings are unrelated-ish if the warnings are considered unrelated.)
As a degenerate case, complaints about something not being exposed to Objective-C might work this way if the same method is used with #selector
in two places.
Great, thank you for clarifying all that!