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>
... and adjust INCLUDEPATH accordingly.
while i'm at messing with include statements, also re-order the include
blocks according to policy and sort them within bigger blocks.
Change-Id: I7762abfd7c4ecf59432b99db2f424e4fa25733a5
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Because apparently, while designing the Objective-C language, somebody
thought it was a world-class idea to allow any white-space between the
'@' character and the subsequent keyword. With this fix, we now
correctly parse:
@ dynamic
and:
@
selector
and:
@"foo"
"bar"
@"mooze"
(This last one is 1 single string split over multiple lines.)
Wonderful, isn't it?
What we (and Clang) do not support, but what GCC supports is something
like:
@"foo"@@ "bar" @"mooze" @@
which is equivalent to @"foobarmooze".
Things you mustn't do:
1) end an enum with a comma
2) #include <cxxxx> and not use std::
3) use anonymous structures
All three things are invalid C++. Anonymous structures inside
anonymous unions are allowed by GCC, but that doesn't mean it's valid.
