Beta versions of maven plugins are omitted from this
upgrade.
A new version of Tycho brings in an update ECJ which means some
of the class files are different, hence the need to bump versions
of bundles too.
A new calendar year brings an update to Copyrights
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:
Some bundles are bumped because dev happened between 11.2 release and
this version bump. The most significant change that happened
was the bump in Tycho version which changed ECJ version and
hence some class files changed
Part of #420
When we update Tycho we pull in a new version of ECJ which means
we can get some differences in the class files even though
there is no difference in the source. This commit bumps
all the bundles that are affected by this.
This is kept as a separate commit from the Tycho update
because if we need to revert the Tycho update we would still
need to bump all these bundles to make jgit timestamp qualifier
happy.
Part of #320
See also #308
If name lookup ends up with a variable, additionally check if node being
resolved is part of the structured binding initializer introducing found
variable. If this is the case, produce problem binding and report structured
binding declaration error via codan.
This change also prevents infinite recursion trying to resolve auto type of
introduced variable while evaluating such problematic initializer.
Warning in build.properties will be errors when they run
in the tycho build, like this:
```
Error: Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:2.7.5:package-plugin
(default-package-plugin) on project org.eclipse.cdt.core.tests:
/home/runner/work/cdt/cdt/core/org.eclipse.cdt.core.tests/build.properties:
bin.includes value(s) [test.xml] do not match any files. -> [Help 1]
```
So make them errors in the workspace so that the issue is
detected before push.
Some build.properties issues don't affect the build, but
are still indicative of a problem.
The CDT Cleanup profile had a bunch of extra cleanups applied to it, this
prevents running the CDT cleanup profile manually to simulate running the
save actions on all Java files
Change-Id: Iad491e1258a4ba90d81d1457ea0f6779e3663e38
All the about.html files are updated, so every bundle that hasn't
already had a bump in 10.7 needs one now
Change-Id: I6143d2fbe77a58a3a6d2f4a226d96087117f9ac1
Add a new option to check in macro expansion. User, if want, can
disable this warning if it's in a macro expansion since the macro
used can be out of control of the user, for example a system
macro like FD_SET could be used.
Change-Id: I0efaaedd09087de87d9340d81ddbd7f2dc1e1abb
Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
Added new checker for variable masking another in a parent scope
Change-Id: Icff6b6499a1d38cc5a719d143552bbe17d57b15c
Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
Checker checks for multiple declarations on one line and
static variables defined in header files.
Change-Id: Ibc9670ee129e9bdd3ea58ac5409493fd99c4a234
Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
We have the "universal resolution" in an ArrayList and they are used as
single instances. So what can happen here is that we add the same
universal resolution instance multiple times for several markers.
However this approach can't work because a "marker resolution" is
designed to fix a single problem. Indeed the last marker analyzed
override the previous one in the single "universal resolution" instance,
so what we have is N proposals pointing to the same resolution where the
problem description is just the latest one. To solve the problem we
instantiate the universal resolution multiple times.
Change-Id: I072ca0b4dabff9781d6230a218eeb7dd388c648d
Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
