Add Debugger Attach Point

[ByronMayne]

When a source generator has an exception when released it can be very very hard to track down the exception. It would be nice to have a method to have the debugger auto attach based on an external parameters. This could be an environment variable that can be turned on.

SGF_ATTACH_DEBUGGER=True

[scooter12]

I just finished splitting that last pull into two parts and have this open right where that functionality would be added. One question, how deep do you want the debugger to be attached? I think there are two viewpoints here, 1) SGF is a library so from an outsiders perspective should be trusted to work and thus any exceptions are the end-users fault and thus the breakpoint should be in emitted SourceGeneratorHoist static constructor which more or less puts them inside "their code". 2) generators are complicated so lets assume issues can be anywhere and breakpoint in the earliest possible spot IncrementalGenerator static constructor.

Or just split the different and do both:
SGF_ATTACH_DEBUGGER
SGF_ATTACH_DEBUGGER_LL

[ByronMayne]

It's for folks testing out their own generators in production. Ideally he generator has pretty good error handling but I just burned myself with this with AutoFactories . It was throwing a cryptic null reference exception and there is no way to attach the debugger. So I just recompiled it and added a debugger.Launch() and overrode the nuget package.

This is why hiding it behind a variable would be a fine option. I would put it in the static constructor of the SourceGeneratorHoist class.

[ByronMayne]

At that point their generator has not been realized so even if their static constructor throws an exception we can catch it

[scooter12]

Yep. I'll send that over tonight

[scooter12]

I might need a better understanding of what you mean by "in production", but I assume you mean "some regular person using SGF via it's nuget pkg". The unsure part is your requirements for when to trigger the option.

If you want to set the debug option from an SGF dependent generator while developing it, I can see doing that from either the previous commit that give us easy access to any CompilerVisibleProperty vars, which is the best solution since it can be independently controlled by the target/build, or extending the SgfGenerator attribute with a AttachDebuggerOnStartup prop, but then it's not easily configurable.

If you meant set the option from inside your dependent generator code, It looks like the only "easy" way to do this is to attach the debugger in the emitted {MyClass}AppSourceGeneratorHoist constructor since there's be no determinate way to signal any of the hoist class's static constructors/methods. So not quite as low-level as wanted but pretty close.

The least hacky way to trigger inside the SourceGeneratorHoist static constructor would be to make SourceGeneratorHoist a non-abstract singleton that creates itself and all but the static constructor & Initialize converted to non-static. I don't see a problem with that. I can think of a few other ways but they get progressively weird.

[ByronMayne]

It would be the case when you publish a source generator that is built of SGF and your generator is causing problems. An easy example is throwing an exception. With SGF you at least get the call stack vs vanilla where it just says it failed.

The only reason I would make it a environment variable is because you can throw exceptions in the the constructors of your generator or inside of the PostInitialization callback. At these points you don't have access to the compiler variables.