When building type hierarchy the pointers to list
elements were put into queue. Later, the list was
modified and it was possible that list detaches
causing stored pointers to be invalid.
Simplify building type hierarchy by adding helper recursive
methods.
Fixes: QTCREATORBUG-28529
Change-Id: I240513fc097536d2175e2242766127b92aaa6a82
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... involving using declarations.
See also aae3ce15aa.
Fixes: QTCREATORBUG-28386
Change-Id: I4171dce7b4e34b41c4a894e3bb34b3f62f82ac0f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This includes one functional change: It drops some cleaning
of the path used to create the CppDocument, which is now
assumed to be done on the caller side.
Change-Id: I5e2a182028e4d5b56282ad85f4a5c665f081754f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace.
Task-number: QTBUG-99313
Change-Id: I88edd91395849574436299b8badda21bb93bea39
Reviewed-by: hjk <hjk@qt.io>
Amends 0fab5956ea.
We want to avoid carrying these eight bytes ber Class instance around.
Instead, we now just replace the (anonymous) struct name with the
typedef'ed one.
Note that in C (but not C++), this is possible:
struct S {};
typedef struct {} S;
struct S s1;
S s2;
However, our code model has never respected the extra struct namespace,
so it can already not distinguish between occurrences of "S" and "struct
S".
Change-Id: I55feafea7d3a4a5848e10f7011f633a2ce0f626e
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Use the named members instead. The operator() versions have been used
only in a handful places, not using them makes things clearer on the
user code side.
Change-Id: I9b44371e094d498ff6ebfa9ecbe32f8654a63d4d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Depending on context, callgrind sees contributions of >8% to
the total cost of project parsing for these functions. The
functional are actualy executed executed out-of-line, often
for a function body of one "payload" instruction only.
Inlining removes the call/endbr64/ret overhead.
Change-Id: I6886f08e322fcaa4e0f54d424279e0a8c24e4718
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... when creating the constructor implementation for a derived class.
We would erroneously strip off the class name.
Amends aae3ce15aa.
Change-Id: I62c800d490626e8cb9416829633f9ef7b0c666cd
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... when using declarations are involved.
Second attempt.
I have a suspicion that this is not the "correct" approach, however:
a) It appears to fix the problem.
b) It does not break any tests.
c) It's rather high in the call tree, so there's a low likelihood
of breaking something else.
d) Considering the hacky-looking pre-existing code dealing with
using declarations (e.g. LookupContext::lookupByUsing()),
it seems quite possible that there is no "correct" way with
the current infrastructure.
Fixes: QTCREATORBUG-14524
Change-Id: I28c6e53137c21ce158bbd03b92b3db39146116d5
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This effetively reverts 87ec0f349f, which had unwanted side effects.
Change-Id: I03438c18f43b07a6560416af746132bc4471fbb7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... when using declarations are involved.
Fixes: QTCREATORBUG-14524
Change-Id: I0c391b88628f40973b6f601e60c64263f62a88a0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Code snippet:
template<class T> struct MyStruct { int value; };
int main() {
auto s = MyStruct<int>();
s.value; // "value" is not found
}
This fixes find usages for unique_ptr declared as auto like this:
auto ptr = std::unique_ptr<MyStruct>(new MyStruct());
ptr->value;
Also fixes in-place constructors:
std::unique_ptr<MyStruct>(new MyStruct())->value;
Fixes: QTCREATORBUG-15364
Change-Id: I8d452a77fe85e63665ec8d4c4afbcf8aad063121
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
These changes target Find Usages feature to work with shared_ptr.
Improve libs/3rdparty/cplusplus and plugins/cplusplus:
parse __declspec() attribute,
call to variadic function template without specified template arguments,
if constexpr,
c++11 attributes [[value]],
function templates with default parameters,
resolve order for function vs template with default parameter,
template operator->() with default arguments,
template specialization with numeric values,
find best partial specialization,
fix partial specialization for non-first specialized argument
Fixes: QTCREATORBUG-7866
Fixes: QTCREATORBUG-20781
Fixes: QTCREATORBUG-22857
Fixes: QTCREATORBUG-17825
Change-Id: I31a080f7729edfb2ee9650f1aff48daeba5a673b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Nikolai Kosjar <pinaceae.pinus@gmail.com>
Recently tons of warnings show up for presumably "problematic"
singned <-> unsigned and size conversions.
The Qt side uses 'int', and that's the biggest 'integration surface'
for us, so instead of establishing some internal boundary between
signed and unsigned areas, push that boundary out of creator core code,
and use 'int' everywhere.
Because it reduces friction further, also do it in libcplusplus.
Change-Id: I84f3b79852c8029713e7ea6f133ffb9ef7030a70
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
...due to indirect recursion:
...
CPlusPlus::ClassOrNamespace::lookupType LookupContext.cpp 833 0x7fffd6c954cc
CPlusPlus::ClassOrNamespace::nestedType LookupContext.cpp 1364 0x7fffd6c94bc6
CPlusPlus::ClassOrNamespace::lookupType_helper LookupContext.cpp 955 0x7fffd6c9517f
CPlusPlus::ClassOrNamespace::lookupType_helper LookupContext.cpp 983 0x7fffd6c952ad
CPlusPlus::ClassOrNamespace::lookupType LookupContext.cpp 833 0x7fffd6c954cc
CPlusPlus::ClassOrNamespace::nestedType LookupContext.cpp 1364 0x7fffd6c94bc6
CPlusPlus::ClassOrNamespace::lookupType_helper LookupContext.cpp 955 0x7fffd6c9517f
CPlusPlus::ClassOrNamespace::lookupType_helper LookupContext.cpp 983 0x7fffd6c952ad
CPlusPlus::ClassOrNamespace::lookupType LookupContext.cpp 833 0x7fffd6c954cc
...
ClassOrNamespace::lookupType(const Name *) already guards with a list of
entries already processed, but some calls deeper the list is not passed
on and lookupType() starts again with an empty list. Handle that case,
too.
Task-number: QTCREATORBUG-18499
Change-Id: Iab8978f6ac1d0aea16f49b3547415f43de887b07
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
The modification of the TemplateNameId changed "global state" because
the TemplateNameId is potentially accessed by multiple threads doing
lookup (access to same document and thus same symbol names).
Depending on the thread scheduling and access to
ClassOrNamespace::_specializations, the changed TemplateNameId
"suddenly" led to inconsistent results of TemplateNameId::Compare and
thus broke the std::map assertions.
Get rid of the const_cast, the setter and simply construct a temporary
TemplateNameId with isSpecializaton = true.
Task-number: QTCREATORBUG-14911
Change-Id: Ie381d132cc0d06af351ace4257773637d1ebee4e
Reviewed-by: Przemyslaw Gorszkowski <pgorszkowski@gmail.com>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
...which was least buggy.
The bugs fixed by the changes we revert here (highlighting/completion
for code involving templates) were minor compared to ones we currently
have. Those bugs will be addressed by the clang code model anyway.
Relevant commits were collected via:
$ cd ${QTC}/src/libs/cplusplus
$ git log \
--no-merges \
--format=oneline \
v3.4.2..HEAD \
-- LookupContext.* ResolveExpression.* TypeResolver.* TypeOfExpression.* \
../../plugins/cpptools/cppcompletion_test.cpp
From this list the following were skipped due to irrelevance:
88c5b47e53 # CppTools: Minor cleanup in completion tests
e5255a1f5c # CppTools: Add a test for ObjC not replacing dot with arrow
5b12c8d63a # CppTools: Support ObjC in member access operator tests
9fef4fb9ca # CPlusPlus: Fix warnings about overriding visit(...) methods
There were only minor conflicts while reverting those.
This changes touches so many files because there were quite some
cleanups and renames after the 3.4.2 release.
Task-number: QTCREATORBUG-14889
Task-number: QTCREATORBUG-15211
Task-number: QTCREATORBUG-15213
Task-number: QTCREATORBUG-15257
Task-number: QTCREATORBUG-15264
Task-number: QTCREATORBUG-15291
Task-number: QTCREATORBUG-15329
Change-Id: I01f759f8f35ecb4228928a4f22086e279c1a5435
Reviewed-by: Marco Bubke <marco.bubke@theqtcompany.com>
A recursive template generates infinite expansions.
Consider the following example:
template <class R1>
struct Base
{
};
template<typename R>
struct Derived :
Base<
typename Derived<typename Base<R>::type>::type,
typename Derived<typename Base<R>::type>::type
>::type
{};
R is instantiated as Base<R>::type, which causes another
instantiation of R into Base<Base<R>> etc...
This is not a solution, but a workaround.
Task-number: QTCREATORBUG-15141
Change-Id: Ib04f70275e07919e2cb6c7fb61a2045bd52f4a7d
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
This mainly reverts
commit 81721f6781
C++: Fix resolving of recursive typedef
commit 2070431d8c
C++: Fix resolving of partial specialization
and some bits of other changes due to dependencies. It also reverts
commit e0594fc9b9
C++: Fix expensive lookup for boost
which attempted to solve the upcoming problems.
Task-number: QTCREATORBUG-14741
Task-number: QTCREATORBUG-14889
Task-number: QTCREATORBUG-14962
Change-Id: I3f9e1f97199e5199b71da394fc27051c7709bd1f
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
With this patch, CheckSymbols takes about 200ms for processing the boost/proto
hello world example [1]. Before, it needed about 11 seconds (timer in
CheckSymbols::run). Same goes for including <boost/fusion/include/zip.hpp>.
The custom ProcessedSet object was added to support "completion for typedefs
for templates in namespaces", but apparently that's not needed anymore, as the
added test proves.
[1] http://www.boost.org/doc/libs/1_58_0/doc/html/proto/users_guide.html#boost_proto.users_guide.getting_started.hello_world
Task-numer: QTCREATORBUG-14889
Task-numer: QTCREATORBUG-14741
Change-Id: I90454e8970a9d04033d56beeb0c6d7a0d4e6cc62
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
If no template is found, findSpecialization will crash
Task-number: QTCREATORBUG-14748
Change-Id: I94b970e6eb994f0a8d85a4b996e52fcff0affef3
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
Since the cache is now more reliable, some workarounds and optimizations
in the instantiation process are not needed anymore.
Also avoid instantiation of base classes when expandTemplates is
disabled.
As a bonus, we now resolve decltype of template function for a type that is not
referenced anywhere but in the decltype.
Change-Id: Idf42ba7280992db477c9aa62bb1815b27174594d
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
Defined in section 14.7.2 of the standard.
Fixes completion for std::string.
The following explicit instantiation appears in bits/basic_string.tcc:
extern template class basic_string<char>;
This is wrongfully considered a specialization for a forward declaration
(like `template<> class basic_string<char>` is).
Introduce a new Symbol type for explicit instantiations.
Use-case:
template<class T>
struct Foo { T bar; };
template class Foo<int>;
void func()
{
Foo<int> foo;
foo.bar; // bar not highlighted
}
Change-Id: I9e35c8c32f6b78fc87b4f4f1fc903b42cfbd2c2b
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
