This report is a grab bag of some C++11 things that need fixing so they don't get lost, alpha numbered to refer to as they are fixed. The list is not intended to be exhaustive as I don't use C++11 in anger yet. There are some non-C++11 specific ones I identified as well, some of these are already known but not well bug reported.
"
break symbol parsing, eg char b[]=u8R"b(abc")b";
adding and removing the "
after c
starts and stops parsing of symbols past this point. R"up to 16 characters(your raw string which can include anything except the 16 chars)the same 16 chars" is a new raw string format std 2.14.51.2ULL
std 2.14.8 (not a Scintilla problem since Scintilla doesn't know about the declaration of an operator "") std 2.14.8"abcdef"_is_a_user_literal
is a user literal not a string followed by an identifier (same as item c.)delete[]
does not highlight the []
(Scintilla problem?){}
to recognise a declaration. eg struct s;
s
is not recognised as a struct symbol. PS applies to C as well.my_class::nested var;
insert var
into my_class
in symbols eg struct G{ struct G1{}; }; G::G1 g;
shows g
as a member of struct G
(Note: not consistent, sometimes g
is shown in a section called Members, can't find determining factor) [[ ]]
attribute syntax not parsed, confuses the parserenum class xxx {};
) parsed as classes and erroneouslynamespace::type var;
insert var
into the namespace
on symbols[b39f90] w. typed enum class names aren't recognized when the enum class is nested inside another class. For example, B
in the following snippet is not recognized:
class A {
enum class B : int {
X, Y, Z
};
};
x. alias templates not highlighted, see http://en.wikipedia.org/wiki/C%2B%2B11#Alias_templates See [#912].
y. Using uniform initializers with C++11 class and object declarations mistakenly treats the object as a typename, eg in
class a { int b; } *c {nullptr};
a and c become classnames, classes in the symbol pane and coloured as a class name.
class a { int b; }; a *c {nullptr};
a remains a class name but now c is an object again, not a class. (was [#964])
static_assert contents not ignored
Linux Geany 1.23 (git >= eeddd6f), en_AU.UTF-8 : GTK 2.24.10, GLib 2.32.3
Most of the items in the attachment were tested to compile (possibly with extra surrounding code) on GCC 3.7.1 (errors in transcription excepted :)
Bugs: #912
Bugs: #964
Commit: [0b4ec5]
Commit: [6c7f69]
Commit: [8d3085]
Commit: [a77785]
Commit: [b39f90]
Commit: [f2f22d]
examples of most of the items listed
GCC 4.7.1 I meant of course
a: fixed, it was "just" a missing mapping for SCE_C_STRINGRAW (how this happened I don't know…)
c: ok, complete parsing of numbers may help, but it probably would just not highlight the non-numeric suffix (as the string suffixes, your "d" point). Though, note that the current highlighting of numeric constant is perfectly exact from the C preprocessor point of view (last point of http://gcc.gnu.org/onlinedocs/gcc/Incompatibilities.html\). BTW, I have a patch for "proper" number parsing I did for the Vala number methods bug.
d: this is not really fixable, how would you differentiate a "string"MACRO_OR_DEFINE from those C++11 user literals?
f: ok, quite easy to fix, but having declarations (so without the definition) in the type list may confuse the scope completion code (since the declaration is a perfect match, simply with no children).
n: I don't understand this one.
v: nor do I get this one.
j and k: fixed in Git
For easier use discussion transferred to thread http://lists.geany.org/pipermail/devel/2012-October/007147.html
Diff:
Diff:
Diff:
Diff:
Item
w
fixed by [b39f90c94d54dd80e1f025e90c03fbf6455fadb9]Related
Commit: [b39f90]
Last edit: Colomban Wendling 2013-07-15
Diff:
Diff:
Diff:
Diff:
I hate to take you past the end of the alphabet, but I have two more things to add to this list.
z. trailing return prevents functions from being recognized.
C++11 added a new way to write function signatures called the trailing return style, where:
is roughly the same as:
The only real difference between the two (other than appearance) is the scope that you are in. In the old-style prefix return, you are in the surrounding scope. In the new trailing return, you are in the function's scope.
?. static_assert is being misinterpreted as a function when using templates.
static_assert is handled correctly when using < and > as inequalities, but not when using them as template brackets.
Add another one, parsing of function args gets confused by string initialisers containing parens.
Diff:
Added static_assert to the list, which now works.
Diff: