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.
My last attempt at this in 4aa51673ab I had set
includeDependencyDepth="direct" but that pulled in a bunch
of unintended dependencies. Instead explicitly add the ASM
dependency.
This includes updating to 3rd party dependencies coming from Maven
so that everything resolves properly. In particular spifly
required asm, and by doing `includeDependencyDepth="direct"` that
dependency is included in the target platform.
Some bundles are bumped because dev happened between 11.2 release and
this version bump. The most significant change that happened
was the bump in Tycho version which changed ECJ version and
hence some class files changed
Part of #420
Includes:
- Sign all artifacts, particularly 3rd party with CDT's PGP key
- Using maven version managed and updated by EF Webmasters
- Update to latest SnakeYAML
- Move some 3rd party dependencies to Import-Package (instead of
Require-Bundle)
The creation of the build container for Core Build projects is
postponed to the start of the build process.
StandardBuildConfiguration getBuildContainer and setBuildContainer
have been cleaned up.
CBuildConfiguration creation is started via
CBuildConfigurationManager.getBuildConfiguration(IBuildConfiguration)
which holds a lock on the HashMap 'configs'. Creation of
StandardBuildConfiguration triggered, via applyProperties and
getBuildContainer(), a Folder.create which loops back to
CBuildConfigurationManager.getBuildConfiguration().
For detailed traces see https://github.com/eclipse-cdt/cdt/issues/424Fixes#424
Snakeyml recentlyish came out with 2.0 version and more recently
TM4E started using the 2.0 version. As TM4E snapshots are in our
target platform we started failing as we started wiring to the newer
version due to a missing underbound on our dependency.
A separate task of updating to recent snakeyaml will be done as part
of #387
* recognize source file extensions ".ccm", ".cxxm", and ".c++m"
cmake 3.27 release notes: The "CXX" language now treats source file
extensions ".ccm", ".cxxm", and ".c++m" as C++.
Signed-off-by: 15knots <11367029+15knots@users.noreply.github.com>
Use ${ProjName} for workspace includes referencing folders from
the project to better support project renames
Inspired by the implementation for selecting includes in build
settings located in FileListControl.java
Fixes#402
---------
Co-authored-by: jantje <eclipse@baeyens.it>
Co-authored-by: Jonah Graham <jonah@kichwacoders.com>
importAll fails with error 'Project: .org.eclipse.egit.core.cmp already
exists in the workspace!' and no further projects are imported.
The fix is to not go into special directories .metadata and
.org.eclipse.egit.core.cmp. Moreover, importAll and removeAll do not
fail immediately if operation on a project fails,
instead it keeps on performing operation on all projects and at the end, headless
builder returns with error code if operation of any project failed
Wrong active build configuration for Core Build projects.
The CoreBuildLaunchBar tracker always made a non default build
configuration the active build configuration. In other words, it
always made the debug build configuration active.
This caused wrong build flags if a non core build launch configuration
was used to launch a core build project binary.
Fixed the CoreBuildLaunchBar tracker to set the build configuration
to active that matches the launchBar mode.
Fixes#378
This is an example of where we have somewhat an inversion of dependencies.
The existing CDT code assumes it knows about all types of editors
at compile time. In this case the LSP C Editor is a new type. However,
rather than creating a new extension mechanism here we are simply
adding the LSP C Editor to the known list as the LSP C Editor
is (or will soon be) part of CDT itself anyway (see #354)
By itself this change doesn't do anything, it needs the
change in https://github.com/Bachmann-electronic-GmbH/eclipse-cdt-lsp/pull/46/
Also-by: Gesa HENTSCHKE <Gesa.HENTSCHKE@bachmann.info>
Enabling C++17 deduction guides unconditionally causes one of the tests for
template instantiation to fail because one of instantiations can be done via
implicit deduction guide using default template arguments.
Test case is covering issue https://bugs.eclipse.org/bugs/show_bug.cgi?id=207840
and remaining erroneous cases are not affected.
Amend the test and comment about change since C++17.
