[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
The Launch Bar Launch Configuration, Build Settings tab allows the user
to customise the CMake Settings (CMake generator, extra arguments, build
command and clean command). But changing these settings did not affect
the CMake build. This is now fixed.
A "Use these settings" checkbox allows the user to choose settings from
the UI or use the operating system defaults.
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)
When launching a GDB debug session using the Launch Bar and a Launch
Target, now the launch takes into account a REMOTE_TCP value in the
launch configuration before considering the type of the Launch Target.
Improves the change submitted in:
Bug 547881 - Allow targets to set ATTR_REMOTE_TCP
Fixes issue #622
Cursor not behaving correctly in memory view editor while
chaging variable value on Hi-DPI #641
Used GC.textExtent() method for getting width of a character as
it handles zooming factor
Fixes https://github.com/eclipse-cdt/cdt/issues/641
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.
[#407] fix CompilerBuiltinsDetector for msys2 on Windows
The cc.exe from mingw64 (part of Msys2) on Windows needs the bin folder
to be on the PATH to be executed. e.g. 'C:\msys64\mingw64\bin' must be
part of the PATH environment variable
fixes#407
