__has_include_next (extension)
__has_include evaluates whether of the header name passed as parameter
exists. This can only be evaluated as part of a #if directive.
Interestingly, it also has to be reported as defined, i.e. #if
defined(__has_include) or #ifdef. In order to report this as defined,
this implementation adds it as a macro but during macro expansion, it's
actually converted as a dedicated token type. Then this token gets
evaluated during normal preprocessor expression evaluation.
In order to parse header names, there were several options. The main
problem is that header tokens (tQUOTE_HEADER_NAME, tSYSTEM_HEADER_NAME)
are actually produced by the Lexer as part of a special mode
(setInsideIncludeDirective) set during the handling of #include. For
expression evaluation, the tokens are already generated without
setInsideIncludeDirective therefore we only have plain string
and < > tokens.
One approach would be to generate header tokens "earlier" than executing
we need to track a new state while fetching token to configure the Lexer
(setInsideIncludeDirective) when in the context of an __has_include.
There are also complications due to macro expansion within the
__has_include where after one expansion, we don't have a lexer in the
context anymore, introducing more changes.
Another approach would be to remove the Header token creation from the
Lexer itself and let the preprocessor assemble the tokens into an header
string, in both cases of #include and __has_include. This mostly works
and is the approach used in Clang, but the problem is that whereas Clang
keeps track of leading spaces of tokens, CDT doesn't. This means with
such change that CDT would now allow #include < iostream > (notice the
white space). I think this is too big of a downside and also too big of
a change to introduce this handling of whitespace at the token level.
The approach used here is more conservative and isolated but also shares
less common logic with #include processing. The non-header token
(string, <, etc) are assembled into a header string only in the case of
a __has_include. So a downside will be that #include and __has_include
will be inconsistent in regards of leading/trailing space parsing but I
feel like this is better than making #include more permissive.
Change-Id: I5b9f5c616c8d999e0c916a85b41f96e20037b651
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
Make sure the project is still accessible before doing the work.
It's possible that the project got closed before the job had a
chance to start.
Change-Id: If02e818394502397e8958d18284160d4f08ca195
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
Move sources from src/main/java to src.
Change output dir from target/classes to bin.
Change-Id: I348fdf2960d183e6ba8ddf1b7971c494fb2bca9c
Signed-off-by: Martin Weber <fifteenknots505@gmail.com>
It is the same as GCC built-in provider but with tweaked parameters to
pass to Clang driver. It has to be enabled by hand since there is no
toolchain associated with it for now.
Change-Id: I5455d04725b2ee4709844d32ee32d355d120d807
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
Optimize AbstractLanguageSettingsOutputScanner.findResource by checking
under the currentProject first when searching for the IFile
corresponding to the parsed file name.
When the parsed file name is absolute, we can try to make it relative to
the current project and see if it exists as an IFile instead of going
through findFilesForLocationURI which is very slow. Having an absolute
path for the source file is quite common under the current (local)
projet.
This saves around 1.5 sec when parsing all commands of LLVM projet as an
example.
Change-Id: I576a917410e5d5ecbd8e932011555c699b250354
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
Bug 549697 introduced the new UI for setting colors, but the
selection color (while added to the pref page) was never
connected to the code.
Change-Id: I9934efe595efe141a14f0bca3bdf355f436d907d
- fix Core Make Makefile template to add one for linuxtools
build mode which is used for Linux Tools profiling
- fix the error default to change tab indent to spaces so
make won't treat error message as recipe
- add some default profiling flags for gcov and gprof support when
Linux Tools profiling
Change-Id: I29c2247c9e2b00a4e1c1952198faf881abd7a66a
Requires https://git.eclipse.org/r/c/lsp4e/lsp4e/+/168414
Allow LS to be started
from "Generic Editor" only
and
if ".settings/org.eclipse.cdt.lsp.core.prefs" has "prefer=false"
actually this blocks LSP from launching until user will configure it
explicitly.
UI to configure for workspace and project.
Change-Id: I7104d21f90380a5de7ccae157ea4299e0558a27c
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
Use https://download.eclipse.org/lsp4e/releases/0.16.0/ instead of
snapshots for CDT 10.0 stream.
Change-Id: I163c3de4723facb45eb23a548174e8a4cd6c0e5c
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
This make messages stand out more prominently in the build console.
Change-Id: I180a7eb6631870004cca94a7f1d2c8bda5b044f8
Signed-off-by: Martin Weber <fifteenknots505@gmail.com>
And prepare to make it an error in CDT to not have properly handled
an Autocloseable which means a number of fixes to make sure handles
are closed.
Change-Id: I36cd46017bbce6ece1703d688d7754e523eca68f
Some CDT preferences use \0 as a separator in preferences. Somewhere
in the Oomph preference synchronizer stack there is, or was, a place
that failed to escape/unescape preferences with encoded \0 properly.
CDT would then fail to parse the preference and an exception would
be raised, causing code completions and the editor to be broken.
This patch hardens the CDT code to:
(1) Allow an escaped \0 to be used as a separator on
read (Oomph uses ${0x0})
(2) Handle NumberFormatExceptions gracefully. In this case that means
showing user a pop-up that their completion preferences
are empty and offering to reset them, or edit them in preference
page. This UI logic already existed, so all the new code
has to do on failed parse is return a list of all disabled
completions.
Change-Id: Ibf3b05c0855bb96c195ca43139a50c27a2a90c7e
The multi launch was moved to Eclipse platform 3 years ago,
this change removes the now deprecated version that was in CDT.
Change-Id: Ida3c4873b182a9e84955ac187ca9525703dc0298
This makes it consistent with how environment variable uppercasing
was documented as they are similar.
Change-Id: I580f599e77db08285753d47c62f46120abd8f9bd
buildInfo is null in the case that the node list is empty.
Change-Id: I165ec31eeeab57e1eb7bed0268d0f83c70d6e0f7
Signed-off-by: Torbjörn Svensson <azoff@svenskalinuxforeningen.se>
Removed useless catch block that just rethrows the same exception
Change-Id: If3e4faea1ed889d4f7b39a7cff786e0aa9a6803d
Signed-off-by: Torbjörn Svensson <azoff@svenskalinuxforeningen.se>
* Bundle-Vendor should be Eclipse CDT
* Added missing Bundle-Name attribute for some bundles
* Synced MANIFEST.MF and properties file for keys
Change-Id: I14e3b1cc35e7ae88a1585d8ab19cede682bd4fce
Signed-off-by: Torbjörn Svensson <azoff@svenskalinuxforeningen.se>
As more checks have been added it has gotten a little unweildy.
The new script "do_all_code_cleanups.sh" now does most of the code
formatting checks.
Change-Id: I65fd888c88e1d7e470ed5621cee18ff3bf6680b4
This change causes incompatibility for users using the \${ to not
expand environment variables.
Tested with sloeber (700+ projects)
Change-Id: If327f055a41c309c475e17e0239a30e7518c3b23
Signed-off-by: jantje <eclipse@baeyens.it>
Device contributions should now extend DefaultGDBJtagConnectionImpl and
provide default connection details in the JTagDevice extension
declaration.
Launch configurations providing legacy connection data (ipAddress and
portNumber) are accommodated at launch and upgraded to use connection
URIs when edited.
Change-Id: I36b5d3e49f1d8f0becf1b898b7a48eb239453f1b
