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)
I don't remember exactly which code didn't parse for me initially
(probably MSVC), but I've found this in some std::is_function
(type_traits) implementation:
#ifdef __clang__
__is_function(_Tp)
...
This is a missing built-in in CDT.
When the variable template was instantiated through an implicit name
(constructor), the current look-up point was used to determine whether
or not the variable instance was an explicit specialization but it's not
enough. During resolution of implicit name, the look-up was on the
constructor call, not on the variable instance. I'm not sure if the
current look-up should be changed but we already had the information
about the AST node being an explicit specialization down the stack, so
we just pass that info now and it seems safer than changing the look-up
point.
This class is intended to mirror the capabilities of the ElfHelper class
over time. Initial support allows for correct presentation of section
sizes within the Eclipse Properties view when a PE64 object file is
selected.
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>
