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
The code for boost test running parsing left
all the excess whitespace from the XML file.
This led to a lot whitespace in messages
in the UI. This change trims leading and
trailing whitespace, but preserves whitespace
within a message.
The pre-existing code assumed that string (qName) passed in
to start and end element was always interned and compared
those strings to constants using ==. Instead rewrite
code using switch statements on the strings.
Also includes small change to the exception handling so that
code analysis can correctly where exceptions are always thrown.
i.e. instead of hiding a throw in an always throwing method,
return the exception and throw it at the call site.
This is checked in the code cleanliness workflow and by failing the
main build here causes the tests not to run and the tests are more
important. Similar to the new api-baseline-check that doesn't
run in the main workflow
The error handling in Tycho 4 identifies when bundles are listed
in category.xml but not available. The removed bundles were
not in the output, and with this change the error is resolved
in the build.
Updated setting for maven enforcer to match Tycho requirements.
A while ago we made the "Make sure all versions have been bumped
appropriately compared to the baseline" output to another file
to make it clearer. This refactor splits it up into different
build steps instead so that I don't have to open an additional
log file.
* Fix meson build under Docker Tooling
- add new IToolChainConstants containing SECCOMP_UNCONFINED property constant
- add new setLauncher() method to CBuildConfiguration so that
watchProcess() can be used for container building
- enhance ContainerCommandLauncher to discover specification of
SECCOMP_UNDEFINED boolean option for execute() so "seccomp=undefined" can be specified
- fix ContainerCommandLauncherFactory.verifyIncludePaths() to only
look at filtered includes that have been made absolute and to
recognize matches when the prefix shows up in the loaded list
- add setting a property to ContainerGCCToolChain to set SECCOMP_UNCONFINED to true
by default for the time-being
- when generating scannerinfo, specify "seccomp=unconfined"
- in ContainerGCCToolChain.startBuildProcess() remove extraneous
banner statement and ensure that the build directory is created
- fixes#479
In https://github.com/eclipse-platform/eclipse.platform.swt/issues/450
the behaviour was changed so that setFocus no longer activates the shell
by default. Therefore when creating the popup shell and setting the focus
the overall focus was still on a control in the main eclipse shell.
This affected Eclipse SWT/Platform 4.29 M1 and has been changed for
M3. However there is intention to (possibly) change the default back
to not activating in setFocus. If that happens this patch will be ready
for it, and in the meantime (until CDT changes to M3) it resolves this
test failure:
`createNewLaunchConfig (org.eclipse.launchbar.ui.tests.internal.CreateLaunchConfigTests) with error`
full trace:
```java
org.eclipse.swtbot.swt.finder.exceptions.WidgetNotFoundException: Could not find shell matching: with text 'Create Launch Configuration'
at org.eclipse.launchbar.ui.tests.internal.CreateLaunchConfigTests.createNewLaunchConfig(CreateLaunchConfigTests.java:77)
Caused by: org.eclipse.swtbot.swt.finder.widgets.TimeoutException: Timeout after: 10000 ms.: Could not find shell matching: with text 'Create Launch Configuration'
at org.eclipse.launchbar.ui.tests.internal.CreateLaunchConfigTests.createNewLaunchConfig(CreateLaunchConfigTests.java:77)
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
```
Yaml 2.0 fixes CVE-2022–1471 to error on object references. This
commit adapts our use of Yaml to not output object references
anymore and on loading explicitly allow object references to
expected types.
Fixes#498
Recently new extensions were added to CDT for C++ modules in #422
At the time some test failures were not noticed. This change patches
those failing tests.
Fixes#454
Until https://github.com/eclipse-cdt/cdt/pull/495 can be resolved
fully, apply some of the required changes.
- wildwebdeveloper was out of date, however we don't really
need wwd in CDT, but some of our dependencies have requirements
that are fufilled (e.g. linuxtools)
- duplicate entry for hamcrest 2.2 removed (other entry was just
above it!)
Long ago in 334702ee05 generic types
were added. However in at least one place a previous assumption
that existed was broken. That assumption was the true
type of ResourceInfo.getTools() would be Tool[] as opposed to ITool[].
That commit broke it for ResourceConfiguration.getTools()
Internally in CDT ITool is in practice always Tool, and as a result
there are lots of downcast from ITool -> Tool. However ITool[] cannot
be downcast to Tool[] unless the original type was Tool[].
Instead we use Arrays.copyOf to copy the array into the correct
array type.
Steps to reproduce the problem now fixed:
1. Create a Managed Build executable project.
2. Open the properties window of the source file (as opposed to project)
3. At the Properties page, navigate to "C/C++ Build/Tool Chain Editor".
4. Click the "Apply" button.
