bug: Go 1.22 alternates naming of anonymous functions

[ivokub]

bug: Go 1.22 alternates naming of anonymous functions

[ivokub]

So to summarize - I'll only add the rewrite from "new-style anonymous functions" to old-style and a regression test which ensures that GetHintName is static for both anonymous and explicit function.

[gbotrel]

@ivokub can you do a quick PR with

.init.funcN to ..glob.funcN

? And a non regression test; don't want to hit the same issue in another deployment.
--> I'm not sure #1043 isn't dangerous; it means circuits compiled before #1043 are not compatible with a process compiled post #1043 right ?

[ivokub]

@ivokub can you do a quick PR with

.init.funcN to ..glob.funcN

? And a non regression test; don't want to hit the same issue in another deployment. --> I'm not sure #1043 isn't dangerous; it means circuits compiled before #1043 are not compatible with a process compiled post #1043 right ?

Indeed #1043 breaks compatibility between pre- and post 1043 circuits. So if we have a circuit compiled pre-1043, then solver/prover post-1043 fails as the hints are not found.

But still, I think 1043 is better for long-term as ensures more consistency. Instead of reverting I think it would better to add explicit hint overrides (for both Go <1.22 and =1.22 naming convention) to keep the backwards compatibility. I'd be happy to do it if makes sense.

[gbotrel]

Mmhhh no for the hint overhide, I think it's dirty ^^.
For Linea we can just recompile the circuits -- if that's the only change and the actual constraints are unchanged it's not a big issue.

[ivokub]

Yup, didn't change the constraints. Only changed hints defined as

var Hint = func(mod *big.Int, inputs []*big.Int, outputs []*big.Int) error {
//
}

to

func Hint(mod *big.Int, inputs []*big.Int, outputs []*big.Int) error {
//
}

in std/algebra packages.