So I have prototyped the code here, there are two places where I am confused: GCC [[invariant]] plugin for Design by Contract (WIP) (github.com) 1. Is it proper to cast like this? tree args = NULL_TREE; tree tmp_tree = NULL_TREE; vec** args_ptr = (vec**)&args; tree call = build_new_method_call(class_type, id, args_ptr, fun->decl, LOOKUP_NORMAL, &tmp_tree, tf_warning_or_error); 2. At the bottom, I want to call "invariant()" before "return", but I'm not sure how to phrase this in code. The following doesn't work quite right: because you can't compare "gsi_stmt()" and NULL_TREE // If the last block is a return block, insert the call before the return statement. if (gsi_stmt(gsi) != NULL_TREE && gimple_code(gsi_stmt(gsi)) == GIMPLE_RETURN) gsi_insert_before(&gsi, g, GSI_SAME_STMT); else gsi_insert_after(&gsi, g, GSI_SAME_STMT); On Thu, Dec 29, 2022 at 10:37 AM Gavin Ray wrote: > Hey all, > > The feature I appreciate most about the D programming language is its > "Design by Contract" feature. > Contract programming - Dlang Tour > > > With the recent merge of Contracts to GCC master, C++ comes close to this, > with support for function-based contracts. > The most powerful contract though, is the "invariant" contract: > > *invariant() is a special member function of struct and class types that >> allows sanity checking an object's state during its whole lifetime:* > > >> >> *- invariant() is called after the constructor has run and before the >> destructor is called.* >> *- invariant() is called before entering a member function* >> *- invariant() is called after exiting a member function.**- Class >> invariants are inherited. That means that a derived class invariant will >> implicitly call the base class invariant.* > > > I'm very interested in prototyping a GCC plugin to implement support for > transforming all member function calls in class/struct types > such that a call to the [[invariant]]-annotated function (if any) is > placed at the beginning and end of method bodies. > > Does anyone have any idea whether something like this would be suitable > for a first plugin, > or if there would be roadblocks/technical challenges to implementing such > a thing? > > I'd be grateful for any advice. > > Thank you, > Gavin =) > >