Fix promote_operation for ScalarNonlinearFunction

[odow]

I guess I didn't run solver-tests.yml on the ScalarNonlinearFunction PR recently.

https://github.com/jump-dev/MathOptInterface.jl/actions/runs/5108546474

[odow]

Something weird is going on with this commit and Revise.

If I run the test, edit, and then re-run the test I can trigger a stack overflow:

julia> MOI.Bridges.runtests(
               MOI.Bridges.Constraint.LessToGreaterBridge,
               """
               variables: x
               ScalarNonlinearFunction(1.5 * x) <= 1.0
               """,
               """
               variables: x
               ScalarNonlinearFunction(-(1.5 * x)) >= -1.0
               """,
           )
┌ Error: Failed to revise /Users/oscar/.julia/dev/MathOptInterface/src/Utilities/functions.jl
│   exception =
│    StackOverflowError:
│    Stacktrace:
│     [1] top-level scope
│       @ ~/.julia/dev/MathOptInterface/src/Utilities/functions.jl:1612
│    Revise evaluation error at /Users/oscar/.julia/dev/MathOptInterface/src/Utilities/functions.jl:1612
│    
└ @ Revise ~/.julia/packages/Revise/WHZdV/src/packagedef.jl:714
┌ Warning: The running code does not match the saved version for the following files:
│ 
│   /Users/oscar/.julia/dev/MathOptInterface/src/Utilities/functions.jl
│ 
│ If the error was due to evaluation order, it can sometimes be resolved by calling `Revise.retry()`.
│ Use Revise.errors() to report errors again. Only the first error in each file is shown.
│ Your prompt color may be yellow until the errors are resolved.
└ @ Revise ~/.julia/packages/Revise/WHZdV/src/packagedef.jl:824

but that doesn't happen if I just run without Revise.

I can't figure out the cause though... I'll re-run solver tests to see what happens.

[odow]

@blegat: so one issue. A lot of the bridges are very permissive in the functions that accept. And then they use promote_operation to figure out what the resultant function is. That makes it hard for new functions, because we need to add a bunch of these promote_operation methods. An alternative would be to make the bridge explicitly declare what functions they support, and external packages would need to opt-into them. Not something we necessarily need to change now, but another MOI 2.0 list.

[blegat]

Having to opt-in for each bridge would loose a lot of the bridges advantages. Right now, the fact that we will be able to no nonlinear conic with the bridges just by implementing a few MOI.Utilities is quite appealing.
I can understand that when you create a new function you would like to be able to test it without having to do all these things.
One thing you could do is to use MOI.Bridges.remove_bridge with the bridges that are annoying you.
We could have a way to say that an operation is not supported as well so that you could do that and then not have to implement MOI.Utilities.operate, etc...

[odow]

https://github.com/jump-dev/MathOptInterface.jl/actions/runs/5115502094

[odow]

The type inference segfault in x86 looks like a problem. But I can't figure out why it's happening. The amount of dispatch going on with promote_operation makes it really hard to trace or reason about. There's lots of Union types that pick of different bits.

[odow]

#2182 also triggered it: https://github.com/jump-dev/MathOptInterface.jl/actions/runs/5126479287/jobs/9221017061. So it turns out it's not this PR...

[odow]

https://github.com/jump-dev/MathOptInterface.jl/actions/runs/5130375265

[odow]

@blegat happy? The x86 error is sporadic. Restarting CI once (or twice) seems to get it passed. I wonder if it's an issue with the available memory?

[blegat]

It's weird, I also have issues with 32 bits since Julia v1.9 on JuliaAlgebra/MultivariatePolynomials.jl#256 but there I think it's a gcd tests were Ints are overflowing so it keeps creating larger and large polynomials and allocating a lot until it runs out of memory. There was no issue before v1.9 though

[blegat]

Excited to have the SNF propagate through the bridge graph