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
