Re: [PATCH] c++, contracts: Only defer contracts that use an undeduced result binding [PR125537]

Hi Folks,

> On 20 Aug 2026, at 03:07, Wang Jinghao <[email protected]> wrote:
> 
> 
> 
> On 2026/8/19 14:46, 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 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_DELCs; unfortunately those special
>> rules also contradict some cases that entities are allowed to be visible to the
>> contract - 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).
>> 
>> So, I drafted a patch that defers parsing of contract conditions uniformly but
>> unfortunately, I don’t have cycles to do much re-work at present … I do keep
>> it rebased onto trunk - and it is here (in case either of you wants to look at
>> the tradeoff between approaches).  I think that, although its an initial step
>> it would simplify things going forward.
>> 
>> https://github.com/iains/gcc-git/tree/master-wip-contracts-deferred-parses
>> 
>> or
>> 
>> https://forge.sourceware.org/iains/gcc-TEST/src/branch/master-wip-contracts-deferred-parses
>> 
>> thanks
>> Iain
>> 
>> P.S. Here is a branch that re-works the postcondition placeholder to be a VAR_DECL
>> which helps with fixing some of the visibility constraints
>> 
>> https://github.com/iains/gcc-git/tree/master-wip-contracts-postcond-rework
>> 
>> https://forge.sourceware.org/iains/gcc-TEST/src/branch/master-wip-contracts-postcond-rework
>> 
> 
> Hi Iain,
> 
> I’d be happy to help.  I implemented a few patches, but reworking this
> to use deferred parsing uniformly is clearly the better approach.  Maybe
> some of my patches can still be useful :D

If Jason agrees that this is a useful direction - then please feel free to take
on the draft patch and modify it as needed.

I was certainly not suggesting that it replaced your patches ;)

cheers
Iain

> 
> Regards
> Jinghao