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

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

Regards
Jinghao