[C++ Patch/RFC] PR 53025

[Jason Merrill]

On 10/01/2014 12:31 PM, Paolo Carlini wrote:
> in this issue Daniel argued that the value of a noexcept expression
> should not depend on constructor elision.

I'm open to that, but I don't think it's at all clear in the standard.

> Then, in the audit trail Marc
> tentatively suggested something like the parser.c hunk below, which just
> disables our -felide-constructors optimization when parsing the noexcept
> expression. Over the last couple of days, I had a look, noticed that in
> any case we still have to handle templates, thus the pt.c hunk, and also
> that maybe we can avoid completely disabling -felide-constructors in
> noexcept expressions when we know for sure that the constructor at issue
> doen't throw: for that in call.s I'm further abusing the
> flag_elide_constructors global, in terms of using a special value of 2
> when flag_elide_constructor is found == 1 when handling the expression.
> The below passes testing, anyway.

Why do we want to avoid completely disabling -felide-constructors, since 
it's an unevaluated context anyway?

If you're going to mess with this flag you need to save/restore it in 
push/pop_to_top_level as well.

Jason