fix(failed): show function

[Mte90]

On my daily check if I can resolve some bugs in Amber I tried with #210

I am not sure about meta.get_index() - 4 to get the function with the issue.

Using the amberr code:

import * from "std/text"

// Output
// 123

main {
    echo parse("123")
}

The meta is:

Context { index: 15, expr: [Tok[import 1:1], Tok[* 1:8], Tok[from 1:10], Tok["std/text" 1:15], Tok[// Output
 3:1], Tok[<new_line> 3:10], Tok[// 123
 4:1], Tok[<new_line> 4:7], Tok[main 6:1], Tok[<symbol: { > 6:6], Tok[echo 7:5], Tok[parse 7:10], Tok[<symbol: ( > 7:15], Tok["123" 7:16], Tok[<symbol: ) > 7:21], Tok[<symbol: } > 8:1]]

REDACTED

So I think that the actual index is always the next symbol where it should be the failed, in this case a }, followed by the closing parenthesis of the function, the parameters, the open parenthesis and finally the function name.
Right now amber doesn't share in the context what is the function or the line is processing, but in this way with - 4 we start from the end that it is more easy to be right so we can ignore the echo token.

Anyway I am not so skilled in the internals but let me know if needs some changes internally before to be able to close that ticket.

[hdwalters]

Good rule of thumb: suspect any code with magic numbers, like "4" here; there will probably be some edge case not covered by it. For example:

hwalters@Ghostwheel ~/git/amber-lang (210) 
$ cat untrusted.ab 
$ echo 'Hello world' $

hwalters@Ghostwheel ~/git/amber-lang (210) 
$ amber untrusted.ab 
thread 'main' panicked at src/modules/condition/failed.rs:64:171:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I'll see if I can find a better way of doing this.

[Mte90]

Yeah I wasn't sure too.
Maybe a check if there are parenthesis because probably with built-in doesn't work too.

[hdwalters]

In fact, the error message "The function '{}' requires..." implies that you expect the $...$ block to be run inside a function; but as my example shows, this is not always the case. I think you need to reword the error message so it doesn't reference a function name at all.

[hdwalters]

Which is exactly what we did before. So, based on the above comment, I would question whether we need this PR at all?

[Ph0enixKM]

One way we could solve this is by including an fun_name: Option<string> in the struct of this syntax module and let the function invocation module set the function name. Then if fun_name has Some we can print the alternative error message.

If this sounds convoluted, I'll open my PR tomorrow to show what I mean

[Ph0enixKM]

This module cannot move back to get the function name. The function invocation should provide this module with the name

[Mte90]

You know better than anyone else so I think that your proposal is good.
The purpose of the PR was to close the issue with adding the error message that it was missing (yet).