This fixes support to properly identify the end of
OSC control sequences which can be terminated
with a BEL or ESC \.
Fixes https://github.com/eclipse-cdt/cdt/issues/831
(cherry picked from commit 229c55c9e2)
Co-authored-by: Jonah Graham <jonah@kichwacoders.com>
When the project's active IBuildConfiguration has the default name and
the chosen ICBuildConfigurationProvider.getCBuildConfiguration does not
support the IBuildConfiguration.DEFAULT_CONFIG_NAME and returns null,
this can cause the project's ScannerInfoProvider to become "stuck"
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=413357) on the wrong
setting (eg LanguageSettingsScannerInfoProvider instead of
ICBuildConfiguration) until Eclipse is restarted or the project is
closed and reopened. When this happens, the indexer does not function.
This problem may arise if an ISV contributes a
ICBuildConfigurationProvider which has very specific naming conventions
for it's build configurations.
The solution uses the API (resetCachedScannerInfoProvider(project)),
introduced by 413357, to reset the project's ScannerInfoProvider when a
new ICBuildConfiguration is created.
(cherry picked from commit 0f36d5dba1)
Co-authored-by: betamax <evil_bandit_betamax@yahoo.co.uk>
When _SC_OPEN_MAX (max nr of open files limit per process) is a very
big number, then closing all possible file handles can take a while.
This change first tries to use the syscall close_range() if available,
falling back to use /proc/self/fd to close only open file handles,
and lastly falling back to the old way of closing all possible handles
one after another.
In general, the first or second approach should be available
which speeds up the pty spawning.
Refs JetBrains/pty4j#147
Copied from 04685d870f
(which is EPL 1.0)
Co-authored-by: Sergey Simonchik <sergey.simonchik@jetbrains.com>
cherry picked and squashed from commits:
- 7bd8d52c6c
- 24d9bd1834
- 3875408070
We need a new docker container for GitHub that runs as the
same uid that GitHub actions uses so permissions all work
correctly.
(cherry picked from commit 46e37c6d22)
Show the JSON Compilation Database Generator properties page only for
managed build projects.
fixes#847
(cherry picked from commit 597eda2d60)
Co-authored-by: G. Hentschke <123444711+ghentschke@users.noreply.github.com>
Co-authored-by: Jonah Graham <jonah@kichwacoders.com>
It is important we don't point at "latest" URLs for dependencies
as we want to ensure compatibility with 2024-06 and if some
project does a newer release we want to explicitly opt-in to
it on this CDT 11.6 branch
Removed the 'Experimental' label in project creation wizard for Core
Build Makefile projects. Seven years after the inception it's time to
remove it. Core Build Makefile is now in a usable state. The
'Experimental' label scares users away from it, making them fall back
to the old Managed Build Makefile projects.
Added support for LLVM optimization remarks to the GCC c/c++ error
parser. They were falsly treated as errors (OtherError). Now they are
treated as generic infos. GCC has no diagnostic messages of 'remark'
type. Since GCC and LLVM messages are very similar, no separate LLVM
error parser was created.
Fixes#752
The progress monitor didn't show which file was being analyzed properly.
Also, the work units didn't seem to be counted in a good way because the
progress bar would stay stuck at like 1%. The fix in this commit for that is
not perfect as it gives equal weight to all resources on a same level until
further split into sub monitors. It still works quite a bit better without
requiring more heavy changes.
Also fix usage of deprecated SubProgressMonitor.
This is accepted by both GCC and Clang and encountered in real code. It looks a
bit strange but basically a condtionally defined macro was used inside the (())
depending on a configurable feature macro of the project.
Includes:
- Created a new extension point to provide the opportunity to
incorporate additional information into the file
- New tests for the generator
- Preference page to enable/disable generator
Fixes https://github.com/eclipse-cdt/cdt/issues/689
This adds basic support for VS 2022 by detecting the toolchain.
I.e. include paths, lib paths, and PATH env var are properly detected.
The detection works the same as 2017 and 2019 since vswhere.exe works
the same and the folder layout hasn't changed.
Revived from https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/182202
- Configure the JRE for Java 21.
- Clone cdt-lsp
- Include its source locator in the targlet
- Configure both clones to rebase new branches by default.
- Add a working set for the CDT LSP projects.
The simrel and cdt update sites can be used to run partial builds
and are not used by default when doing builds. This change
brings those URLs up to date.
The maintenance of having a streamlined standalone debugger that
starts as fast as possible is no longer possible. See for
example #591 - therefore when using standalone debugger, use
the same sets of plug-ins/features as the product it is installed
in uses. The side effect is that the standalone debugger in this
use case will start slower and extra "stuff" will be present in
this UI.
For people just building the standalone debugger, provide a minimum
feature set. This will be many more bundles than before, but
should still provide a reasonably small set that starts well.
This simplification also includes removing the the duplicates set
of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These
provided a simplified version of CDT's documentation targetted
at just standalone debugger. However there are a few problems related
to this duplication:
- The two sets of docs were not kept in sync
- The standalone docs appear in the online help, leading to
duplicated entries
- With the config.ini changes above, there is no way to exclude
the main docs in the standalone case, so remove the duplicate
A number of directly related clean-ups are included too:
- Remove the `ConfigGenerator.java` that stopped being referenced
in PR #761
- Complete the removal of `build-standalone-debugger-rcp` profile
that was started in #761. There is a small drawback to not having
this profile, the standalone debugger is very slow to build
compared to the rest of CDT. If this becomes a problem, restoring
this profile along with the changes made in #761 is reasonable.
- bring debug.product's licenses up to date
- modernize command line args to eclipse when using debug.product
Fixes#781
Building osxcross is somewhat problematic because the versions
are not fixed and reproducibility of making this docker file
can be problematic. For example new versions of cmake, etc
make be needed. TODO Is there a way to fix the version of
osxcross so that we can rebuild reliably?
- Fix links for cdt-infra
- The cdt-infra git repo is now archived, so this commit updates
the links to the current values.
- Add new Docker related files to the gitattributes as text files
- Update DEFAULT_BUFFER_SIZE for Java 21's value when building JNI,
this also means the dll/exe need a rebuild
- add a toolchains.xml since we use Java 21 toolchain, but most bundles
are Java 17 still
* Switch CI to Java 21
* Remove config generation for debug application
* Remove `org.eclipse.osgi.services` from `proxy.server` product
* Remove `org.eclipse.osgi.services` from
`org.eclipse.cdt.debug.application.product` product
* Move `org.eclipse.cdt.debug.application.product` from profile to
general part
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
