| Re: [cdt-dev] Need help scratching an itch (Bug #379684) |
|
Hi Richard Sorry for the late response (I have been fighting with a flu and couldn't check my mails). Actually, I'm still looking for guidance myself regarding my patches. But I'm sure everyone would be glad if you started working on the semantics. I'm not sure where to start that either. There needs to be some connection of the user defined literal and the corresponding literal operators.
Here I guess a new type of AST node would make sense, to provide this additional information. I expect the resolution to require identifying the literal operators themselves and also resolving the correct overload of that operator. Which parameter list the
literal requires should be determinable by the literal itself. I reflected by underscore-requiring syntactic implementation and came to the same conclusion as you - it is insufficient. We'll have to figure
out a better approach. The main question remains: How to deal with clashes of the current implementation (of intended features) and the C++11 standard. Regards Thomas From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Richard In that case, with your guidance and permission, I'd like to help implement the semantics. I'll just need to know which files to start looking in. Thanks, Richard. On 4 June 2012 09:54, Corbat Thomas (tcorbat@xxxxxx) <tcorbat@xxxxxx> wrote: 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.
|