[swiftsrc2cpg] Implement desugaring for optional binding syntax

[max-leuthaeuser]

Add support for optional binding constructs in if/while/guard statements:

If-let and While-let:

• Single bindings: if let a = foo() { ... }
• Shorthand syntax: if let a { ... } (checks existing variable)
• Multiple bindings: if let a = foo(), let b = bar() { ... }
• Mixed cases: if let a = foo(), let b { ... }
• Tuple patterns: if let (a, b) = foo() { ... }
• Mixed simple + tuple: if let a = foo(), let (b, c) = bar() { ... }
• While loops: while let item = iterator.next() { ... }

Guard-let:

• Single bindings: guard let a = foo() else { exit }
• Shorthand syntax: guard let a else { exit } (checks existing variable)
• Multiple bindings: guard let a = foo(), let b = bar() else { exit }
• Mixed cases: guard let a = foo(), let b else { exit }
• Guard with other conditions: guard let a = foo(), flag else { exit }

Desugaring strategy:

• Condition block: Creates temp variables for simple optional bindings with initializers, evaluates expressions within nil checks with proper short-circuit semantics using && operator
• Then/body block: Creates properly scoped locals, unwraps temp variables into final bindings
• Tuple patterns: Excluded from condition desugaring, processed as-is in body block
• Guard special handling: Implemented in astsForBlockElements (AstCreatorHelper.scala) because guard's then block includes all subsequent statements in the function, not just an explicit block

Desugaring examples:

if let a = foo() { body } desugars to:

let <tmp>0;
if { (<tmp>0 = foo()) != nil } {
  let a = <tmp>0
  body
}

if let a = foo(), let b = bar() { body } desugars to:

let <tmp>0;
let <tmp>1;
if { (<tmp>0 = foo()) != nil && (<tmp>1 = bar()) != nil } {
  let a = <tmp>0
  let b = <tmp>1
  body
}

This ensures proper short-circuit evaluation: bar() is only called if foo() returns non-nil.

if let a { body } desugars to:

if a != nil {
  body
}

guard let a = foo() else { exit } desugars to:

let <tmp>0;
if { (<tmp>0 = foo()) != nil } {
  let a = <tmp>0
  // ... rest of function
} else {
  exit
}

guard let a = foo(), let b else { exit } desugars to:

let <tmp>0;
if { (<tmp>0 = foo()) != nil && b != nil } {
  let a = <tmp>0
  // ... rest of function
} else {
  exit
}

This does no type "unwrapping" (i.e., Optional[T] -> T).

1. by default (without types from the compiler): we do not have any types there anyway. That would only work if the user code explicitly uses type annotation which mostly just does not happen.
2. with types from the compiler: we set type fullnames for identifiers and call fullnames for calls anyway (directly from what the compiler gives us). Hence, no need to create a synthetic unwrap call. Imho, that would not bring anything to the table w.r.t. data-flow.

[maltek]

how is the tuple assignment desugared?

[max-leuthaeuser]

This is not done with full coverage there. That needs an additional PR.
There is special tuple de-sugaring, but only in condition/pattern-matching contexts like if case, guard case, and switch, where tuple subjects get de-sugared into tmp variables plus .0, .1, etc. accesses. That de-sugaring is in astsForBindingTuplePattern / astsForBindingTupleExpr.

For optional tuple pattern bindings here we can reuse it mostly (store in tmp and do the nil comparison; locals and .0, .1, etc. accesses in then block).

[maltek]

I'm not happy with some of the tests. They are so fuzzy. E.g. AvailabilityQueryTests is using contains and not be empty all over the place instead of complete matches that'd tell us exactly what's there and what isn't there. And some of the queries in there are also structured similarly imprecise - e.g. we know that nilCheck has an assignment argument, but we don't know if it has any other arguments.

(It's not just this test though, some of the others are similar.)

[max-leuthaeuser]

Ok, I'll overhaul them (tbh they were bad already before this PR).

[max-leuthaeuser]

I'm not happy with some of the tests. They are so fuzzy. E.g. AvailabilityQueryTests is using contains and not be empty all over the place

Are we talking about the same file? I can not find any "not be empty" assertion there.
There are a few "shouldBe empty" assertions but that's expected (testing for empty true/false blocks).

Do not yet re-review. I am still bug-hunting a local creation issue. Got it.

[maltek]

generally, I think it's better to write such tests like this instead:

      val List(thenPrint: Call, thenAssign: Call) = guardIf.whenTrue.astChildren.l

That way, any potential children which are not calls aren't swept under the rug.

(Depending on the warning levels of the project, inside might be required.)

[max-leuthaeuser]

Yeah, warning level do not allow this implicit type narrowing.
Rewriting everything to inside matchers is something thats needs to be addressed separately as the current test style with .isFoo traversals is scattered across the whole test base here.