Hi,
On 05/16/2012 12:11 AM, Jason Merrill wrote:
On 05/15/2012 04:56 PM, Paolo Carlini wrote:
@@ -2753,7 +2754,8 @@ build_x_indirect_ref (location_t loc, tree expr, r
rval = cp_build_indirect_ref (expr, errorstring, complain);
if (processing_template_decl&& rval != error_mark_node)
- return build_min_non_dep (INDIRECT_REF, rval, orig_expr);
+ return build_min_non_dep_loc (EXPR_LOCATION (rval), INDIRECT_REF,
Shouldn't this use loc? If rval comes from cp_build_indirect_ref, it
might not have the right location.
@@ -3621,15 +3623,16 @@ build_x_binary_op (location_t loc, enum
tree_code
warn_about_parentheses (code, arg1_code, orig_arg1, arg2_code,
orig_arg2);
if (processing_template_decl && expr != error_mark_node)
- return build_min_non_dep (code, expr, orig_arg1, orig_arg2);
-
+ return build_min_non_dep_loc (EXPR_LOCATION (expr), code, expr,
Likewise. Similarly in build_x_array_ref, build_x_unary_op,
build_x_conditional_expr, build_x_compound_expr.
I can't change the build_min_non_dep_loc call in build_x_binary_op to
simply use loc, that causes the diagnostic regression I mentioned
before. Sorry, I wasn't clear in my previous message, it happens when
one "naturally" just passes loc, not the EXPR_LOCATION from the
intermediate expr. Indeed, in all the calls you mentioned I naturally
passed a couple of days ago loc in my local tree, then when I saw that
library testcase with the wrong location in some error messages I
stopped. Today, I fooled myself into believing that I should have passes
the location via EXPR_LOCATION from the intermediate expr and tried
quickly to prepare something.
This requires more analysis.
Is it Ok with you if we return to a patch only touching the
build_min_nt_locs?
I still see a lot of EXPR_LOC_OR_HERE in the patch, is that deliberate?
Now that you are asking, I can re-analyze those which I added a couple
of days ago.
Paolo.
