RFR: 8305672: Surprising definite assignment error after JDK-8043179 [v3]

[Archie Cobbs]

> The fix for [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179) is to clear the DU flags for all variables when entering a lamba. This reflects the fact that the lamba's actual execution could be arbitrarily far in the future, so we can't assume anything that is DU when the lambda is created is still DU when the lambda actually executes.
> 
> However, this fix created a new bug. The problem is that `visitLambda()` does not save & restore the `uninitsTry` bits, which are used by `visitTry()` to track DU variables within `try { }` blocks. So if there is a `try { }` block outside the lambda and a `try { }` block inside the lambda, the latter can "leak" DU state up to the former via this field. As a result, a final variable that should still be DU at the completion of the outer `try { }` block can be incorrectly recorded as not DU, leading to the bogus "might already have been assigned" error.
> 
> This patch fixes that by adding the necessary save & restore logic.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8305672
 - Merge branch 'master' into JDK-8305672
 - Fix failure of visitLambda() to save & restore uninitsTry bits.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13366/files
  - new: https://git.openjdk.org/jdk/pull/13366/files/a07bdb78..3fce25b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13366&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13366&range=01-02

  Stats: 20571 lines in 488 files changed: 14268 ins; 4168 del; 2135 mod
  Patch: https://git.openjdk.org/jdk/pull/13366.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13366/head:pull/13366

PR: https://git.openjdk.org/jdk/pull/13366