GabrielDosReis / ipr

Compiler-neutral Internal Program Representation for C++
BSD 3-Clause "New" or "Revised" License
222 stars 23 forks source link

membership() field of the decls. Missing in Alias and Var #170

Closed GorNishanov closed 3 years ago

GorNishanov commented 3 years ago

Most of the declaration has a membership() accessor returning the UDT they are member of. I noticed a comment in impl/ udt::declare_alias

         impl::Alias*
         declare_alias(const ipr::Name& n, const ipr::Type& t)
         {
            impl::Alias* alias = body.declare_alias(n, t);
            //alias->member_of = this; // FIX: Add member_of to Alias
            return alias;
         }

Which made me audit all declarations for the presence of member_of / membership field.

Decl impl::member_of interface::membership()
Alias missing missing
Bitfield yep yep
Enumerator yep yep
Field yep yep
Fundecl yep yep
Parameter yep yep
Template yep missing
Typedecl yep yep
Var missing missing

There also three unorthodox declarations that do not have membership, but, since they are special, I am not worried about them much: Asm, Base_type and Using_declaration.

I cannot find justification for why Var and Alias do not have member_of, whereas Typedecl has. I am wondering if membership() should be a property of all declarations and could be pulled into interface Decl (common base for all declarations).

GabrielDosReis commented 3 years ago

There are comments in <ipr/impl> that suggest to remove membership() so I suppose at some point, I realized that it was redundant information as I believe the thinking behind membership() meaning is that it is morally

    return home_region().owner();

which does not even need to be a virtual function. How often is that information needed?

Any other declaration is just trying to refine the return type based on the specific declaration class node.

Thoughts?

GorNishanov commented 3 years ago

Sounds great!

I think it will even work for current instantiations (in the new and upcoming model where there will be a "micro-region" which will host the current instatiations for Option 2), the owner of that region could point at what is the proper owner of that decl).

This removes the necessity to maintain a redundant field storing information that can be inferred via home_region().owner().

Great resolution!

GabrielDosReis commented 3 years ago

And of course, interestingly, <ipr/interface> defines some of home_region() in terms of membership().region() :-)

Clearly, we are dealing with redundancy

GorNishanov commented 3 years ago

Fantastic! This demonstrates the equivalence :-)

membership() = home_region().owner() home_region() = membership().region()