On 10/31/2011 12:44 PM, 3dw...@verizon.net wrote:
For string and character literals, we can still just build up a call; we
only need to walk the overload list here for numeric literals.
I found that if you don't walk the overload list for chars, a char could be
routed to the operator taking wc
>
> Oct 31, 2011 11:56:59 AM, ja...@redhat.com wrote:
>
> On 10/30/2011 01:13 PM, Ed Smith-Rowland wrote:
> > + /* Look for a literal operator taking the exact type of numeric argument
> > + as the literal value. */
>
> Is this right? Do numeric literals only get here with type unsigned
On 10/30/2011 01:13 PM, Ed Smith-Rowland wrote:
+ /* Look for a literal operator taking the exact type of numeric argument
+ as the literal value. */
Is this right? Do numeric literals only get here with type unsigned
long long or long double?
+ while (fns)
{
tree tmpl_a
On 10/27/2011 03:47 PM, Jason Merrill wrote:
On 10/27/2011 03:32 PM, Ed Smith-Rowland wrote:
+ if (TREE_CODE (TREE_TYPE (decl)) != LANG_TYPE)
+argtypes = TYPE_ARG_TYPES (TREE_TYPE (decl));
If you have multiple overloaded operator"" _foo, you need to iterate
over them looking for the one
On 10/27/2011 03:32 PM, Ed Smith-Rowland wrote:
+ if (TREE_CODE (TREE_TYPE (decl)) != LANG_TYPE)
+argtypes = TYPE_ARG_TYPES (TREE_TYPE (decl));
If you have multiple overloaded operator"" _foo, you need to iterate
over them looking for the one (or ones, in the case of numeric literals)
yo
On 10/26/2011 03:38 PM, Jason Merrill wrote:
On 10/26/2011 02:00 AM, Ed Smith-Rowland wrote:
The patch was bootstrapped and regtested on x86_64-linux-gnu.
Really? I ran into a warning about the unused "suffix" parameter to
interpret_integer. So I've fixed that error. I also added a couple of
On 10/26/2011 03:38 PM, Jason Merrill wrote:
On 10/26/2011 02:00 AM, Ed Smith-Rowland wrote:
The patch was bootstrapped and regtested on x86_64-linux-gnu.
Really? I ran into a warning about the unused "suffix" parameter to
interpret_integer. So I've fixed that error. I also added a couple
On 10/26/2011 04:11 PM, 3dw...@verizon.net wrote:
Thank you Jason and Tom for your help in getting this together an putting up
with my slowness.
Thanks for all your work on this!
Jason
Oct 26, 2011 03:39:09 PM, ja...@redhat.com wrote:
On 10/26/2011 02:00 AM, Ed Smith-Rowland wrote:
> The patch was bootstrapped and regtested on x86_64-linux-gnu.
Really? I ran into a warning about the unused "suffix" parameter to
interpret_integer. So I've fixed that error. I also added a
On 10/26/2011 02:00 AM, Ed Smith-Rowland wrote:
The patch was bootstrapped and regtested on x86_64-linux-gnu.
Really? I ran into a warning about the unused "suffix" parameter to
interpret_integer. So I've fixed that error. I also added a couple of
comments, and implemented the change to ch
On 10/24/2011 10:53 AM, Ed Smith-Rowland wrote:
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.
It seems more likely to me
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_cx
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
> "Ed" == Ed Smith-Rowland <3dw...@verizon.net> writes:
Ed> + /* Nonzero for the 2011 C++ Standard. */
Ed> + unsigned char cxx11;
I think it would be better if the new field name reflected its purpose,
so something like "user_literals".
Ed> + if (ISIDST(*cur))
Ed> + {
Ed> + typ
Jason,
I split the changelog into four parts and tweaked some of the content and
formatting.
Ed
CL_udlit_gcc_c-family
Description: Binary data
CL_udlit_gcc_cp
Description: Binary data
CL_udlit_gcc_testsuite
Description: Binary data
CL_udlit_libcpp
Description: Binary data
On 10/12/2011 04:58 PM, 3dw...@verizon.net wrote:
+ tree const_char_ptr_type_node
+ = build_pointer_type (build_type_variant (char_type_node, 1, 0));
You can just use const_string_type_node here.
Jason
On 10/12/2011 04:58 PM, 3dw...@verizon.net wrote:
+ const char *text = (const char *)tok->val.str.text;
+ char delim;
+ unsigned int i;
+ for (i = 0; i < len; ++i)
+if (text[i] == '\'' || text[i] == '"')
+ break;
This seems like it will get confused by embedded ' or \" in the strin
On 10/12/2011 01:05 AM, Ed Smith-Rowland wrote:
cp_parser_operator(function_id) is simply run twice in
cp_parser_unqualified_id.
Once inside cp_parser_template_id called at parser.c:4515.
Once directly inside cp_parser_unqualified_id at parser.c:4525.
Ah. You could try replacing the operator "
On 10/11/2011 12:57 PM, Jason Merrill wrote:
On 10/11/2011 12:55 PM, Jason Merrill wrote:
On 10/09/2011 07:19 PM, Ed Smith-Rowland wrote:
Does cp_parser_identifier (parser) *not* consume the identifier token?
I'm pretty sure it does.
It does.
Does it work to only complain if !cp_parser_par
On 10/09/2011 07:19 PM, Ed Smith-Rowland wrote:
Does cp_parser_identifier (parser) *not* consume the identifier token?
I'm pretty sure it does.
Does it work to only complain if !cp_parser_parsing_tentatively?
Jason
On 10/11/2011 12:55 PM, Jason Merrill wrote:
On 10/09/2011 07:19 PM, Ed Smith-Rowland wrote:
Does cp_parser_identifier (parser) *not* consume the identifier token?
I'm pretty sure it does.
Does it work to only complain if !cp_parser_parsing_tentatively?
I suppose not, if you got no complain
On 10/08/2011 07:15 PM, Jason Merrill wrote:
On 10/08/2011 07:25 PM, Ed Smith-Rowland wrote:
Also, In spite of the documentation cp_parser_template_parameter_list
returns a TREE_VEC not a TREE_LIST. This happens inside
end_template_parm_list called inside the former. So parameter_list is a
TREE_
On 10/08/2011 07:25 PM, Ed Smith-Rowland wrote:
Also, In spite of the documentation cp_parser_template_parameter_list
returns a TREE_VEC not a TREE_LIST. This happens inside
end_template_parm_list called inside the former. So parameter_list is a
TREE_VEC, parm_list is a TREE_LIST, parm is a PARM_
On 10/05/2011 11:55 AM, Ed Smith-Rowland wrote:
+ int num_parms = TREE_VEC_LENGTH (parameter_list);
+ if (num_parms != 1)
+ ok = false;
+ else
+ {
+ tree parm_list = TREE_VEC_ELT (parameter_list, 0);
+ tree parm = INNERMOST_TEMPL
On 09/19/2011 10:07 PM, Ed Smith-Rowland wrote:
On 09/19/2011 05:11 PM, Jason Merrill wrote:
Can't you store the string and the suffix, and then interpret the
number later if you end up calling an operator that takes the value?
I could and I thought abut it but from the wording (2.14.8 p3 and
On 09/19/2011 04:22 AM, Ed Smith-Rowland wrote:
+check_literal_operator_args( const_tree decl,
Space before the (, not after.
Done. I am now storing the numeric string along with the number and the suffix
ID for numeric operators. I'm keeping the numeric value because we need it too.
Can
Since we're starting to come up on the end of stage 1, I'll go ahead and
review the current patch even though it isn't finished yet. Thanks for
all your work on this, it definitely seems to be coming together.
On 09/13/2011 10:35 AM, Ed Smith-Rowland wrote:
+#define CPP_N_USERDEF 0x100 /
On 09/13/2011 10:35 AM, Ed Smith-Rowland wrote:
I need to build a TEMPLATE_ID_EXPR whenever I encounter 1234_suffix.
I need to construct a call
operator"" _suffix<'1','2','3','4'>();
Is make_char_string_pack (const char* str) in cp/parser.c right?
The TREE_TYPE of a NONTYPE_ARGUMENT_PACK is no
28 matches
Mail list logo
