Steps:
======
1. Create a managed project and build it
2. Expand the built binary available in binary container in project explorer view
3. Now clean the project, clean will fail irrespective of number of tries you do
Reason:
=======
For finding the sources for binary, Elf instance is created and Section.mapSectionData creates MappedByteBuffer of channel which locks the file on Windows until its garbage collected, see following
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4715154
Solution:
=========
Made ISymbolReader AutoCloseable and user is responsible to properly close it. In case of dwarf reader, we remove all the references of ByteBuffer and call gc.
The indexer has a feature that allows readers of the index
to read the index in the middle of write operations. This
is done by using a YeildableIndexLock.
The YeildableIndexLock's yield method can be called to
temporarily give up the write lock. However the assumption
in the code was that it would always successfully
reaquire the lock after that.
However, if the indexing was cancelled the lock would
fail to be reaquired. Therefore the code that thinks it
owns the lock no longer owns it. In this case the code
in PDOMWriter.storeSymbolsInIndex's finally block.
Therefore I have added an new exception type to explicitly
identify this use case so the original code can differentiate
between cases where an exception was thrown where the lock
is still held, and cases where the lock is no longer held.
Note that instead of a new exception caught like this:
```java
} catch (FailedToReAcquireLockException e) {
hasLock = false;
e.reThrow();
```
I could have done this:
```java
} catch (InterruptedException | OperationCanceledException e) {
hasLock = false;
throw e;
```
But it is not obvious that nothing else other than the
acquire can raise an OperationCanceledException because it
is a RuntimeException. By having a new checked exception we
can know for sure that in the finally block we have lost
our lock.
There are no API implications of this change as all the classes
and interfaces are internal to CDT.
Fixes#128
The format of this error message used to look like:
```java
Expected number (0) of Non-OK status objects in log differs from actual (1).
Error while parsing /projC_testTripleDownwardV/h3.h. java.lang.reflect.InvocationTargetException
Caused by: java.lang.reflect.InvocationTargetException
Caused by: java.lang.AssertionError: Need to hold a write lock to clear result caches
```
and it was hard to impossible to identify what the cause is.
The hope is that capturing this fuller stack trace into the log
will make it easier to identify the problem.
Part of #117
This helps add some isolation between tests in case background
threads are accessing a project. However I am not sure
this solves any of the actual outstanding flaky tests.
Part of #117
While it may be that the tests don't directly rely
on JUnit5, the IDE requires JUnit5 in the classpath
or else the launch config doesn't work with this error:
Cannot find class 'org.junit.platform.commons.annotation.Testable'
on project build path.
Part of #117
JDT thinks this is a test and will run it in the IDE and display
an error. But it is only used to compose other tests, by making
it abstract the IDE won't see it anymore.
Part of #117
This is an ancient (2004) test that does not apply, was never
referenced in the Suites and whose name doesn't match standard
pattern.
It tried to import ancient versions of projects as well, which
would kick off the project converter UI that can't be disabled
from the core plug-in.
All in all, this test adds nothing of value.
Part of #117
This code seems to be trying to optimize across tests.
This change isolated each individual test better.
Also removed is a bunch of effectively unused test code.
Part of #117
Some of these tests left behind projects, by chaning them
to extend BaseTestCase5 the resource cleanup happens
and the tests are cleaned up properly
Part of #117
Ideally the code itself should also be deleted from CDT, but
this test is super flaky and I cannot seem to convert it to
JUnit5 so I can properly mark it as flaky. Therefore
the test is now simply gone.
Part of #117
The resource helper is widely used, but when it deletes
projects, it leaves their contents on disk. Fix this
so that the contents on disk is deleted.
Part of #117
Maybe once upon a time this lifecycle did something,
but now in setUp fProject is always null and therefore
the project was never getting deleted as the fProject
that deleteProject saw was different than
the tests.
Part of #117
Having the test suites means that tests run multiple times
when running in the UI. Most suites just ran the tests in
that package, so their value, especially with the transition
to JUnit5 is minimal.
Note that the suites are not used when running build
with Tycho/Maven
Part of #117
Warning in build.properties will be errors when they run
in the tycho build, like this:
```
Error: Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:2.7.5:package-plugin
(default-package-plugin) on project org.eclipse.cdt.core.tests:
/home/runner/work/cdt/cdt/core/org.eclipse.cdt.core.tests/build.properties:
bin.includes value(s) [test.xml] do not match any files. -> [Help 1]
```
So make them errors in the workspace so that the issue is
detected before push.
Some build.properties issues don't affect the build, but
are still indicative of a problem.
If a .cproject references a binary parser ID that is not in
the plug-in XML, or in the XML, but marked as private, the
UI cannot display the binary parsers and was raising an
ArrayIndexOutOfBoundsException as below.
This fix rewrites the array handling using collections.
```java
!ENTRY org.eclipse.ui 4 0 2022-11-04 09:44:27.409
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
at org.eclipse.cdt.ui.newui.BinaryParsTab.updateData(BinaryParsTab.java:253)
at org.eclipse.cdt.ui.newui.AbstractCPropertyTab.setVisible(AbstractCPropertyTab.java:253)
at org.eclipse.cdt.ui.newui.BinaryParsTab.setVisible(BinaryParsTab.java:221)
at org.eclipse.cdt.ui.newui.AbstractCPropertyTab.handleTabEvent(AbstractCPropertyTab.java:630)
at org.eclipse.cdt.ui.newui.AbstractPage.updateSelectedTab(AbstractPage.java:412)
at org.eclipse.cdt.ui.newui.AbstractPage$4.widgetSelected(AbstractPage.java:382)
```
Changed the execute to take the cwd to run the command in and
clean up the related code, including some error message
handling and removing some redundant code.
Fixes#125
Various tests are not cleaning up properly after
themselves, causing test failures on subsequent
tests. Therefore start each test by deleting
all projects.
In addition, some tests were creating their test
projects in their constructor. As all the constructors
run before all the tests as part of test discovery
it means that projects were being created in
constructor and interfering with other tests
later. With the deleting of all projects in @AfterEach
these tests would have started failing. Therefore,
change these tests to create their projects
and do other initialize tasks in the setUp method.
For older JUnit3 style tests:
This substantially slows down tests as many tests
rely on sharing the project between multiple tests and
recreating those projects on each run is slow.
Therefore this is not applied universally to
all JUnit3 tests.
For tests that are affected, those tests are moved
to JUnit5 base test.
Part of #117
On GitHub actions the org.eclipse.cdt.ui.tests.text.contentassist2
tests are running after ProposalFilterPreferencesTest and
ProposalFilterPreferencesTest was changing the default
filter and not restoring it.
Part of #117
This old test had a race condition. The failing test was trying
to verify that CDTPROJECT_ADDED was received, but if there
was a delay in the startup then another event would come in
later. So for this test use the first received event,
for the remaining tests use the last received event.
Part of #117
It may be that this test fails regularly because
another test is not cleaned up properly.
Make sure there are no unexpected projects in
the workspace.
Part of #117
The launchbar way of compositing images for the buttons was preventing
the use of higher quality icons on hidpi dislays, making the launchbar
buttons look blurry or pixelated compared to other toolbar buttons.
Instead we can get a nicer result with a custom widget on which we can
directly draw a button border plus the hidpi version of the icon.
Also included is an attempt at a 2x hammer build button icon, which
should look a bit nicer on hidpi screens.
Switch to CTabFolder/CTabItem for newui.
This changeset is a breaking change but on a review of existing
adopters/extenders of CDT no one is actually accessing these fields.
Change-Id: Ic1ef0f242c1d2932726f3a6d4c9df9558312764a
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
Also-by: Jonah Graham <jonah@kichwacoders.com>
Adds constexpr evaluation for some additional compiler builtins. This is
probably the last lot few builtins that can reasonably be
constexpr-evaluated in CDT.
gcc linker outputs "removing unused section" to stderr when the option "--print-gc-sections" is used. That is fine.
Eclipse CDT reports all these lines as errors however and the build seems to have failed, which is wrong.
The was a bug report Bug 539927: Do not mark "Removing unused section" lines as errors and a fix
To fix this bug a change was made 2020-12-02 05322656c6
-CDTGNULinkerErrorParser.regex.LdMode=(.*[/\\\\])?ld(\\.exe)?: (mode .*)
+CDTGNULinkerErrorParser.regex.ldInfo=(.*[/\\\\])?ld(\\.exe)?: ((mode|Removing unused section) .*)
That does however not solve problem entirely, as the output of gcc linker is "removing", not "Removing", i.e. the word "removing" starts with a lower-case "r"
To fix that problem both R and r should be accepted.
