Sort diagnostics by line number to prevent stale signs

[everett1992]

Some signs would not be removed from the sign column when their
diagnostic was fixed.

Debugging revealed that signs_to_add would include two signs for the
same line. state.signsis keyed by line number so the second sign for
a line will overwrite the first when signs_to_add is recorded in state.
The first sign's id is lost when it's overwritten so it can't be
removed.

signs_to_add included two signs for the same line because itertools
group_by only groups consecutive runs (it's more efficient, you only
need to remember the current group and can flush it when the key
changes).

This quick fix sorts diagnostics by line number so that group_by gives
us one group per line number.

fixes #952

[everett1992]

There's a couple ways to fix this issue, I chose the easiest, sorting the iterator so group_by works.

I think it would be faster/efficient-er to create a hash map of line number -> severity then insert each diagnostic into the map if it's severity is less than the current value at the line number.

Overall I think that state mapping by line number is a bad idea, unless you need to index by line number somewhere else. It should index by the sign id. Then if you accidentally add two signs on the same line you'll have two signs and know both id's instead of two signs and only know one id.

[autozimu]

Thanks!

[jimmycuadra]

Was this supposed to handle both warnings and errors? After pulling down the latest commits it seems to have resolved the problem for the latter but not the former.

[everett1992]

I'd expect this to fix both warnings and errors

…

On Wed, Jan 22, 2020, 7:39 AM Jimmy Cuadra ***@***.***> wrote: Was this supposed to handle both warnings and errors? After pulling down the latest commits it seems to have resolved the problem for the latter but not the former. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#955?email_source=notifications&email_token=AAE6WMZ4VQEV3VMZZZTOUGTQ67Z2TA5CNFSM4KIBADN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJSQ7SQ#issuecomment-577048522>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE6WM6KSIK2UYWGJM6SFV3Q67Z2TANCNFSM4KIBADNQ> .

[everett1992]

I recommend following my debug process, checking the sign list with `:sign place` and checking the log. #952 (comment) On Wed, Jan 22, 2020, 10:28 AM caleb everett <everett.caleb@gmail.com> wrote:

…

I'd expect this to fix both warnings and errors On Wed, Jan 22, 2020, 7:39 AM Jimmy Cuadra ***@***.***> wrote: > Was this supposed to handle both warnings and errors? After pulling down > the latest commits it seems to have resolved the problem for the latter but > not the former. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#955?email_source=notifications&email_token=AAE6WMZ4VQEV3VMZZZTOUGTQ67Z2TA5CNFSM4KIBADN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJSQ7SQ#issuecomment-577048522>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAE6WM6KSIK2UYWGJM6SFV3Q67Z2TANCNFSM4KIBADNQ> > . >