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

[jkool702]

BUG REPORT

• Rule ID: SC1070, SC1141, SC1083,
• My shellcheck version: online
• The rule's wiki page does not already cover this
• 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:

1. it completely stops shellcheck's parsing/analysis, and
2. 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.