Rubberduck: Ignore Once QuickFix doesn't work with line continuation - gives no reason why

[daFreeMan]

Rubberduck version information
Version 2.4.1.4819
OS: Microsoft Windows NT 10.0.15063.0, x64
Host Product: Microsoft Office 2016 x64
Host Version: 16.0.4873.1000
Host Executable: MSACCESS.EXE

Description
A UseMeaningfulNames inspection popped up for a parameter on the 2nd line of a multi-line procedure declaration. I selected the Ignore Once quick fix and nothing happened. I took a look at the log thinking this was another occurrance of #5085 and that I'd have a full log to post there. Instead, I found this:

2019-08-16 09:00:21.1630;WARN-2.4.1.4819;Rubberduck.Parsing.VBA.AnnotationUpdater;Tried to add an annotation to a context not on the first physical line of a logical line.;
2019-08-16 09:00:21.1784;TRACE-2.4.1.4819;Rubberduck.Parsing.VBA.AnnotationUpdater;Tried to add annotation Ignore with values UseMeaningfulName to a the context with text 'Optional ByVal p1 As Variant' at L25C30 - L25C58 in module Quarterly Report.Tools.;

So, the failure is Status-by-design and I'm OK with that. However, it would be really nifty if the duck gave us poor, unwitting VBA programmers a clue as to why it just did nothing.

To Reproduce
Parse this code, attempt to apply the Ignore Once Quick Fix to either b or c.

Public Sub foo(ByVal bar As String, _
               ByVal b As String, _
               ByVal c As String)

End Sub

Expected behavior
Either:
A) Find the beginning of the logical line and insert the '@Ignore annotation there, or
B) Notify me that it cannot be added because the issue is not on the first physical line
B1) Bonus points for including the proper annotation string (including the name of the inspection to be ignored) in the warning message so that I can copy/pasta where it belongs. It's not always easy to remember what the inspection names are.

Screenshots
If applicable, add screenshots to help explain your problem.

Logfile
_GitHub won't let me upload the log right now. I'll do so later if a full log is requested._

Additional context
Maybe this should be a feature request instead of a bug report...

[Vogel612]

The problem here is that you can't just insert the annotation manually, because IIRC we're not currently scoping Annotations to logical lines. Note that I might be wrong here.

If we're not scoping them by physical lines, the correct fix here would be to insert it before the logical line instead of just warning and bailing out.

[daFreeMan]

Actually, @Vogel612 , you can insert the inspection manually (so long as you do it before the first _physical_ line of code). I did so on my code that raised this issue.

Well, maybe you can do it if you insert it in the logical middle somewhere, but I didn't try that (and it shouldn't work because you can't continue after a commented line continuation, I don't think).

[Vogel612]

Then there is no reason for this to be [status-bydesign]. Instead we should just inser the annotation at the appropriate location (before the logical line)

[MDoerner]

Annotations are scoped by _physical_ line. If you insert it above the logical line, it will simply not do anything to stuff below the first physical line.

You cannot insert an annotation in the middle of a logical line because it turns everything following it into a comment.

[retailcoder]

What's the status on this one? Is it even possible to modify annotations to be scoped to a logical line of code? I can definitely see the difficulty in implementing that, and I'd agree with status:deferred.

[MDoerner]

It is completely possible to change the annotation scoping yet again. However, I am a bit worried that using logical lines might degrade the performance of the resolvers. (That would have to be tested thought.)

Actually, it is really simple to determine the physical lines belonging to all logical lines. If we store the information about the first physical line of a logical line in a b-tree or simply in an ordered list, it should be reasonably fast to do a reverse lookup. (The depth of a binary search cannot exceed 16, and that should be super rare.)