Shellcheck throws an error and stops parsing on valid bash code when you open a file descriptor for a code block using an array index variable

BUG REPORT

Rule ID: SC1070, SC1141, SC1083,
My shellcheck version: online
[x] The rule's wiki page does not already cover this
[x] I tried on https://www.shellcheck.net/ and verified that this is still a problem on the latest commit

Here's a snippet or screenshot that shows the problem:

#!/bin/bash

declare -a fdA
{ :; } {fdA[0]}>file1

Here's what shellcheck currently says:

Line 3: declare -a fdA ^-- SC2034 (warning): fdA appears unused. Verify use (or export if used externally).

Line 4: { :; } {fdA[1]}>file1 ^-- SC1070 (error): Parsing stopped here. Mismatched keywords or invalid parentheses? ^-- SC1141 (error): Unexpected tokens after compound command. Bad redirection or missing ;/&&/||/|? ^-- SC1083 (warning): This { is literal. Check expression (missing ;/\n?) or quote it. ^-- SC1083 (warning): This } is literal. Check expression (missing ;/\n?) or quote it.

Here's what I wanted or expected to see:

Shellcheck not throwing an error and continuing to parse.

The SC1070 is particuarly annoying here, since:

it completely stops shellcheck's parsing/analysis, and
it cannot be ignored

ADDITIONAL INFO

The part that shellcheck cant handle is assigning the file descriptor to a specific index in an array (the fdA[0]. it handles the following without error:

{ :; } {fd}>file

Also, it doesnt matter if you use curly braces or parenthesis, nor if you split the command over multiple lines, nor if you use a command other than :. For example, the following throws the same error:

(
    echo hi
) {fdA[0]}>file

Lastly, it is worth noting that shellcheck handles this correctly if you use an exec statement instead. e.g., the following works without error:

exec {fdA[0]}>file

NOTE: this still does throw an erronious SC1083 warning, but this can be manually ignored and doesnt cause shellcheck to error out and stop parsing.

koalaman / shellcheck