With the first part of the fix in #603 we recreate the document
regularly (on each context change) therefore we need to let any
consumers of the document fetch the current version of the document
from the editor (by calling getAdapter(IDocument.class)) when
it is needed, rather than caching it.
Fixes#603
The view can be reset in a couple of ways, by changing debug
context or manually refreshing. With this change in Platform
https://github.com/eclipse-platform/eclipse.platform.ui/pull/963
the CDT violation of the API aronud resetting state of the
document was exposed.
Therefore the solution is to instead of trying to reset the
state of the existing document, create a new one when the
view is reset.
Fixes#603
CDT.setup was allowing devs to choose the target platform, but
in reality most choices don't work. Instead force the known
correct value which is what Eclipse Platform does too.
Fixes#571
Some flows (such as open JUnit test case) does a IRunnableContext.run
before the UI is open. Therefore we need to fall back on the platform
progress service to run it since the launch config UI is not ready yet
Fixes#555
This happened to work before because the contents of
api-baseline.repo was in api-baseline.repo.simrel so
the error in the pom.xml went undetected until
#551 issue meant api-baseline.repo wasn't in
api-baseline.repo.simrel
In recent binutils version, the warning, for stubbed functions, is
properly printed and due to this correction, linking a project with
stubbed functions fails the build in headless build rather than
just printing the warnings.
Example:
.../arm-none-eabi/bin/ld.exe: .../libc.a(libc_a-writer.o): in function `_write_r':
(.text._write_r+0x10): warning: _write is not implemented and will always fail
...
12:02:52 Build Failed. 8 errors, 8 warnings. (took 6s.284ms)
The first line matches the error pattern (.*[/\\])?ld(\.exe)?: (.*)
that incorectly fails the build in headless mode (a single line matching
a pattern with severity "error" fails the build) when there are really
only warnings in the build log.
The problem can be obsered using the GCC 11 (and later) toolchain
builds with newlib for the arm-none-eabi target provided by Arm.
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
With the extra memory in the parent commit the build is succeeding again
and therefore we don't need tests disabled anymore.
This reverts commit bee7e0db0c.
I think with some of the recent changes (Tycho 4, API baselines,
maybe even new dependency on Platform M3) it may be that our memory
requirements have gone up substantially for the build.
Also, with Sonar in the works that also requires more memory.
Therefore see if the EF's JIPP infra will allocate 10G of ram to
our build.
This should fix all the "Killed" messages randomly in the CDT builds.
https://wiki.eclipse.org/Jenkins#What_is_killing_my_build.3F_I.27m_using_custom_containers.21
This escape sequence can be generated when using Powershell on
Windows (and possibly other places too) to erase number of
characters.
Change-Id: I32405f51a3f91fd8653d44f2676a5c85b696ef99
I recently split code cleanliness into two parts, and since in Jenkins
the baseline-compare-and-replace and api-baseline-check run on the main
build we don't need to run them on the cleanliness pass too. Therefore
run the "only" script in the code formatting checks stage to speed up
build and avoid duplicated work.
The Jenkins CI at EF is running very slowly recently and all
tests are timing out. The tests work fine locally and find
on GitHub actions runners.
Therefore on the Jenkins CI build without running the tests.
When a more complete implementation of ANSI Escape sequence for
renaming terminal titles was added in
[CDT 10.2](https://github.com/eclipse-cdt/cdt/blob/main/NewAndNoteworthy/CDT-10.2.md#rename-terminal-tab)
it caused a regression in use cases where extenders of the terminal
wanted to retain control of the terminal's title.
This commit adds a new flag that will prevent the title of the
terminal tab from being updated from ANSI escape sequences.
Fixes#494
The Memory Browser and Memory views will jump to the memory
address after a user selects a value from the Memory Search
Result list. If the views belong to the same tab group as
the Search view, then it might not be very intuitive for
the user to switch back to one of the Memory views and see
the effect of the selection.
The current commit adds on the the double click listener
(from MemorySearchResultsPage.java) the behavior to refocus
on the Memory Browser/ Memory view.
Resolves: #515
