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
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/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 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/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)
you
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
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 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
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
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
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 + type =
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
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 string
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 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: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
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: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
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
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
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
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.
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 not a
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
24 matches
Mail list logo
