On 1/18/21, Jason Merrill <ja...@redhat.com> wrote: > On 1/4/21 9:58 AM, Jeff Chapman wrote: >> Ping. re: >> https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561135.html >> <https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561135.html> >> >> https://github.com/lock3/gcc/tree/contracts-jac-alt >> <https://github.com/lock3/gcc/tree/contracts-jac-alt> >> > Why is some of the code in c-family? From the modules merge there is > now a cp_handle_option function that you could add the option handling > to, and I don't see a reason for cxx-contracts.c to be in c-family/ > rather than cp/.
I've been pushing changes that address the points raised and wanted to ping to see if there's more feedback and give a status summary. The notable change is making sure the implementation plays nicely with modules and a mangling change that did away with a good chunk of code. The contracts code outside of cp/ has been moved into it, and the contract attributes have been altered to work with language independent handling code. More of the contracts code can probably still be moved to cxx-contracts which I'll loop back to after other refactoring. The naming, spelling, and comments (or lack thereof) have been addressed. >> +set_decl_contracts (tree decl, tree contract_attrs) > I think you want to use 'chainon' here. >> +build_arg_list (tree fn) > You can use is_this_parameter here. Thanks; I knew of chainon but didn't think of it and is_this_parameter is new to me. Always fun to delete code :) >> + /* If we have contracts, check that they're valid in this context. */ >> + // FIXME: These aren't entirely correct. > > How not? Can local extern function decls have contract attributes? > >> + /* FIXME when we instatiate a template class with guarded >> + * members, particularly guarded template members, the >> resulting >> + * pre/post functions end up being inaccessible because their >> + * template info's context is the original uninstantiated >> class. > > This sounds like a significant functionality gap. I'm guessing you want > to reconsider the unshare_template approach. > >> + /* FIXME do we need magic to perfectly forward this so we don't >> clobber >> + RVO/NRVO etc? */ > > Yes. CALL_FROM_THUNK_P will probably get you some of the magic you want. These points are still being investigated and addressed; including them for reference. > More soon. Please let me know what other issues need work. Thank you! Jeff Chapman
