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.
The new json1 format works just like json except that it treats tabs as
single characters instead of 8-character tabstops.
The main use case is to allow editors to pass -fjson1 so that they can
consume the json output in a character-oriented way without breaking
backwards compatibility.
Also addresses #1048.
Benjamin Gordon
Vidar Holen
Zero King