[hvitved]

This PR adds support for nested types in type inference. Since nested types can interact with both generics and sub typing, we need a way to represent outer types in addition to the nested type itself:

class Outer<TOuter> {
    class Inner<TInner> {
    }
}

class SubOuter<TSubOuter> : Outer<TSubOuter?>

For example, we need to distinguish Outer<Int>.Inner<Int> from Outer<Bool>.Inner<Int>, as well as from SubOuter<Int>.Inner<Int>.

We do this by adding a pseudo type parameter to each nested type, which will hold type information about the outer type. For example, Outer<Int>.Inner<String> is represented as

TypePath	Type
""	Inner
"TInner"	String
"Inner_Parent"	Outer
"Inner_Parent.TOuter"	Int

where Inner_Parent is the special type parameter belonging to the nested class Inner.

Things can get further complicated when type aliases are used, which prompted a change to the existing TypeMention logic: Instead of resolving aliases directly in the getTypeAt relation, we split resolution logic into different phases, where the initial getUnexpandedTypeAt does not expand aliases, but instead treat them as ordinary types. Ultimately, in getTypeAt, aliases are fully expanded, and type inference still does not need to worry about them.

DCA is fine.

[Copilot]

🟡 Changes recommended

Implicit argument handling and parent-scope checks still produce incorrect or incomplete nested-type inference.

2 open issues

• Exclude qualified member mentions from implicit argument inference · New
• Allow implicit parent qualification when the parent is in scope · New

What changed in this PR

Extends Unified’s type inference to represent nested types and preserve their enclosing generic arguments, with Swift regression coverage.

Changes:

• Adds parent-type parameters and qualified type names.
• Updates type mentions and enum construction to propagate parent-type paths.
• Adds nested-type tests and updates inference expectations.

File	Description
unified/​ql/​test/​library-tests/​type-inference/​type-inference.expected	Updates expected inference results.
unified/​ql/​test/​library-tests/​type-inference/​nested_types.swift	Adds nested-generic, self-type, and extension coverage.
unified/​ql/​test/​library-tests/​type-inference/​generics.swift	Removes a resolved MISSING annotation.
unified/​ql/​test/​library-tests/​type-inference/​classes.swift	Updates the inline expected nested-type name.
unified/​ql/​lib/​codeql/​unified/​internal/​typeinference/​TypeMention.qll	Adds nested-type qualification and implicit argument handling.
unified/​ql/​lib/​codeql/​unified/​internal/​typeinference/​TypeInferencePluginSwift.qll	Removes Swift-specific enum plugin hooks.
unified/​ql/​lib/​codeql/​unified/​internal/​typeinference/​TypeInferencePlugin.qll	Removes enum-specific hooks and wrappers.
unified/​ql/​lib/​codeql/​unified/​internal/​typeinference/​TypeInference.qll	Integrates parent paths into constructor inference.
unified/​ql/​lib/​codeql/​unified/​internal/​typeinference/​Type.qll	Introduces parent-type parameters and qualified names.
unified/​ql/​lib/​codeql/​unified/​internal/​AstExtra.qll	Adds shared enum relationships and enum-field modeling.

_{Review effort: Max}

[Copilot]

🔵 Needs a closer look

Unresolved generic-inference regressions and changes to recursive type paths require fixes and human validation.

3 open issues

• Bind inherited and enclosing type parameters in abstractions · New
• Resolve extensions across all enclosing class scopes · New
• Restrict nested-type fallback to lexical parent scopes · New

2 resolved since last review

• Exclude qualified member mentions from implicit argument inference
• Allow implicit parent qualification when the parent is in scope

_{Review effort: Max}

[Copilot]

🔵 Needs a closer look

Recursive generic substitution and constructor propagation have unresolved correctness concerns and need expert validation.

2 open issues

• Propagate enclosing qualifier arguments through qualified aliases · New
• Propagate contextual enclosing arguments through inherited constructors · New

3 resolved since last review

• Bind inherited and enclosing type parameters in abstractions
• Restrict nested-type fallback to lexical parent scopes
• Resolve extensions across all enclosing class scopes

_{Review effort: Max}

[Copilot]

🟡 Changes recommended

Parent-type inference can recurse into itself and produce conflicting types for nested classes and aliases.

7 open issues

• Prefer lexical parent over enclosing subclass fallback · New
• Preserve alias-expanded parent specialization · New
• Exclude fixed-specialization aliases from implicit arguments · New
• Exclude generic alias bases from parent fallback · New
• Avoid fallback on specialized unqualified alias uses · New
• Correct expected and spurious constructor targets · New
• Use bar(...) for zero-argument type inference · New

2 resolved since last review

• Propagate enclosing qualifier arguments through qualified aliases
• Propagate contextual enclosing arguments through inherited constructors

_{Review effort: Max}

[Copilot]

🟡 Changes recommended

Alias expansion can lose enclosing generic arguments or introduce conflicting certain types.

3 open issues

• Preserve alias-defined parent type during qualification · New
• Preserve lexical parent for sibling-owned aliases · New
• Substitute enclosing parameters during alias expansion · New

7 resolved since last review

• Prefer lexical parent over enclosing subclass fallback
• Use bar(...) for zero-argument type inference
• Correct expected and spurious constructor targets
• Avoid fallback on specialized unqualified alias uses
• Exclude generic alias bases from parent fallback
• Exclude fixed-specialization aliases from implicit arguments
• Preserve alias-expanded parent specialization

_{Review effort: Max}

[Copilot]

🔵 Needs a closer look

The coupled recursive inference changes retain a correctness defect and require human validation.

1 open issue

• Restrict prefix matching to parent-type parameter paths · New

1 resolved since last review

• Narrow nested alias exclusion or document the inference limitation

_{Review effort: Max}

[Copilot]

🟡 Changes recommended

Nested alias handling still loses qualifier information in forwarded references, generic arguments, and tuple elements, causing incorrect outer-type inference for qualified alias uses.

2 open issues

• Preserve qualifiers through forwarded generic alias references · New
• Preserve qualifiers for nested alias tuple elements · New

1 resolved since last review

• Restrict prefix matching to parent-type parameter paths

_{Review effort: Max}

[Copilot]

🟡 Changes recommended

The enum-field inference rule misses generic arguments beneath parent paths, preventing nested enum initializers from acquiring outer type arguments from their annotations.

1 open issue

• Infer missing outer type arguments for nested enum fields · New

2 resolved since last review

• Preserve qualifiers for nested alias tuple elements
• Preserve qualifiers through forwarded generic alias references

_{Review effort: Max}

[Copilot]

🟡 Changes recommended

The QLDoc references a nonexistent parameter, and test annotations contain internal issue URLs that external contributors cannot access.

2 open issues

• Correct the QLDoc parameter reference · New
• Remove inaccessible issue links from MISSING annotations · New

1 resolved since last review

• Infer missing outer type arguments for nested enum fields

_{Review effort: Max}

[asgerf]

Why do enum constructors need special handling here (and in needsContextualTyping)? If the enum case class is considered a subtype of the enum class, doesn't it work out via the normal code path?

[hvitved]

In the end I decided to not give enum constructors the special types, but instead the type of the whole enum as before. So this logic is about translating the special constructor types to the enum types.