Hello! Looping back around to this. re: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567334.html
On 3/25/21, Jason Merrill <ja...@redhat.com> wrote: > On 3/1/21 8:12 AM, Jeff Chapman wrote: >> 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. > > Sounds good. I plan to get back to this when GCC 11 branches, which > should be mid-April. Please let me know if you see any more issues when you pick it back up. Particularly in modules interop, since I don't think you've had a chance to look at that yet. Completed another merge with master earlier this week which didn't bring to light any new issues or regressions, but I'll keep on that :) >>>> + /* 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. If there's anything I can do to make the process smoother please don't hesitate to ask. Thank you, Jeff Chapman
