<br><br><div class="gmail_quote">On 23 October 2012 12:22, Lex Trotman <span dir="ltr"><<a href="mailto:elextr@gmail.com" target="_blank">elextr@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Transferred from bug tracker <a href="https://sourceforge.net/tracker/?func=detail&aid=3578557&group_id=153444&atid=787791" target="_blank">https://sourceforge.net/tracker/?func=detail&aid=3578557&group_id=153444&atid=787791</a> to be easier to handle discussion.<div>

<br></div><div>Original bug (list)</div><div><br></div><div><label></label>
            <p>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.<br>
<br>
a. R raw string syntax doesn't highlight<br>
b. raw strings containing a " break symbol parsing<br>
c. user defined "numeric" literals show as numbers, since they may not be numbers should show as some other highlight<br>
d. user defined "string" literals show as strings and the suffix is not highlighted<br>
e. operator delete[] does not highlight the []<br>
f. forward declared classes not always highlighted as types, seems to need the {}<br>
g. declarations class::nested var; insert var into class in symbols<br>
h. scope autocompletion on -> should remain after ->*<br>
i. [[ ]] attribute syntax not parsed, confuses the parser<br>
j. typed enums (eg enum class xxx {};) parsed as classes and erroneously<br>
k. enums with base types fixed don't appear in symbols<br>
l. namespace aliases parsed as "Other" not namespaces<br>
m. declarations namespace::type var; insert var into the namespace on symbols<br>
n. deleted member functions not identified in symbols, show as if declared to exist, not to be removed (picky)<br>
o. direct initialisations do not show as symbols<br>
p. scope autocomplete does not show base class members<br>
q. scope autocomplete does not respect access controls on members<br>
r. friend declarations are treated as member declarations<br>
s. template class parameters not recognised as typenames<br>
t. tooltips don't work for template parameters when < is typed<br>
u. explicit specialisations break autocompletely<br>
v. the documented limitation of not parsing local declarations should be mentioned for completeness<br>
<br>
Linux Geany 1.23 (git >= eeddd6f), en_AU.UTF-8 : GTK 2.24.10, GLib 2.32.3<br>
<br>
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 :)</p><p>Colomban replies:</p><p>a: fixed, it was "just" a missing mapping for SCE_C_STRINGRAW (how this<br>
happened I don't know…)</p><p>c: ok, complete parsing of numbers may help, but it probably would just not<br>
highlight the non-numeric suffix (as the string suffixes, your "d" point).<br>
Though, note that the current highlighting of numeric constant is perfectly<br>
exact from the C preprocessor point of view (last point of<br>
<a href="http://gcc.gnu.org/onlinedocs/gcc/Incompatibilities.html" target="_blank">http://gcc.gnu.org/onlinedocs/gcc/Incompatibilities.html</a>).  BTW, I have a<br>
patch for "proper" number parsing I did for the Vala number methods bug.<br></p></div></blockquote><div><br></div><div> Yes, for C, the definition of "preprocessor token" for C++11 has been extended to include user defined literals.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p>
<br>
d: this is not really fixable, how would you differentiate a<br>
"string"MACRO_OR_DEFINE from those C++11 user literals?<br></p></div></blockquote><div><br></div><div>As I read C++11 thats a user defined literal token, not a string and an identifier.myeh, cod</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p>
<br>
f: ok, quite easy to fix, but having declarations (so without the<br>
definition) in the type list may confuse the scope completion code (since<br>
the declaration is a perfect match, simply with no children).</p><p><br>
j and k: fixed in Git</p><p><br>
n: I don't understand this one.<br>
<br>
v: nor do I get this one.<br></p><p>Cheers</p><span class="HOEnZb"><font color="#888888"><p>Lex</p></font></span></div>
</blockquote></div><br>