On 10/21/2011 05:20 PM, Jason Merrill wrote:
I think we're down to minor cosmetic issues:
On 10/21/2011 03:55 PM, Tom Tromey wrote:
There are a few spots like this that are missing a space before an open
paren.
+ if (DECL_LANGUAGE(decl) == lang_c)
Another one.
- if (warn_cxx0x_compat
- && C_RID_CODE (token->u.value) >= RID_FIRST_CXX0X
- && C_RID_CODE (token->u.value) <= RID_LAST_CXX0X)
....
This code doesn't seem to have actually changed, so let's not adjust
its whitespace.
+ /* Fill in PARMVEC with all of the parameters. */
+ parmvec = make_tree_vec (len);
Let's call it 'charvec'; the characters are template arguments, not
parameters.
+/* Parse a user-defined numeric constant. returns a call to a
user-defined
+ literal operator. */
+static tree
+cp_parser_userdef_numeric_literal (cp_parser *parser)
Add a blank line between comment and function.
While looking at the embedded string issue I found that if you apply
the suffix of a raw literal to a string it errors as it should but
the error complained that there were too many arguments for the
function. This was not helpful so I made a nicer error message.
+ if (result == error_mark_node)
+ error ("invalid string literal prefix %<\"%s\"%> for user-defined"
+ " raw literal operator %qD", TREE_STRING_POINTER (value),
name);
I think that we want a combination of the two errors; the new error
doesn't help the user to fix their code as much. It should remind
them that for a string literal the function is called with a length
argument as well.
Concerning this error, the only way to get here is to mis-use a raw
literal operator by giving it a quoted string. The prefix must be
interpretable as a number of some kind. I think I'll tell the user to
drop the quotes.
The length of a string literal is supplied implicitly by the compiler to
a string literal operator when a string user defined literal is
encountered. The user doesn't explicitly call the operator (not here
anyway).
+ error ("literal operator template %qD has invalid parameter
list",
+ decl);
Similarly, this message should say that the parameter list needs to be
<char...>
+
+/* Return true if a user-defined literal operator is a raw
operator. */
+
We don't need the extra newline before the comment.
Should be ready to go with these tweaks.
Jason
I've made these corrections. They'll be in the next patch.
Unfortunately, as I was testing raw operators on very long strings I
observed two things:
1. A bad error - the argument to a raw literal operator must be a
null-terminated string.
2. If a very long number is given as the prefix to a numeric literal, a
warning is issued ("integer constant is too large for its type")
If the receiving operator is either the raw operator or the operator
template then this should not be given. I anticipate people might like
to have multi-precision numbers someday, for example.
Before I release another patch I have to fix 1. The warning might be
fixed in-tree if that's OK.
Ed