Vim9: can't use a subscript to get the n'th byte of a string inside ":def" function

[lacygoill]

Describe the bug

In Vim9 script, we can't use a subscript to get the n'th byte of a string inside a :def function.

To Reproduce

Run this shell command:

vim -Nu NONE -S <(cat <<'EOF'
    vim9script
    def Func()
        let str = 'abc'
        echo str[1]
    enddef
    defcompile
EOF
)

E1090 is raised:

Error detected while processing function <SNR>1_Func:
line    2:
E1090: List, Dict or Blob required

Expected behavior

No error is raised. b is echo'ed.

Environment

• Vim version: 8.2 Included patches: 1-1233
• OS: Ubuntu 16.04.6 LTS
• Terminal: XTerm(356)

Additional context

The issue disappears outside a :def function. Either at the script level:

vim9script
let str = 'abc'
echo str[1]

Or inside a legacy function:

vim9script
fu Func()
    let str = 'abc'
    echo str[1]
endfu
Func()

---

Here are some other unexpected errors:

vim9script
def Func()
    let l = []
    let x = len(l)
    if l[0]
    endif
enddef
Func()

This code raises E684, which is expected:

Error detected while processing function <SNR>1_Func:
line    2:
E684: list index out of range: 0

What is not expected is the address of the error line: 2. It matches this line:

let x = len(l)

While the error should come from the third line:

if l[0]

Similarly, consider this code:

vim9script
def Func()
    let l = []
    l = ['']
    if l[0][0]
    endif
    # a
    # b
    # c
enddef
Func()

It raises E714:

Error detected while processing function <SNR>1_Func:
line    7:
E714: List required

Again, the address of the error line seems wrong. 7 matches this line:

# c

While the error is raised from the third line:

if l[0][0]

---

I had a look at the todo list, and the only items which may be relevant are:

vim/runtime/doc/todo.txt

Line 50 in a90afb9

- Slice of list: [1, 2, 3][1:2].

vim/runtime/doc/todo.txt

Line 112 in a90afb9

- Implement more expressions, e.g. [a:b]

The first one is about list slicing. But the current issue is about strings, not lists. Not sure whether the distinction matters for a possible fix.

I don't know what is the second one about.