Hi Jason, > On 21 Aug 2026, at 19:54, Jason Merrill <[email protected]> wrote: > > 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.
I encountered cases where the outcome was dependent on current_function_decl, which is unset (we don’t even have a decl at that point). > 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. OK - this is one extreme of consistency … others might be better. >> 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? In some cases we have to undo the permission given to PARM_DECLs conditionally on contracts parsing (unfortunately, I cannot recall all the details - it’s been several months - but lambda captures was to be one circumstance). >> - 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. OK.. fair enough - this patch was something we (you, me, Nina and Ville) discussed during the work, at the time we all seemed to agree that the intent of the cxx2a code was suspect and this approach was suggested as a way forward. I have no strong attachment to it, thanks Iain > > Jason >
