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>
Use List<IProject> instead of raw List
Use HashSet<IProject> instead of raw HashSet
Change-Id: I583daad225f828345d7109dba582ad5507431d65
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
Use Map<String, String> instead of raw Map
Use Entry<String, String> instead of raw Entry
Change-Id: I6e9ffc4dad34fcb8d2b0b1db04cfc901d9225f74
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
Attributes `url` and `version` can be omitted for features
Change-Id: I37ef5f52cd3a22dc9ccbce0905aa6642edf60a39
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
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>
The generated elf file is still checked, but the makefiles are auto-
generated and have full path names in them, meaning that different
Jenkins jobs (with different workspace paths) cause a difference.
Change-Id: Iaa2eab80ba4b116c06ff1f765160a8580c0dafff
Instead of pop-up NPEs and hung UI, log once that QML Analyzer is
unsupported.
Change-Id: I4ad599e870bd73f5cbda8992dedb14405af545f4
(cherry picked from commit 6d76cc5839)
Narrow down parsers based on option string
Instead of trying to match all patterns one by one, we can check the
start of the option string to be parsed and narrow down which pattern
(parsers) should be used.
Doing so is much less elegant code-wise as we are "unrolling" the
beginning of the patterns by hand, but it gives a good speed up. Around
300ms saved with a test of LLVM code base (~50% of parseOption time) and
much larger gains on much larger projects or course.
Change-Id: I9e841e7233078d6e38ad08943d98966d0e3c661e
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
Add repository list for 2020-12
Update Orbit to 2020-12
Change-Id: Ib1dd63606be177e0e17000903c9efe5aeea851fa
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
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>
Fix a NPE I just introduced. This method gets called before things are
initialized, just like before. I prefer being conservative by restoring
previous behavior and not change too many things by revising the
initialization sequence at the same time of other bigger changes.
Change-Id: I1096621e29b51c67d218c7e55eaf3ebe29858d07
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
With this change, support for VS 2008, 2010 and 2012 is dropped
and support for 2017 and 2019 is added.
The new detection uses vswhere.exe as we cannot rely on registry keys
anymore. We also retrieve correct values for INCLUDE, LIB, and PATH
by executing vcvars.bat, which is less brittle and hard-coded than
before. Doing this also partially addresses bug 357980.
We also now store knowledge about multiple VS installation (one for
each major version) and related MSVC toolchain. This is one step closer
to letting users choose which version to use and store this per
configuration in the project.
Change-Id: I3b3579d8c6742ef232626b5e5294bb6f8634a326
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>
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
