CSourceHover did not know how to handle UnknowMemberClasses
Change-Id: I4ef6a4ad794e670c4d5e9ccc9cea204f8d273f2a
Signed-off-by: Michael Woski <woskimi@yahoo.de>
As ArrayContentProvider is stateless, re-using the global instance
avoids a few allocations.
Change-Id: Ia378195c2c90e35badcf6e2c1938a93877a442e6
Signed-off-by: Andreas Sewe <andreas.sewe@codetrails.com>
When creating the settings.xml, avoid writing to the file unless
the contents have actually changed. This avoids a resource delta
that caused unneeded rebuilds.
Change-Id: I83cea84e96d006f99a1c264f283d4bba4ad68784
This resolves a significant UI performance regression so
now line numbers don't need to be recalculated for areas
where they are already known.
Change-Id: I4668d620cde24b7cd8c6a22e9c022eaf5b237ff2
Adds in Core Build support for the MSVC toolchain. Fixes issue
with PATH in the core build configuration since on Windows it's often
Path.
Change-Id: I3eb201bc22bf42341207e8f3bbef999d4d174f05
(cherry picked from commit 7f3745c765)
- Change parser to include virtual specifier in function declarator
location
- Change DeclaratorWriter to write all virtual specifiers in their
initial order
Change-Id: Iff381394b834146c1b63877bc9eb84517d31e078
This allows querying alias template instances for their arguments (for
e.g. instantiating dependent arguments later).
Change-Id: I7cc3dfcef75fe0faf104dc7bfe11e2acd90a4748
We previously modelled alias template specializations as alias template
instances, which was conceptually incorrect and problematic for a number
of reasons.
Change-Id: Ibca8b87bb3d54cd3ae312254a02e8522e446331d
Besides the UX advantages of typedef preservation (such as refactorings
preserving typedefs), it's important for correctness because the
arguments of template aliases can be subject to SFINAE even if they
don't participate in the target type.
Change-Id: I4e71372553dc418d1b8c3e27bd2c0387a41a3269
When checking whether gathering the build output from a
CBuildConfiguration, if a binary is a shared library and is an
ELF file, dig deeper and see if it has an INTERP section in the
program header. That tells us it's actually a PIE executable and
add it to the list.
As a rider to this bill, improve the error message when a Qt install
can't be found for a given toolchain/target.
Change-Id: I8fd0bf2d204e9425b02916d7b17f4309a5ad9dd5
(cherry picked from commit 14b07f490c)
If we are merging two env vars and the operations are both
append or prepend, keep that as the operation instead of
replace.
Change-Id: I758a54b8903eabafac38bf2f3f7d7065c0373e70
Out-of-line definitions where the definition is in a different file
than the declaration are not supported yet.
Change-Id: I3631bdb3e08abe2aab266065c7858c66170fb570
This allows reusing more code, such as CommonCPPTypes and
BindingAssertionHelper, between the two test suites.
Change-Id: I8203191fc3a10565add0ae1bd25c98f743cd1e64
This ensures that, when instantiating the function call, we get into
EvalFunctionSet.resolveFunction(), and check that the function is
actually callable with the instantiated argument types, and error out
if it isn't (which is important for SFINAE purposes).
Change-Id: Ia01755bc1a830fded1f61658f4beef875cc0b029
Re-wrote the BuildConsolePartitioner to do as many operations as possible
in the non-UI thread and only to update the UI thread in batches.
Key changes:
- The UI thread "pulls" changes when it is ready, this means that many
lines of output are updated in one go. This compares to the "push" that
the non-UI thread used to do. The previous code pushed a change to the
UI thread on every line of build output.
- The limit on console size is now soft, rather than recalcuating the
entire document on each line (i.e. add line at bottom, remove line
from top) the document is truncated to the limit size as it reaches
2x the limit size. This calculation is also done more effeciently by
tracking the number of lines each partition contains rather than
recalculating them.
- Folded most of the implementation of BuildConsolePartition into
BuildConsolePartitioner. This is because the partioner has a global
view and is much more efficient at determining if adjacent partitions
can be combined. In addition, rather than having the complexity of
splitting partitions that were too long, instead make sure we don't
create such partitions in the first place.
Change-Id: I47543db3fef754e779684cae44d3316982f1bc0a
