For ISV integration/extension to CDT CMake, it is necessary to extend
several non-API classes (eg: CMakeBuildConfiguration,
CMakeBuildConfigurationProvider). This would cause "Discouraged access:
The type XXX is not API" warnings.
The classes have now been made API so can be extended without warnings.
Addresses Issue: CDT CMake Improvements #1000, IDE-82683-REQ-017
Extending CMakeBuildConfiguration
The docker images all have new, simpler names and use Ubuntu 20.04
(instead of 18.04) as their base.
A few new tools have been added, specifically what is needed for:
- Linux on RISC-V - see #980
- Winodows on ARM - see #969Fixes#976
Refactors the initialization code of PTY to allow code to avoid
loading WinPTY if it isn't needed. The previous code would
load WinPTY even if ConPTY was in use.
To achieve this the code was refactored to have cleaner state
with a new field ptyType that replaces isConPTY, isWinPTY and
hasPTY.
This is needed so that WoA can run without needing to port the
unneeded WinPTY library. In particular, the winpty.dll and
pty.dll are no longer used on WoA.
Part of #969
- add a new fragment 'org.eclipse.cdt.core.win32.aarch64' containing
re-compiled Arm64 natives suitable for the Windows on Arm64 platform.
- add the 'serial.dll' binary re-compiled for Windows on Arm64.
- add the win32/win32/aarch64 environment triplet to various Maven
build scripts to support building CDT software for that environment.
The updated dlls/exes are not included in this commit and will be provided
in subsequent commits with the corresponding update to build infrastructure
Part of #969
The documentation for GCC, and other compilers, stipulates that
__DATE__ with a day of month less than 10 should be prefixed by a space,
not a zero.
Contributed by STMicroelectronics
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
_This commit adds to #8407bd8d52c6c to apply the same fix to
another place that does the same operation on all fds._
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>
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>
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.
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
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.
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
[703] fix NPE when no build binaries on system PATH
- fixes NPE when new cmake project has been created while there are no
C/C++ build binaries on the PATH environment variable. The NPE has been
thrown when the children of the project should be fetched (e.g. in
project explorer view)
- fix NPE cause in ErrorBuildConfiguration
- fix unit test
fixes#703
Display the new more accurate error when all candidates were failed
instantiations. Otherwise, if there is a mix of failed instantiation and
wrong number of arguments, display the old message.
This could really be improved even more...
template<typename T>
void function() {}
Before:
function(); // Invalid arguments 'Candidates are:
After:
function(); // Cannot instantiate template function 'Candidates are:
### Changes
With this PR, `PreprocessorMacro` and its subclasses are no longer package-private but public instead. Same goes for `TokenList`.
### Reasons for the changes
When parsing C/C++ code with CDT as a standalone library I want to track certain macro expansions using the [MacroExpander](https://github.com/eclipse-cdt/cdt/blob/main/core/org.eclipse.cdt.core/parser/org/eclipse/cdt/internal/core/parser/scanner/MacroExpander.java).
It is not actually part of the public API but declared as `public`. It takes an argument `macroDictionary` of type `CharArrayMap<PreprocessorMacro>` in its constructor. Currently, `PreprocessorMacro` is package-privat and thus, not available without shadowing (i.e., implementing my custom macro tracker in the package `org.eclipse.cdt.internal.core.parser.scanner`).
It questionable whether it is a good design decision to have public and private API mixed together here (rendering the usage of the constructor of `MacroExpander` impossible).
Also, another problem occurs once you take the route of shadowing to have access to `PreprocessorMacro`: the CDT jars are all signed during release (makes sense) but, sadly speaking, that will result in a `SecurityException` when trying to call their API from your own (unsigned) code which lives in the shadowed package (in my case in `org.eclipse.cdt.internal.core.parser.scanner`).
### Problem solved
MacroExpander can now be used from the outside because `PreprocessorMacro` and `TokenList` are no longer package-private. Shadowing is no longer needed. Signed jars are no longer a problem.
Current partial specialisation selection matches deduced type by
IBinding, not by IType, meaning that it can't work for types (such as
primitive types) that aren't represented by an IBinding. Fix that by
wrapping the result of resolution in a type which can handle either.
Turned out that index is missing information about template parameters of
deduction guide templates, and all affected names which are only available
via index could not be resolved. This happens to e.g. std::map<> which is
usually looked up via index populated from <map> header file.
Fix this by implementing ICPPTemplateParameterOwner and ICPPTemplateDefinition
interfaces in new CPPDeductionGuideTemplate which delegates missing resolution
calls to the function object which already carry required template information.
Closes#438
Add new index binding resolution test strategy SinglePDOMReindexedTestStrategy
which does reindex project after adding test case sources. Clean up redundand
C++17 setup helper classes from test since deduction guides are always enabled.
Add test case modelling std::map resolution problem and make sure to run it with
new test strategy to reproduce the issue.
Bug #438
This change prevents invalid partial specialisations from being chosen
when
instantiating a template in cases where the expression for the
type/value of a template parameter involves a constructor call.
When AST is used to resolve binding for class-name and elaborated-type-specifier
is found matching [basic.lookup.elab] rule introducing the class-name, behavior
of CPPSemantics.resolveAmbiguities() is different in presence of index.
If there is no index, CPPVisitor.createBinding() for ICPPASTElaboratedTypeSpecifier
creates binding for class-name as introducing the name. When later lookup finds
this binding all is good because binding is declared before the use site.
If index is available, lookup for class-name fails in AST too but now matching
entry is found in the AST index. When later lookup finds this index binding
CPPSemantics.declaredBefore() returns false because it does not look in
AST index and only checks project index.
To fix this additionally check if ICPPClassType object is in AST index,
as we already do for ICPPConstructor. This way declaredBefore() does almost
the same thing as isReachableFromAst() and lookup succeeds returning the
same binding from index.
* remove invalid tycho resolver config (not valid since many versions)
* fix PMD plugin configuration (config attribute was renamed in 3.18)
* remove duplicate versions already managed in pluginManagement section
* fix indentation
* move all not yet configured versions into pluginManagement of the
parent module to avoid further duplication
* consume the target platform as file, not as maven artifact (this
simplifies building a single module A LOT)
* remove invalid tycho-source-plugin configuration
* disable tycho consumer POM generation (not needed here, and avoids a
warning in each module)
* remove prerequisites. that's for maven plugins only, and this POM
already contains the better suited similar maven enforcer rule
* enforce UTF-8 for javadoc generation (the build fails on Windows
otherwise, trying to read some Japanese? characters with the Windows
default encoding)
