Expression::CallResult does not provide a way to get the arguments used in the call

[LegNeato]

Is your feature request related to a problem? Please describe.
Expression::CallResult only contains a handle to a Function. That function has FunctionArgs, but they are the args that are defined in the function signature rather than the args for the function call.

This is not a problem for the backends that output strings as they can just output the function name and an open paren and hope that Expression::FunctionArguments or whatever come later. It is a problem for my Rust backend (#5175) as I need to make a complete syn item for the function call when I encounter an Expression::CallResult:

Ok(Expr::Call(ExprCall {
    attrs: vec![],
    func: Box::new(Expr::Path(ExprPath {
        attrs: vec![],
        qself: None,
        path: Path::from(Ident::new(
            &func.name.as_ref().expect("function has name"),
            Span::call_site(),
        )),
    })),
    paren_token: syn::token::Paren::default(),
    args: ????, // <------ Can't access anything to fill out here.
}))

Describe the solution you'd like
I'd like Expression::CallResult to also contain the list of argument expressions the function is being called with, similar to how Expression::Math works.

Happy to put up a PR if someone points me in the right direction.

Describe alternatives you've considered

• Am I missing some way to do what I want?
• I could store the current function being called in some way, though I am not sure how I would know it is over...perhaps when encountering a store?

[LegNeato]

I was able to work around it by storing the current function call when parsing a Statement::Call as it has all the arguments. Then in the handling of Expression::CallResult I merely return the value. This works, but feels hacky to me for some reason. It also means any future multi-threading would require refactoring.

[teoxoy]

When you encounter a Statement::Call, that is when you should generate the code for the call.
Expression::CallResult is only needed so that we have a handle to what the call returned.

It's important to generate the code when you encounter the call statement because it could have side-effects.