On 8/19/26 2:46 AM, Iain Sandoe wrote:
Hi Folks,
On 19 Aug 2026, at 00:33, Wang Jinghao <[email protected]> wrote:
Hi Jason,
Thanks for the review.
On Tue, Aug 18, 2026 at 3:39 AM Jason Merrill <[email protected]> wrote:
On 8/14/26 4:33 PM, Wang Jinghao wrote:
For precondition and postcondition without a result binding, whether
the return type is auto is irrelevant to the condition expression, so
type conversions should be completed immediately.
PR c++/125537
gcc/cp/ChangeLog:
* pt.cc (tsubst_contract): Keep template processing enabled
only for postconditions with an undeduced result binding.
Hmm, I notice this is still a different condition from
cp_parser_late_contract_condition and rebuild_postconditions, which only
check whether there's a result binding, not whether it's auto. They
ought to agree on the condition for treating the postcondition as a
pseudo-template.
If we also make the condition in cp_parser_late_contract_condition
consistent, we could even remove its call to rebuild_postconditions, since
the known-type path would no longer create pseudo-templates that require
this compensating step.
During the implementation, we discussed uniformly deferring contract parsing
(but did not manage to implement it during that phase of the work),
I think that there are two places that cannot avoid it (lambdas and contracts on
functions with auto return).
We also took on the (ab)use of the substitution code to deal with postcondition
placeholders (from the cxxa2 implementation) without fully appreciating the
consequences: The tsubst code is not really designed to operate without a
current function decl
How do you mean? We handle lots of substitution outside of functions.
This isn't the first area to want to do this sort of pseudo-template
substitution; notably requires-expressions necessarily do as well. I
think we need to make it work consistently.
and there is some sleight-of-hand done to make the
postcondition placeholder a PARM_DECL instead of a VAR_DECL to make use
of some special rules that apply to PARM_DECLs; unfortunately those special
rules also contradict some cases that entities are allowed to be visible to the
contract
How so?
- and I was getting concerned that we were growing more and more
special cases gated on “processing contract condition" We already have
a deferred parse in the class processing (which itself also produces some
issues when we have in-class redeclared friends).
Hmm, I've actually been considering moving many of those deferred parses
in the other direction to address ordering problems without actually
trying to do parsing on demand.
Jason
