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
Because javax.activation 1.2.2.v20221203-1659 is in SimRel (for now)
it gets picked by p2 over jakarta.activation-api 1.2.2 which provides
the same packages.
As and when we update to Jave EE 9 (IIUC) we should be able to solve this
in a cleaner way and not rely on the old orbit bundles. Also, if and
when all projects contributing to simrel remove 1.2.2.v20221203-1659 then
we can change too.
The other option is to try to force the jakarta.activation-api 1.2.2 into
simrel and the EPP packages, but if we accidentally end up with both in
a product then other things don't work, e.g. like this error:
<details>
<summary>frame work error details</summary>
```java
!ENTRY org.eclipse.cdt.debug.application 4 0 2023-11-20 15:06:47.456
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Could not resolve module: org.eclipse.cdt.debug.application [101]
Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf; bundle-version="2.4.0"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
org.eclipse.cdt.dsf [116]
No resolution report for the bundle. Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.ui; bundle-version="2.4.0"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf.ui; bundle-version="2.7.200.202311031553"; singleton:="true"
org.eclipse.cdt.dsf.ui [119]
Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf; bundle-version="2.0.0"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
Unresolved requirement: Require-Bundle: org.eclipse.cdt.gdb; bundle-version="7.0.0"
-> Bundle-SymbolicName: org.eclipse.cdt.gdb; bundle-version="7.2.100.202303140100"; singleton:="true"
org.eclipse.cdt.gdb [121]
No resolution report for the bundle. Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.gdb.ui; bundle-version="2.4.0"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf.gdb.ui; bundle-version="2.8.300.202309151124"; singleton:="true"
org.eclipse.cdt.dsf.gdb.ui [118]
Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.ui
-> Bundle-SymbolicName: org.eclipse.cdt.dsf.ui; bundle-version="2.7.200.202311031553"; singleton:="true"
Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.gdb; bundle-version="[7.0.0,8.0.0)"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf.gdb; bundle-version="7.1.200.202309151124"; singleton:="true"
org.eclipse.cdt.dsf.gdb [117]
Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf
-> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
Unresolved requirement: Require-Bundle: org.eclipse.cdt.native.serial; bundle-version="1.1.100"
-> Bundle-SymbolicName: org.eclipse.cdt.native.serial; bundle-version="11.4.0.202311201859"
org.eclipse.cdt.native.serial [141]
No resolution report for the bundle. Unresolved requirement: Require-Bundle: org.eclipse.cdt.gdb; bundle-version="7.0.0"
-> Bundle-SymbolicName: org.eclipse.cdt.gdb; bundle-version="7.2.100.202303140100"; singleton:="true"
Unresolved requirement: Require-Bundle: org.eclipse.cdt.native.serial; bundle-version="1.1.100"
-> Bundle-SymbolicName: org.eclipse.cdt.native.serial; bundle-version="11.4.0.202311201859"
Unresolved requirement: Require-Bundle: org.eclipse.tm.terminal.control; bundle-version="4.0.0"
-> Bundle-SymbolicName: org.eclipse.tm.terminal.control; bundle-version="5.5.100.202311142253"; singleton:="true"
org.eclipse.tm.terminal.control [506]
No resolution report for the bundle. Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf
-> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
Unresolved requirement: Require-Bundle: jakarta.activation-api; bundle-version="[1.2.2,2.0.0)"
-> Bundle-SymbolicName: jakarta.activation-api; bundle-version="1.2.2"
jakarta.activation-api [30]
No resolution report for the bundle. Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.gdb; bundle-version="4.2.0"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf.gdb; bundle-version="7.1.200.202309151124"; singleton:="true"
Unresolved requirement: Require-Bundle: org.eclipse.cdt.gdb.ui; bundle-version="7.0.0"
-> Bundle-SymbolicName: org.eclipse.cdt.gdb.ui; bundle-version="7.2.0.202211062329"; singleton:="true"
org.eclipse.cdt.gdb.ui [122]
No resolution report for the bundle. Bundle was not resolved because of a uses constraint violation.
org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.eclipse.cdt.debug.application [osgi.identity; osgi.identity="org.eclipse.cdt.debug.application"; type="osgi.bundle"; version:Version="11.4.0.202311201855"; singleton:="true"] because it is exposed to package 'javax.activation' from resources jakarta.activation-api [osgi.identity; osgi.identity="jakarta.activation-api"; type="osgi.bundle"; version:Version="1.2.2"] and javax.activation [osgi.identity; osgi.identity="javax.activation"; type="osgi.bundle"; version:Version="1.2.2.v20221203-1659"] via two dependency chains.
Chain 1:
org.eclipse.cdt.debug.application [osgi.identity; osgi.identity="org.eclipse.cdt.debug.application"; type="osgi.bundle"; version:Version="11.4.0.202311201855"; singleton:="true"]
require: (&(osgi.wiring.bundle=jakarta.activation-api)(&(bundle-version>=1.2.2)(!(bundle-version>=2.0.0))))
|
provide: osgi.wiring.bundle: jakarta.activation-api
jakarta.activation-api [osgi.identity; osgi.identity="jakarta.activation-api"; type="osgi.bundle"; version:Version="1.2.2"]
Chain 2:
org.eclipse.cdt.debug.application [osgi.identity; osgi.identity="org.eclipse.cdt.debug.application"; type="osgi.bundle"; version:Version="11.4.0.202311201855"; singleton:="true"]
require: (&(osgi.wiring.bundle=jakarta.xml.bind-api)(&(bundle-version>=2.3.3)(!(bundle-version>=3.0.0))))
|
provide: osgi.wiring.bundle; bundle-version:Version="2.3.3"; osgi.wiring.bundle="jakarta.xml.bind-api"
jakarta.xml.bind-api [osgi.identity; osgi.identity="jakarta.xml.bind-api"; type="osgi.bundle"; version:Version="2.3.3"]
import: (osgi.wiring.package=javax.activation)
|
export: osgi.wiring.package: javax.activation
javax.activation [osgi.identity; osgi.identity="javax.activation"; type="osgi.bundle"; version:Version="1.2.2.v20221203-1659"]
at org.eclipse.osgi.container.Module.start(Module.java:463)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1852)
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1845)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1786)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1750)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1672)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345)
```
</details>
The underlying problem here is that the debug application's "product" that
gets converted to a config.ini at CDT build time doesn't expose its
dependencies fully to p2, so we end up with a built product in EPP that
doesn't have everything listed in config.ini.
There is significant maintenance overhead and it is growing to keeping
standalone as it is now working. Other options should probably be considered,
such as using the config of the full product when launching.
Fixes#591
Includes updating to latest target platform. This should
also fix#591 but it is hard to tell until after it is
integrated into SimRel and the output checked in EPP.
Fixes https://github.com/eclipse-cdt/cdt/issues/591
Part of #548
Includes a new system property `org.eclipse.tm.terminal.control.convertBackspace`
to allow us to disable this new behaviour in the field if it turns out that
some terminal/host combination does not like this conversion.
Fixes#392
With the first part of the fix in #603 we recreate the document
regularly (on each context change) therefore we need to let any
consumers of the document fetch the current version of the document
from the editor (by calling getAdapter(IDocument.class)) when
it is needed, rather than caching it.
Fixes#603
The view can be reset in a couple of ways, by changing debug
context or manually refreshing. With this change in Platform
https://github.com/eclipse-platform/eclipse.platform.ui/pull/963
the CDT violation of the API aronud resetting state of the
document was exposed.
Therefore the solution is to instead of trying to reset the
state of the existing document, create a new one when the
view is reset.
Fixes#603
