Note that we cannot write tests for these at the moment. Passing
```
-enable-experimental-feature DefaultIsolationPerFile
```
to the extractor results in:
```
error: experimental feature 'DefaultIsolationPerFile' cannot be enabled in production compile
```
These are currently added implicitly by the compiler in the context of
`if`/`switch` expressions. In the future, there might be explicit
`then <expr>` statement useful for cases where one would like to add
more than one statement in the branch, to mark what value to actually
use.
See https://forums.swift.org/t/pitch-multi-statement-if-switch-do-expressions/68443
* `variables` under `CaseStmt` are now AST children, which solves
orphan `VarDecl`s in that case
* reordered `CaseStmt` AST children to be `labels > variables > body`
(was `body > labels`)
* made `NamedPattern::getVarDecl` an extracted property instead of
`getName`
* The above led to duplicate DB entities because of a quirk in the
Swift compiler code. This is solved by tweaking the extraction of
`variables` under `CaseStmt` to not use `getCaseBodyVariables`.
This is done by adding a `isSuccessfullyExtracted` predicate that is
filled for primary files at the very end of the extractor invocation if
the frontend was performed successfully. If for example the extractor
crashes this will therefore not be filled.
The upgrade script is written so that `SuccessfullyExtractedFiles.ql`
on an upgraded script will give exactly the same results as before it.
As discussed [in this accepted proposal][1], parameter labels do not
take part any more in making up a function type, so we need to not
extract them any more to avoid DB inconsistencies.
These were unused in the library, which makes the upgrade and downgrade
scripts have full compatibility.
[1]: 9c53790a13/proposals/0111-remove-arg-label-type-significance.md
As shown by the extractor's code not needing any change, the DB values
already had that more specific type, which is why the upgrade/downgrade
scripts are actually no-ops.
