On 12/6/19 4:36 PM, Paolo Carlini wrote:
Hi,

On 06/12/19 18:53, Jason Merrill wrote:
On 12/6/19 11:14 AM, Paolo Carlini wrote:
Hi,

as promised, the below takes care of the various remaining casts. It's mostly mechanical, follows the same approach used for build_functional_cast. Tested x86_64-linux.

It occurs to me that once we're passing the location into the build_* functions, we can apply it to the expression there rather than in the parser.

In fact that occurred to me too ;) but at first I didn't like the idea of multiplying the set_location calls... Anyway, in practice for the casts of this last patch the idea works reasonably well, because most of the complexity is encapsulated in the *_1 versions of the functions and the build_* functions proper have only a couple of returns. I wanted to send those changes... But then my build failed in the libcp1plugin.cc bits because the switch also includes c_cast and all the functions must return the same type. And then for consistency we want also to adjust functional_cast (which allows to remove the set_location in the parser which also remained after my previous patch). Those two cast however are more annoying, because there aren't *_1 counterparts and the functions have *lots* of returns, are complicated. Thus for those I'm proposing to create ad hoc *_1 identical to the current functions in order to have single set_location in cp_build_c_cast and build_functional_cast. All in all, I don't have better ideas... I'm finishing testing the below.

Hmm, is the change to cp_expr really necessary vs. using protected_set_expr_location?

Jason

Reply via email to