Make the hack for finding attribute ranges more robust.
ClosedPublic

Authored by flherne on Nov 21 2016, 5:58 PM.

Details

Summary

Previously, this would find an incorrect range if the attribute was immediately followed by a comment containing its name.

e.g. foo.bar #bar would highlight the comment.

This patch ensures that we ignore comments in all cases.
Unfortunately, this introduces a new (much less likely) failure case.

If the expression we're getting the attribute from contains a dot, the name of the attribute and a hash in that order (not necessarily consecutive), and the hash is on the same line as the attribute name, we wrongly interpret the hash as the start of a comment.

For example, foo["...barrier#"].bar will highlight part of the string.

This should be very unlikely to occur in practice.

Test Plan

No regressions in pre-existing tests.

Added three new tests, two fail->pass with this patch and one pass->fail as described above.

Much staring at mis-highlighted bits of code.

Seriously, this whole problem is just stupid.

Diff Detail

Repository
R53 KDevelop: Python Support
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
flherne updated this revision to Diff 8355.Nov 21 2016, 5:58 PM
flherne retitled this revision from to Make the hack for finding attribute ranges more robust..
flherne updated this object.
flherne edited the test plan for this revision. (Show Details)
flherne added a reviewer: brauch.
flherne set the repository for this revision to R53 KDevelop: Python Support.
Restricted Application added a subscriber: kdevelop-devel. · View Herald TranscriptNov 21 2016, 5:58 PM
brauch accepted this revision.Nov 21 2016, 6:49 PM
brauch edited edge metadata.

Looks good, I also think the remaining case is unlikely to ever happen.

This revision is now accepted and ready to land.Nov 21 2016, 6:49 PM
This revision was automatically updated to reflect the committed changes.