...since build() is called multiple times for e.g. the global snapshot
(CppModelManager::projectPartFromDependencies,
CppModelManager::replaceDocument).
Change-Id: I03667496a5abc984ba976046dc7b76998a6e3336
Reviewed-by: hjk <hjk121@nokiamail.com>
It logically depends on the Snapshot and has a related lifetime.
Keeping it in the Snapshot avoids some code compelxity.
Change-Id: I24ee4483b44d9b0d7f2e4d494ae7ea624b949f9c
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
Reported as a dead store by the clang static analyzer.
Change-Id: Id5eb72ea4698a17486b8a05d88ee66f3fd89bcfc
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
This reverts commit c228b36ccf.
There are multiple issues with the reverted patch:
* Infinite loop due to indirect recursion e.g. when opening projectmodels.cpp
* Crash when executing CppTools tests on Windows (no infinite loop)
Change-Id: I38f02132ca57d3d32085db6146d0df7d620d7618
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
Qt 5.3 is the minimum requirement these days. Remove all fallback code
from sources and project files.
Change-Id: If6188a471197acadda4d6baee71804ba1a8026c6
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
The CppRefactoringChanges::fileNoEditor takes a Document from the
snapshot it has. Although this snapshot is a safe copy, it might have
been gotten right after it was updated by indexing. Such a document will
still have its AST. If this AST is used by any refactoring action
without retaining it, the pointers will be dangling after a short while
(specifically: after the locator has extracted all the information).
The fileNoEditor method is called by the declDefLinkFinder to search
the target document. The snapshot is obtained before, and contains the
document for the semantic info. However, the target document will not
come from the semantic info, but from the indexer.
Change-Id: I212ff41dde6910e94e80552b2c3e5911fe9496ae
Task-number: QTCREATORBUG-11262
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
See [global.names] (17.6.4.3.2 in the C++11 spec.)
Change-Id: I8434496dbe392b52d339d5f17cfaeee8dbd88995
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
A<int[]> now prefer second specialization for
template<typename T> class A
template<typename T> class A<[]>
Change-Id: I32e874f78b2f5b363d088fbab6a8897e42e44035
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
The parent of instantiation of nested class of template class
should be the instantiation of enclosing template class.
To prevent the infinite loop for case with local typedef of enclosing
template we should not change a parent of typedefed instatiation of
enclosing template. Example:
template <typename T>
struct Enclosing
{
typedef Enclosing<T> EnclosingT;// first case
struct Nested
{
typedef Enclosing<T> EnclosingT;// second case
};
};
Task-number: QTCREATORBUG-11752
Task-number: QTCREATORBUG-11999
Change-Id: Iadd7b5ef73ee0c4881f59c9dabfe03339f55827b
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
So far the pre-compiled headers were processed (thus defines from those
headers were visible), but the actual includes for the documents were
not added, which is necessary for lookup/completion.
Note that this will be only done if pre-compiled headers are not ignored
(Options > C++ > Code Model > [] Ignore pre-compiled headers).
Change-Id: I54a8e6b00597af164d958e3e9f2a1075ea187788
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
Lambdas do not have a name.
Change-Id: Ifda4816c62dcfe19bdbb1649dc1caf408e056b37
Task-number: QTCREATORBUG-12686
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Nesting the namespace "Internal" inside of other namespaces and using
sequential "using namespace" directives *or* relying on a "using
namespace" directive to resolve a method name that contained the
"Internal" namespace for resolution resulted in ambiguous resolution
errors when compiling with the RHEL5.10 stock compiler (GCC 4.1.2). A
sample error is provided below:
Compilation error encountered was:
reference to 'Internal' is ambiguous
/usr/lib/gcc/x86_64-redhat-
candidates are: namespace Internal { }
qt-creator/src/libs/cplusplus/PPToken.h:106: error:
namespace CPlusPlus::Internal { }
Modifying the using namespace directives to reflect the nested nature of
the namespace names resolved the compilation errors. For example:
using namespace CppEditor;
using namespace Internal;
produced errors. However,
using namespace CppEditor;
using namespace CppEditor::Internal;
resolved the compilation errors by removing the ambiguity.
Change-Id: I6d5051e20acb2c147bd7ee1c6c6e1e3b2b4ff0f9
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
This caused displaced highlighting of macro uses after #if constructs.
MacroUse::utf16charBegin() was based on the last "continuation token",
which was wrong.
Change-Id: I89983d82fcf804ba853c04a59a7533c489785d05
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
... by setting the environment variable QTC_LOOKUPCONTEXT_DEBUG
Change-Id: Ia46f55b2989129d5327d894734b6ea9c77c3e0ac
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
When the cdbengine is using the codemodel breakpoint correction.
Change-Id: I70efa3119ca36b4ffd658425132f3fdff3d3eecf
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
...since it's superseded by the class Matcher.
For consistency, rename FullySpecifiedType::isEqualTo() to match().
Change-Id: I07640f9218d814e0350265de45f05929e5d595a9
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
In most cases we need to work with the utf16 indices. Only in
cppfindreferences the byte interface is still needed since there we read
in files and work on a QByteArray to save memory.
Change-Id: I6ef6a93fc1875a8c9a305c075d51a9ca034c41bb
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
...especially in CppTools/CppEditor where the offsets are used with a
QString/QTextDocument.
Change-Id: Ic6d18fbc01fb9cc899a9bd2d7424cd2edae487f1
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
The Lexer can handle it now.
Task-number: QTCREATORBUG-7356
Change-Id: I8c4b03a247656e013d44c3cedca4835e133d4036
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
This will save us toLatin1() conversations in CppTools (which already
holds UTF-8 encoded QByteArrays) and thus loss of information (see
QTCREATORBUG-7356). It also gives us support for non-latin1 identifiers.
API-wise the following functions are added to Token. In follow-up
patches these will become handy in combination with QStrings.
utf16chars() - aequivalent of bytes()
utf16charsBegin() - aequivalent of bytesBegin()
utf16charsEnd() - aequivalent of bytesEnd()
Next steps:
* Adapt functions from TranslationUnit. They should work with utf16
chars in order to calculate lines and columns correctly also for
UTF-8 multi-byte code points.
* Adapt the higher level clients:
* Cpp{Tools,Editor} should expect UTF-8 encoded Literals.
* Cpp{Tools,Editor}: When dealing with identifiers on the
QString/QTextDocument layer, code points
represendet by two QChars need to be respected, too.
* Ensure Macro::offsets() and Document::MacroUse::{begin,end}() report
offsets usable in CppEditor/CppTools.
Addresses QTCREATORBUG-7356.
Change-Id: I0791b5236be8215d24fb8e38a1f7cb0d279454c0
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
This will avoid confusion when later more length and indices methods are
added.
In Token:
length() --> bytes()
begin() --> bytesBegin()
end() --> bytesEnd()
Change-Id: I244c69b022e239ee762b4114559e707f93ff344f
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
They are already inlined. Now it's easier to find read-only accesses.
Change-Id: I9aaeca3bc5860e3a20a536a2484925e4334c005f
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
The necessary data can be retrieved by the resulting Token.
Change-Id: I79afb23183c156240c690beff30bb11dfe943e61
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
This reverts commit 5d76b4339a since it
might lead to an infinite loop.
Task-number: QTCREATORBUG-11999
Change-Id: I12c7f3afc4aa53a83ddc2bf2d33eb76c29b747ee
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
