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
