>>> +// Bring the parameters of a function declaration back into >>> +// scope without entering the function body. The declarator >>> +// must be a function declarator. The caller is responsible >>> +// for calling finish_scope. >>> +void >>> +push_function_parms (cp_declarator *declarator) >> >> I think if the caller is calling finish_scope, I'd prefer for the >> begin_scope call to be there as well. >> > Even though Andrew said that this will change later for other reasons, it's > a function I wrote so: I actually debated this with Andrew before. My > rationale for calling begin_scope in the function was that it feels > consistent with the semantics of the call. Specifically it can be seen as > reopening the function parameter scope. Thus the call is balanced by > calling finish_scope. Either way would work of course, but perhaps it just > needed a better name and/or comment?
In the process of removing constraints from lang_decl nodes, I also ended up addressing a lot of the other constraint processing comments -- it made sense to do it at the same time. One of those was moving a requires-clause into a function declarator. I had thought that this would prevent me from having to re-open that scope, but it doesn't. The parameter scope is closed at a lower level in the parse :/ So this issue is still around. >>> + // Save the current template requirements. >>> + saved_template_reqs = release (current_template_reqs); >> >> >> It seems like a lot of places with saved_template_reqs variables could be >> converted to use cp_manage_requirements. >> > Probably. The instance you quoted isn't very trivial though. The > requirements are saved in two different branches and need to be restored > before a certain point in the function. Might just need to spend more time > looking over the code. I got rid of current_template_reqs in my current work. Constraints are associated directly with a template parameter list or a declarator. >>> + // FIXME: This could be improved. Perhaps the type of the requires >>> + // expression depends on the satisfaction of its constraints. That >>> + // is, its type is bool only if its substitution into its normalized >>> + // constraints succeeds. >> >> >> The requires-expression is not type-dependent, but it can be >> instantiation-dependent and value-dependent. >> > This is an interesting change. The REQUIRES_EXPR is currently marked as > value dependent. The ChangeLog indicates that Andrew loosened the > conditions for being value dependent for some cases, but then added it as > type dependent when something else failed. May require some time to pin > down exactly what needs to be done here. I think something may have changed since I made that change... If I'm remembering correctly, it used to be the case that build_x_binary_op would try to fold the resulting expression when the operands weren't type dependent. That happens in conjoin_constraints. Now it looks like it's calling build_non_dependent_expr, which does something a little different. I agree that requires-expressions are not type-dependent (they have type bool). Andrew
