@dominikh, Ian did a bit of research recently, and found that (1) while any staticcheck analyzer that uses IR will panic, it doesn't seem to be problematic to simply recover: the panics cause neither performance issues nor corrupted state. For this reason, we're thinking of just letting it panic on generic code rather than eagerly guarding against the panic.

An argument against doing this would be if there were an analyzer that doesn't panic, but rather reports inaccurate diagnostics. We've seen this before in e.g. #50658. However, this type of behavior should not be related to SSA and is usually easy to fix. If we were to generate a avoid-list of such analyzers, it might be easier to just patch them rather than work around them. Are you aware of any staticcheck analyzers that report inaccurate diagnostics (but don't panic) on generic code? Thanks.

CC @timothy-king

@findleyr I'm currently auditing all checks in Staticcheck. So far I've only found false negatives, or slightly inaccurate messages (usually by referring to a named type by its base name, not the instantiated form). I'm tempted to expect no false positives, but I can't say for sure. I do plan on finishing the audit before the end of the month, though.

Similarly, I'm planning on failing gracefully in buildir instead of panicing (and of course I'm hoping to actually support type parameters in the IR in time for 1.18.) However, recovering from the panics should be fine in the meantime. I'm not aware of any global state that would get corrupted.

@dominikh thanks for confirming. Closing as this is no longer actionable.