Fix #3405 Updating code minings

[travkin79]

There are three types of code minings and three corresponding types of annotations. Issue #3405 describes a problem with updating the annotations. In certain cases the annotations are not re-created if the code mining type changes, e.g. from in-line code minings to line header code minings. This PR fixes that issue.

In order to make reviews easy, I left three commits for three different changes. The commits can be squashed if you prefer having only one commit.

[tobiasmelcher]

Thanks a lot for the fixes, great work.
Could you please also create a unit test which documents the problem scenario where the CodeMiningType for a given offset is changed?

[travkin79]

Could you please also create a unit test which documents the problem scenario where the CodeMiningType for a given offset is changed?

Hi @tobiasmelcher,
Thank you for the feedback. I'll incorporate corresponding changes.

I was thinking about how to implement a test for my case, but for some reason, some tests, esp. CodeMining test, fail on my machine on the master branch (without my changes), commit hash 0ce1430. I didn't find the reason yet.

[github-actions]

Test Results

 3 018 files   3 018 suites   2h 52m 43s ⏱️
 8 230 tests  7 981 ✅ 249 💤 0 ❌
23 610 runs  22 816 ✅ 794 💤 0 ❌

Results for commit e85cb9d.

♻️ This comment has been updated with latest results.

[travkin79]

Hi @tobiasmelcher and @BeckerWdf,

I'm trying to implement a test for issue #3405, but I'm struggling with various issues with running the tests on my machine(s). I might need some help.

Some tests fail for the unmodified Eclipse platform UI master branch, commit 0ce1430, on MacOS and on Windows 11 as well. Due to the failing tests, I cannot assure that my new test will behave as expected.

In addition, the SWT widgets or the tests seem to behave strange. For example, when debugging my new test case on MacOS, the first line's vertical line indentation is reported to be 16, but the code mining is being drawn onto the source viewer's content instead of drawing it into an extra line (see screenshot 1). The in-line code mining is sometimes also drawn into the source viewer's text (see screeshot 2). The method getStyleRangeAtOffset(...) seems to always return null, on both operating systems (Mac & Win). Thus, I don't know which conditions to choose in my tests in order to check if the code minings are correctly drawn.

Screenshot 1:

Screenshot 2:

I've extended the code mining demo where the code minings seem to behave as expected, i.e. drawing a "title" either above a reference (e.g. "REF-X" in my example) in a line header or in the same line in front of the referencing text:

Line Header:

In-line:

It would be great if someone could take a look at my PR draft and help me fixing the tests.

[tobiasmelcher]

@travkin79 sure, I'll take a look and make a proposal. Please give me some time. I will also check if I can reproduce the other test errors you have mentioned.

[travkin79]

Thank you @tobiasmelcher,

I managed to finish a first version of a test. It turns out, getStyleRangeAtOffset(...) does return something != null, but for an unexpected index. For a text "Here REF-X..." where a code mining label is placed after "Here ", I expected getStyleRangeAtOffset(5) to be non-null, but instead I get a non-null result for getStyleRangeAtOffset(4), i.e. at the position of the space character. That looks wrong to me.

Besides that, there might be an issue with my PR in case that someone is using AbstractCodeMining class instead of sub-classing one of LineContentCodeMining, LineHeaderCodeMining, or DocumentFooterCodeMining. If none of the latter classes is sub-classed, we cannot determine which of the three corresponding code mining modes we have. I saw a few tests fail because of using anonymous sub-classes of AbstractCodeMining and fixed these, but there might be some client code doing something similar. I guess, moving AbstractCodeMining to an internal package is not an option.