* Unify pointer checkes
* Avoid using negated conditions.
* Reduce scope of local variables when possible
Change-Id: Ibacd13126351019af544f3e22513654d5ffee342
Signed-off-by: Torbjörn Svensson <azoff@svenskalinuxforeningen.se>
This will enforce formatting when building the native code
Change-Id: I6c047f4c0672609df322b7ba716fc786f0e3aab4
Signed-off-by: Torbjörn Svensson <azoff@svenskalinuxforeningen.se>
The comment is part of the generated header file
Change-Id: Ie890ad4d906c0f4e6a23b2a42a1ef342d1da8865
Signed-off-by: Torbjörn Svensson <azoff@svenskalinuxforeningen.se>
Added a new C/C++ formatter profile called "Unmanaged profile 'CDT'"
(name stolen from the Java formatter) that is basically K&R with the
tweak of maxium line width set to 120 (same width as for .java files).
Added enforcement of the formatter during build.
libspawner.so/jnilib have differences because the re-formatting changes
line numbers and therefore the __LINE__ macro expands to a different
value.
Change-Id: Id3a0619cb31640c7817dc684c72139f90cab0fc6
Signed-off-by: Torbjörn Svensson <azoff@svenskalinuxforeningen.se>
Change the default workspace indexer setting
Use the active configuration by default, which is less confusing because
the UI is properly reflected on active config change. Using a fixed
config can be seen as a more advanced setting for performance concerns.
A new preference is added, only used at default scope:
org.eclipse.cdt.core/cprojectdescription.configRelations
This can be used by products to customize the default according
to their needs (plugin_customization.ini).
This was done because this is a fairly impactful change for users.
Change-Id: I35888ffe5bc1814943f432f88a12094394924c88
Signed-off-by: Alex Freidin <freidin.alex@gmail.com>
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
I don't think "inheriting" by hand the background colors is supposed to
be done like this. Removing the lines setting the background to be the
same as the parent fixes the issue. I also verified all places in the UI
before/after the change.
Change-Id: I2eb4cc5afdd303d5d5613fc3d50d67d0c18c7028
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
CoreModelUtil.findTranslationUnit only returns CElement in the populated
CModel of a project. This shouldn't change as a large majority of client
code need to see the model this way and not consider files that are
outside source folders. So for a file not under a source folder (and
therefore not in the CModel), we can just create a new translation unit
instance for it. This is actually how the editor deals with it too.
Change-Id: I8898822e94cac8562edcc0a726fdd8680119faca
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
Version changes are all to refect non-API changes (micro version)
Change-Id: I372aa2671a4c7f5c765a42156d3f639b8eaff680
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
These were already there for GCC but not for Clang and they are
supported by Clang:
__is_literal (synonym for __is_literal_type)
__is_standard_layout
__is_trivial
__is_trivially_copyable
__float128
__int128
Change-Id: Iec6151492cd30f17e2a5aa4617f6e88812f0f4cc
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
I'm not sure how sufficient this explanation is but it's better than
leaving just "// Why?" for that central piece of code in CDT.
Change-Id: I0858f83b8f4fbe65fd869e96fb210b5af7d16f65
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
IWorkspace.validateEdit should only be called if the file is read only.
Quoting IWorkspace.validateEdit javadoc "A client (such as an editor)
should perform a validateEdit on a file whenever it finds itself in the
following position: (a) the file is marked read-only, and (b) the client
believes it likely (not necessarily certain) that it will modify the
file's contents at some point."
Change-Id: Id73d3629f9ce276b931ed586a6dbf19199d56831
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
__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>
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
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>
As mentioned in
https://devblogs.microsoft.com/oldnewthing/20180103-00/?p=97705,
Microsoft has stopped using the _IMAGE_FILE_HEADER.TimeDateStamp as a
time stamp and rather as a hash of the source files to make the build
result predictable.
Change-Id: I4f4a7b9557330e4c478ef7fb25653144c5b2d4ad
Signed-off-by: Torbjörn Svensson <azoff@svenskalinuxforeningen.se>
Do not pretty-format *.language.settings.xml files in the workspace
plugin state area. These are not meant to be shared and looked by users
so they do not really need to be pretty-formatted. This saves a lot of
time for large projects with per-file language settings. For example, I
have seen this save 30 sec on a test project during serialization.
Change-Id: I27f8e0cfdc593f084d95bbed7aedb707570f1f6d
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
- modify ProcessFactory to prefix commands with flatpak-spawn
when running under Eclipse flatpak
- add new FlatpakLaunch class to dsf.gdb to do a prelaunch
of gdbserver and set up remote port settings when debugging
local C/C++ application under Eclipse flatpak
- add new tab to gdb when running under Eclipse flatpak
to allow user to specify gdbserver and port number
- add new org.eclipse.cdt.flatpak.launcher plug-in which
contains a FlatpakCommandLauncherFactory to handle copying
header files from host to workspace when developing under
Eclipse flatpak
- add new FlatpakCommandLauncher class which simply extends
CommandLauncher and can be used for debugging purposes to
distinguish from regular command launcher
- also add new FlatpakHeaderPreferencePage to allow C/C++ users
to delete copied headers if needed
- dynamically add the headers preference page from
FlatpakCommandLaunchFactory
if running under Eclipse flatpak
- add new ICommandLaunchFactory3 to add an interface to check if
headers have been modified/removed and scanner info refresh
is required
- add new org.eclipse.cdt.flatpak.launcher-feature
- give higher priority to ContainerCommandLauncherFactory so if
running on Eclipse flatpak, the flatpak factory won't be chosen
if both apply (i.e. building in a container but running on
Eclipse flatpak)
Change-Id: Id68e60c4dd37c4494af10440231ac7b7bbec8d17
As the memory browser configuration is preserved in the launch
configuration file as an indented serialized XML string, the string will
contain the result of System.lineSeparator(). As the launch
configuration file can be shared among developers with different
platforms, there is a risk that the launch configuration file is always
modified although there is no real modification, just line endings.
To avoid this scenario, always save the XML string without any
indentation or line endings.
Change-Id: I94497a924f7aa5a881ac6a32f146d2cbceb6324f
Signed-off-by: Torbjörn Svensson <azoff@svenskalinuxforeningen.se>
Remove all equalIgnoreCase and equal with uppercasing for environment
variables
Change-Id: Ic15974b5fb62413c7b1826ced544ff6d4a8eba2f
Signed-off-by: jantje <eclipse@baeyens.it>
The Windows registry can be checked for keys that may not exist.
In order to avoid logging an exception that the entry is missing when
it's not critical that the entry do exist, the method should just return
null and let the caller handle if it's critical or not that the entry
exists. To easily debug situations where the entry is supposed to always
exist, the trace symbol
"org.eclipse.cdt.core.native/debug/win32/registry" can be set to "true"
and the exceptions will be logged in any case.
Change-Id: I6603cbe363ebecd357fa44c41fb1a26c6345dd70
Signed-off-by: Torbjörn Svensson <azoff@svenskalinuxforeningen.se>
Sets the pattern to the default of upcoming tycho 2.0 in advance.
Signed-off-by: Martin Weber <fifteenknots505@gmail.com>
Change-Id: I31b3fc733d0cb888fbf6f566995ce2043f6cd621
