| Re: [cdt-dev] Need help scratching an itch (Bug #379684) |
|
Hi Richard Sorry, I did not want to take away anyones work. ;) But there will be plenty to do on this features regarding the semantics anyway. Regarding the check whether the string literal is empty, I did not add it there (though left a comment), as I'm not quite sure about CDTs policy
considering how strict the parser shall be. It will be easy to verify the token content if desired. So the answer to your question is: No, it is not checked. I have introduced the underscore limitation in my implementation for not breaking existing CDT functionality. For example GCCCompleteParseExtensionsTest.testBug39686(),
which has a case for imaginary float literals. But I agree that my suggestion is not optimal. Perhaps we need further LexerOption to configure UDL. Thanks for the link to your code. At a glance, regarding the CPPASTLiteralExpression, we could also think of deriving that class (CPPASTUserDefinedLiteralExpression),
which would allow a little more distinction from the existing literals. I'll have a closer look at your implementation as soon as I have time. Regards Thomas From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Richard Hi Thomas, Although I'm a little disappointed that wont be able to see this through myself, I'm glad it's actively being worked on. Thanks. The solution I managed to come up with looked at the column offsets between the quotes and the identifier, making sure there is at least 1 space. Looking at N2765 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2765.pdf)
right at the end there is an example of operator definitions which states that there must be a space, otherwise an error because, as you said, it would be seed as one token instead of two. Looking through you patch at where the operator is defined (GNUCPPSourceParser.java line 717), correct me if I'm wrong, but does consume check the length of tString, or is that done elsewhere? One other thing, I believe UDLs that do not start with an underscore should be allowed, but issue a warning. My understanding of the CDT lexer makes this difficult to find the suffix for integers and floats, my approach was to parse these
two in CPPASTLiteralExpression.java, then knowing where the valid int/float were, anything remaining would be a suffix. In case you're interested, my partial solution is https://github.com/Naddiseo/cdt/compare/2c63700887ee5...9e6ed0c22a Thanks again, Richard. On 4 June 2012 01:59, Corbat Thomas (tcorbat@xxxxxx) <tcorbat@xxxxxx> wrote: Hi Richard I've already started implementing user defined literals syntactically. Code is in gerrit
(https://git.eclipse.org/r/6000). Regarding your question. As far as I know the standard does not explicitly require a
space between "" and the following identifier. But it is not possible according to the lexical conventions to have a matching token sequence for a literal operator. If we consider an example: float operator ""E(const char*); This is invalid as ""E would yield only one token, a user defined string literal, instead
of "" and E as separate tokens. As you run into this problem, you might not yet have the corresponding adaption in the lexer. Regards Thomas From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Richard Hello CDT mailing list, I'm taking a stab at fixing bug #379684 User-defined literals, mostly just for the fun of it, but I'm probably going to need a lot of help as this is my first time in the eclipse/cdt
internals. Anyway, I have managed to get the parser to recognise the T operator "" L() syntax, with one caveat: I can't figure out how to require the whitespace between the "" and the literal
name. Thanks, Richard.
|