Bug 275038 – Fix miscellaneous complaints of the clang static analyzer.

• Component: JavaScriptCore
• Status: ASSIGNED

[Mark Lam]

1. Address unneeded variable initializations in a few ways:
   a. Where the variable is clearly unused or overridden after initialization, remove the variable.

      In 3rd party code, just comment out the initialization with an added comment that this is to placate the static analyzer.
      This makes it easier for folks doing an update of the 3rd party code later to understand why this change was made, and
      decide how to handle merge conflicts.

   b. Where the variable initialization is part of a repeated idiom.

      For example, a parser may parse for a sequence of words. The parser is therefore made up of blobs of code to parse
      for each word in the sequence.  Each code blob is expected to follow an idiom of advancing the cursor when it's done.
      This enables the next code blob to parse for the next word.

      When we get to the last word, technically we can elide the cursor advance in the last code blob because no one is
      currently dependent on the cursor beyond this point.  However, this opens up an opportunity for a bug to be introduced
      later.  In the future, if someone adds more code blobs to parse additional words downstream, the new code blobs will
      expect the previous last code blob to follow the idiom and advance the cursor.  Our elision broke the idiom, thereby
      introducing a bug in the new code, unless we remember to go back an un-elide the cursor advance.

      For cases like this, it's better to just keep the unneeded initialization.  Instead, we'll add a `(void)var` (which is
      what the UNUSED_PARAM macro does) to placate the static analyzer.

   c. Where the variable initialization is in a body of code deemed to be somewhat complex.

      Similar to (2), while it is possible to determine that the variable will be unused thereafter, it is difficult for
      future code that gets added to realize that the variable wasn't updated.  As a result, this is an opportunity for
      introducing bugs.  So, instead of eliding the initialization, we apply the solution in (2) to placate the static
      analyzer.

2. In 1st party code where possible and appropriate, we'll reshape the code to move variable initializations to where they
   are needed e.g. inside a `if (verbose)` code block.  This avoids initializing the variable when unneeded.

3. For cases of uninitialized variables in non-performance sensitive code (e.g. AllowUnfinalizedAccessScope), we'll just
   initialize the variables (though unneeded) to placate the static analyzer.

These changes resolves about 300 clang static analyzer warnings from building all of WebKit.

[Radar WebKit Bug Importer]

<rdar://problem/129144030>

[Mark Lam]

Pull request: https://github.com/WebKit/WebKit/pull/29437