SC2155 (Declare and assign seperately) not detected when assigned variable name is dynamic

[jriddy]

For bugs with existing features

• Rule ID: SC2155
• Version: 0.11.0
• [x] The rule's wiki page does not already cover this (e.g. https://shellcheck.net/wiki/SC2086)
• [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:

Shellcheck does alert on this, but it doesn't work with dynamic variable names:

Example:

export FOO="$(bar)"

This correctly produces as described in the wiki

However, when using a dynamically named variable:

#!/bin/bash 

BAZ='FOO'
export "$BAZ"="$(bar)"

This does not trigger this warning, even though it's the same underlying issue as SC2155, just with variable name indirection happening.

Here's what shellcheck currently says:

No issues detected!

Here's what I wanted or expected to see:

SC2155 (warning): Declare and assign separately to avoid masking return values.

[char23-web]

SC2155 (warning): Declare and assign separately to avoid masking return values.

[wwp]

Still around SC2155, since there is no other way to assign a value to a variable you declare read-only than assigning its value on the declare statement, raising this warning could be disputable, couldn't it?

declare -r VAR=$(command that always returns 0 - or not) ^-^ SC2155 (warning): Declare and assign separately to avoid masking return values.

SC2155 is suggesting something that is somehow impossible (no it's not possible to declare -r and assign separately and yes indeed it's possible to store the result of the command in another var, check its return code then assign the value to VAR on the declare -r statement, but.. that's no longer a single statement. Should I open a separate issue ticket? Maybe shellcheck could 'understand' what declare -r is?

[jriddy]

declare -r VAR=$(command that always returns 0 - or not) ^-^ SC2155 (warning): Declare and assign separately to avoid masking return values.

That's a different case than this, and think what strict compliance there looks like is:

tmp_var="$(mycmd)"
declare -r VAR="$tmp_var"