I have static this scattered throughout. Some are module static this and some are struct and class.


In a test case I have reduced to a struct that uses a static this and I get a cycle... even though, of course, the static this does nothing accept internal things.

It is very annoying to have to hack these cycles. while they can be bypassed for testing but production requires passing a runtime argument which is useless for distribution to users.

The cyclic testing is so ignorant that it effectively makes using any static this with any type of complex importing impossible, even though no cycles actually exist.


Something new has to be done.

I propose that some way be made to disable a static this from being included in the testing:

@NoCyclicRedundancyCheck static this()
{

}

I'm not sure if attributes will persist at runtime though. Any method is better than what we have now which essentially prevents all static this usage because one can't guarantee that the future won't create a cycle and then the program will break with no easy fix.

I got tired of waiting for a solution and rolled my own:



static this()
{

	import std.meta, std.stdio;

	// Find all <module>___This functions linked to this module
	auto Iterate()()
	{
		string[string] s;
		void Iterate2(alias m, int depth = 0)()
		{
			static if (depth < 4)
			{		
				static foreach (symbol_name; __traits(allMembers, m))
				{			

					static if (symbol_name == "object") { }
					else static if (symbol_name == m.stringof[7..$]~"___This")
					{
						s[m.stringof[7..$]] = m.stringof[7..$]~"___This";
					} else static if (isModule!(__traits(getMember, m, symbol_name)))
						{
							mixin("Iterate2!("~symbol_name~", depth + 1);");
						}
				}
			}
		}

		mixin("Iterate2!("~.stringof[7..$]~");");

		return s;
	}


	// Call all
	enum fs = Iterate;
	static foreach(k, f; fs)
		mixin(k~"."~f~"();");	
}


This code simply finds all <module>___This static functions linked to the module this static constructor is called from and executes them.

This doesn't solve the original problem but lets one execute the static functions to simulate static this. One could hypothetically even add attributes to allow for ordering(which is what the original cyclic redundancy check is suppose to solve but makes things worse since it is an ignorant algorithm).

This type of method might be more feasible, a sort of static main(). It does not check for static this of aggregates though but gets around the CRC's banket fatal error.

On 6/18/18 3:19 AM, Mr.Bingo wrote:
> I have static this scattered throughout. Some are module static this and some are struct and class.
> 
> 
> In a test case I have reduced to a struct that uses a static this and I get a cycle... even though, of course, the static this does nothing accept internal things.
> 
> It is very annoying to have to hack these cycles. while they can be bypassed for testing but production requires passing a runtime argument which is useless for distribution to users.
> 
> The cyclic testing is so ignorant that it effectively makes using any static this with any type of complex importing impossible, even though no cycles actually exist.

Indeed, the module dependency information is very coarse, so it's very easy to have "fake" cycles. All we look at is which modules import other modules.

Note that the cycle detection and ordering is correct, given the limited information the compiler provides.

> Something new has to be done.
> 
> I propose that some way be made to disable a static this from being included in the testing:
> 
> @NoCyclicRedundancyCheck static this()
> {
> 
> }

I'd love to see something like this. Note that the cycle check is not for redundancy, but for ordering how to call the static ctors. What you really want to call this is @IndependentCtor or something like that. This means that this segment of the static ctor does not depend on anything initialized by other static ctors, and so can be called at any time.

> I'm not sure if attributes will persist at runtime though. Any method is better than what we have now which essentially prevents all static this usage because one can't guarantee that the future won't create a cycle and then the program will break with no easy fix.

It would effectively split the static ctors into 2 functions, one that can be called independently, and one that has to be sorted. How this is normally handled is the compiler makes "fake" modules so it can put that moduleinfo somewhere.

-Steve

On 6/18/18 4:45 AM, Mr.Bingo wrote:
> I got tired of waiting for a solution and rolled my own:
> 
> 
> 
> static this()
> {
> 
>      import std.meta, std.stdio;
> 
>      // Find all <module>___This functions linked to this module
>      auto Iterate()()
>      {
>          string[string] s;
>          void Iterate2(alias m, int depth = 0)()
>          {
>              static if (depth < 4)
>              {
>                  static foreach (symbol_name; __traits(allMembers, m))
>                  {
> 
>                      static if (symbol_name == "object") { }
>                      else static if (symbol_name == m.stringof[7..$]~"___This")
>                      {
>                          s[m.stringof[7..$]] = m.stringof[7..$]~"___This";
>                      } else static if (isModule!(__traits(getMember, m, symbol_name)))
>                          {
>                              mixin("Iterate2!("~symbol_name~", depth + 1);");
>                          }
>                  }
>              }
>          }
> 
>          mixin("Iterate2!("~.stringof[7..$]~");");
> 
>          return s;
>      }
> 
> 
>      // Call all
>      enum fs = Iterate;
>      static foreach(k, f; fs)
>          mixin(k~"."~f~"();");
> }
> 
> 
> This code simply finds all <module>___This static functions linked to the module this static constructor is called from and executes them.
> 
> This doesn't solve the original problem but lets one execute the static functions to simulate static this. One could hypothetically even add attributes to allow for ordering(which is what the original cyclic redundancy check is suppose to solve but makes things worse since it is an ignorant algorithm).

The algorithm in druntime is correct, I'm sure you mean that the data provided to the algorithm is not detailed enough. This is actually a very tricky thing to get right. What you may end up with is a program that works or doesn't based on your linker order.

> This type of method might be more feasible, a sort of static main(). It does not check for static this of aggregates though but gets around the CRC's banket fatal error.

The worst thing to consider is template class/struct static ctors which get called in the *instantiating* module. I always recommend avoiding putting those into your code.

-Steve