Transferred from bug tracker https://sourceforge.net/tracker/?func=detail&aid=3578557&group_id=15... be easier to handle discussion.
Original bug (list)
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.
a. R raw string syntax doesn't highlight b. raw strings containing a " break symbol parsing c. user defined "numeric" literals show as numbers, since they may not be numbers should show as some other highlight d. user defined "string" literals show as strings and the suffix is not highlighted e. operator delete[] does not highlight the [] f. forward declared classes not always highlighted as types, seems to need the {} g. declarations class::nested var; insert var into class in symbols h. scope autocompletion on -> should remain after ->* i. [[ ]] attribute syntax not parsed, confuses the parser j. typed enums (eg enum class xxx {};) parsed as classes and erroneously k. enums with base types fixed don't appear in symbols l. namespace aliases parsed as "Other" not namespaces m. declarations namespace::type var; insert var into the namespace on symbols n. deleted member functions not identified in symbols, show as if declared to exist, not to be removed (picky) o. direct initialisations do not show as symbols p. scope autocomplete does not show base class members q. scope autocomplete does not respect access controls on members r. friend declarations are treated as member declarations s. template class parameters not recognised as typenames t. tooltips don't work for template parameters when < is typed u. explicit specialisations break autocompletely v. the documented limitation of not parsing local declarations should be mentioned for completeness
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 4.7.1 (errors in transcription excepted :)
Colomban replies:
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).
j and k: fixed in Git
n: I don't understand this one.
v: nor do I get this one.
Cheers
Lex
On 23 October 2012 12:22, Lex Trotman elextr@gmail.com wrote:
Transferred from bug tracker https://sourceforge.net/tracker/?func=detail&aid=3578557&group_id=15... be easier to handle discussion.
Original bug (list)
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.
a. R raw string syntax doesn't highlight b. raw strings containing a " break symbol parsing c. user defined "numeric" literals show as numbers, since they may not be numbers should show as some other highlight d. user defined "string" literals show as strings and the suffix is not highlighted e. operator delete[] does not highlight the [] f. forward declared classes not always highlighted as types, seems to need the {} g. declarations class::nested var; insert var into class in symbols h. scope autocompletion on -> should remain after ->* i. [[ ]] attribute syntax not parsed, confuses the parser j. typed enums (eg enum class xxx {};) parsed as classes and erroneously k. enums with base types fixed don't appear in symbols l. namespace aliases parsed as "Other" not namespaces m. declarations namespace::type var; insert var into the namespace on symbols n. deleted member functions not identified in symbols, show as if declared to exist, not to be removed (picky) o. direct initialisations do not show as symbols p. scope autocomplete does not show base class members q. scope autocomplete does not respect access controls on members r. friend declarations are treated as member declarations s. template class parameters not recognised as typenames t. tooltips don't work for template parameters when < is typed u. explicit specialisations break autocompletely v. the documented limitation of not parsing local declarations should be mentioned for completeness
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 4.7.1 (errors in transcription excepted :)
Colomban replies:
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.
Yes, for C, the definition of "preprocessor token" for C++11 has been extended to include user defined literals.
d: this is not really fixable, how would you differentiate a "string"MACRO_OR_DEFINE from those C++11 user literals?
As I read C++11 thats a user defined literal token, not a string and an identifier.myeh, cod
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).
j and k: fixed in Git
n: I don't understand this one.
v: nor do I get this one.
Cheers
Lex
OOps previous post sent before completion.
On 23 October 2012 12:42, Lex Trotman elextr@gmail.com wrote:
On 23 October 2012 12:22, Lex Trotman elextr@gmail.com wrote:
Transferred from bug tracker https://sourceforge.net/tracker/?func=detail&aid=3578557&group_id=15... be easier to handle discussion.
Original bug (list)
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.
a. R raw string syntax doesn't highlight b. raw strings containing a " break symbol parsing c. user defined "numeric" literals show as numbers, since they may not be numbers should show as some other highlight d. user defined "string" literals show as strings and the suffix is not highlighted e. operator delete[] does not highlight the [] f. forward declared classes not always highlighted as types, seems to need the {} g. declarations class::nested var; insert var into class in symbols h. scope autocompletion on -> should remain after ->* i. [[ ]] attribute syntax not parsed, confuses the parser j. typed enums (eg enum class xxx {};) parsed as classes and erroneously k. enums with base types fixed don't appear in symbols l. namespace aliases parsed as "Other" not namespaces m. declarations namespace::type var; insert var into the namespace on symbols n. deleted member functions not identified in symbols, show as if declared to exist, not to be removed (picky) o. direct initialisations do not show as symbols p. scope autocomplete does not show base class members q. scope autocomplete does not respect access controls on members r. friend declarations are treated as member declarations s. template class parameters not recognised as typenames t. tooltips don't work for template parameters when < is typed u. explicit specialisations break autocompletely v. the documented limitation of not parsing local declarations should be mentioned for completeness
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 4.7.1 (errors in transcription excepted :)
Colomban replies:
a: fixed, it was "just" a missing mapping for SCE_C_STRINGRAW (how this happened I don't know…)
Tests ok for me, thanks.
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.
Yes, for C, the definition of "preprocessor token" for C++11 has been extended to include user defined literals. Scintilla may need to be fixed to distinguish standard numbers from user numbers so we can highlight them differently, same for string user literals below.
d: this is not really fixable, how would you differentiate a "string"MACRO_OR_DEFINE from those C++11 user literals?
As I read C++11 standard thats a user defined literal token, not a string token and an identifier token, rather like the number-number example (in the gcc doc you referenced above) isn't two numbers subtracted. Its something that may be different between C and C++ and c.c and Lexcpp.cxx may need changing to reflect that.
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).
Yeah, I guess completion has to be taught to ignore tags with no content in favour of ones with content.
j and k: fixed in Git
Tests ok for me, thanks.
n: I don't understand this one.
Ok, I did say being picky, but it affects autocomplete. In C++11 you can delete inherited functions (at least the special member functions, and I think any one) using a function declaration = delete; syntax. These functions are unavailable and shouldn't be in autocomplete, but because they look like declarations, at the moment, they are in the symbols looking like normal functions and they are in autocomplete.
v: nor do I get this one.
I was just saying "I know its documented as a limitation, but the fact that local declarations are not parsed is still a deficiency". As mentioned on IRC I have been trying various fixes for this but have gotten nowhere.
Cheers Lex
Cheers
Lex
For those of use who are pointer to member syntax challenged (including me), example G of the attachment to the bug:
class G{ public: class G1{ int a; int b; }c; int d; G(int dd):d(dd){}; };
const G g; G::G1 G::* gg = &G::c;
(nobody least of all me spotted the mistake that the last character should be c :)
The last line is read as, gg is a pointer to a member of class G and the type of that member is class G1 which is a member of class G and gg is initialised to a pointer to member c of an object of class G.
Cheers Lex
Le 23/10/2012 04:58, Lex Trotman a écrit :
OOps previous post sent before completion.
On 23 October 2012 12:42, Lex Trotman <elextr@gmail.com mailto:elextr@gmail.com> wrote:
[...]
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. Yes, for C, the definition of "preprocessor token" for C++11 has been extended to include user defined literals. Scintilla may need to be fixed to distinguish standard numbers from user numbers so we can highlight them differently, same for string user literals below.
I attached the patch I was talking about, 0001-LexCPP-really-parse-numeric-constants.patch
I'll discuss it on the Scintilla ML or BT soon too.
d: this is not really fixable, how would you differentiate a "string"MACRO_OR_DEFINE from those C++11 user literals? As I read C++11 standard thats a user defined literal token, not a string token and an identifier token, rather like the number-number example (in the gcc doc you referenced above) isn't two numbers subtracted. Its something that may be different between C and C++ and c.c and Lexcpp.cxx may need changing to reflect that.
OK, GCC agrees with you. So C++11 is incompatible with earlier versions of C++, wow. Wonderful. This probably means we'll need a new filetype, lexer and parser for this new C++11 language :)
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).Yeah, I guess completion has to be taught to ignore tags with no content in favour of ones with content.
Well, for C it'd be OK since empty structures (and probably others) are invalid, but that's probably not the case for other languages, so simply skipping empty containers would only give *more* suggestions, not *better* ones.
Anyway, patch 0001-Create-tags-of-the-appropriate-type-for-forward-type.patch attached -- though again I'm not sure it's good.
[...] n: I don't understand this one.Ok, I did say being picky, but it affects autocomplete. In C++11 you can delete inherited functions (at least the special member functions, and I think any one) using a function declaration = delete; syntax. These functions are unavailable and shouldn't be in autocomplete, but because they look like declarations, at the moment, they are in the symbols looking like normal functions and they are in autocomplete.
OK, so any "= delete" declaration should simply be ignored?
v: nor do I get this one.I was just saying "I know its documented as a limitation, but the fact that local declarations are not parsed is still a deficiency". As mentioned on IRC I have been trying various fixes for this but have gotten nowhere.
OK, so that's more a feature request than a bug ;)
Cheers, Colomban
On Wed, 24 Oct 2012 11:56:49 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 23/10/2012 04:58, Lex Trotman a écrit :
OOps previous post sent before completion.
Ok, I did say being picky, but it affects autocomplete. In C++11 you can delete inherited functions (at least the special member functions, and I think any one) using a function declaration = delete; syntax. These functions are unavailable and shouldn't be in autocomplete, but because they look like declarations, at the moment, they are in the symbols looking like normal functions and they are in autocomplete.
OK, so any "= delete" declaration should simply be ignored?
class A { foo(); }; class B : public A { foo() = delete; }; class C : public B { foo(); };
"foo()" should be suggested if you complete "fo" in objects of class A or C, but not B. In other words, "= delete" should remove the [derived] suggestion for foo(), if any.