SC2247 already warns about translated strings that look like $"(foo)" or
$"{foo}". Since typical use of translated strings is to translate whole
messages, a string like $"foo" is likely to be a similar mistake if foo
is the name of an existing variable. Conversely, a string like
$"foo bar" is potentially meant to be a message id even if foo is a
known variable.
Add a warning for the $"foo" case, but make it separate from the
existing warning so that projects that reuse variable names as their
message ids can separately disable the new warning.
The shflags command-line flags library creates variables at runtime
with a few well-defined functions. This causes shellcheck to spit out
lots of warnings about unassigned variables, as well as miss warnings
about unused flag variables.
We can address this with two parts:
1. Pretend that the shflags global variables are predefined like other
shell variables so that shellcheck doesn't expect users to set them.
2. Treat DEFINE_string, DEFINE_int, etc. as new commands that create
variables, similar to the existing read, local, mapfile, etc.
Part 1 can theoretically be addresssed without this by following sourced
files, but that doesn't help if people are otherwise not following
external sources.
The new behavior is on by default, similar to automatic bats test
behavior.
Addresses #1597
Always using braces makes it harder to accidentally change a variable by
pasting other text next to it, but the warning is off by default because
it's definitely a style preference. Omit special and positional
variables from the check because appending additional characters to them
already doesn't change parsing.
References of the form $var and ${var} both map to the same structure in
the AST, which prevents any later analysis functions from distinguishing
them. In preparation for adding checks that need this info, add a Bool
to T_DollarBraced that tracks whether the braces were seen at parsing
time and update all references so that this change is a no-op.