[Geany-Devel] C++11 Bug discussion (transferred from bug tracker)
Colomban Wendling
lists.ban at herbesfolles.org
Wed Oct 24 09:56:49 UTC 2012
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 at gmail.com
> <mailto:elextr at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-LexCPP-really-parse-numeric-constants.patch
Type: text/x-patch
Size: 3994 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20121024/e5f5098f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Create-tags-of-the-appropriate-type-for-forward-type.patch
Type: text/x-patch
Size: 1799 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20121024/e5f5098f/attachment-0001.bin>
More information about the Devel
mailing list