On 3/19/19 11:45 AM, Marek Polacek wrote:
On Thu, Mar 14, 2019 at 04:22:41PM -0400, Jason Merrill wrote:
On 3/7/19 4:52 PM, Marek Polacek wrote:
This was one of those PRs where the more you poke, the more ICEs turn up.
This patch fixes the ones I could find. The original problem was that
maybe_instantiate_noexcept got a TEMPLATE_DECL created for the member
friend template in do_friend. Its noexcept-specification was deferred,
so we went to the block with push_access_scope, but that crashes on a
TEMPLATE_DECL. One approach could be to somehow not defer noexcept-specs
for friend templates, I guess, but I didn't want to do that.
How does it make sense to instantiate the noexcept-specifier of a template?
We should only get there for fully-instantiated function decls.
Hmm, but duplicate_decls calls check_redeclaration_exception_specification even
for DECL_FUNCTION_TEMPLATE_Ps.
...
Note the crash happens in tsubst_friend_function. I wouldn't know when to
check the noexcept-specifier of such a TEMPLATE_DECL for a template friend
if not there.
Hmm, true, I guess we do need to do a partial instantiation of the
noexcept-specifier in order to compare it.
That broke in register_parameter_specializations but we don't need this
code anyway, so let's do away with it -- the current_class_{ref,ptr}
code is enough to fix the PR that register_parameter_specializations was
introduced for.
What about uses of non-'this' parameters in the noexcept-specification?
template <typename T>
struct C {
template <int N>
friend void foo(T t) noexcept(sizeof(decltype(t)) > 1);
};
template <int N>
void foo(int i) noexcept { }
C<int> c;
Lastly, I found an invalid testcase that was breaking because a template code
leaked to constexpr functions. This I fixed similarly to the recent explicit
PR fix (r269131).
This spot should probably also use build_converted_constant_expr.
Ok, I'll address this.
I'm finding this repeated pattern awkward. Earlier you changed
check_narrowing to use maybe_constant_value instead of
fold_non_dependent_expr, but perhaps whatever that fixed should have
been fixed instead with a processing_template_decl_sentinel in the
enclosing code that already instantiated the expression. That ought to
avoid any need to change this spot or r269131.
Jason
