With SwiftSyntax alone, you can't.
Since Swift allows custom operators to be defined with custom precedence and associativity relationships, and since operators can be defined in different modules and then imported (indeed, most operators are defined in the standard library, not built in to the compiler), these relationships can't be resolved at parsing time. When you parse a single source file, it has no knowledge of operators defined in its dependencies, so it can't resolve those.
The output you see from -dump-ast is after semantic analysis—once dependencies have already been loaded. If you run -dump-parse, you'll see what SwiftSyntax essentially gives you:
(if_stmt range=[<stdin>:1:1 - line:1:22]
(sequence_expr type='<null>'
(unresolved_decl_ref_expr type='<null>' name=number function_ref=unapplied)
(unresolved_decl_ref_expr type='<null>' name=+ function_ref=unapplied)
(integer_literal_expr type='<null>' value=1 builtin_initializer=**NULL** initializer=**NULL**)
(unresolved_decl_ref_expr type='<null>' name=== function_ref=unapplied)
(integer_literal_expr type='<null>' value=2 builtin_initializer=**NULL** initializer=**NULL**))
(brace_stmt range=[<stdin>:1:20 - line:1:22])))))
Once the compiler has all the information it needs about operators, it "folds" those sequences into expression trees based on precedence/associativity. In swift-format, we wanted to be able to format expressions using that knowledge, so we ported the folding algorithm to Swift: SequenceExprFolding.swift. This takes a flat SequenceExprSyntax and folds it into a tree. The internal nodes are still SequenceExprSyntax, but they have fixed shapes (2 elements for casts and 3 elements for binary expressions).
For the operators themselves, we just hardcoded the pre-defined operators in OperatorContext.swift. If the folding algorithm encounters one that it doesn't recognize, it tries to handle it with a reasonable default (within the compiler, this would be an error). This isn't perfect, but it's the best we can do without importing all the dependencies of the module containing the file being formatted, which is a non-starter. (In the future, we'll let people add frequently used custom operators to their config file.)
At some point we should upstream the sequence folding code to SwiftSyntax so other tools can make use of it more easily. We'd want to make some other enhancements first, like having distinct node types for the cast expression and binary expression nodes, instead of reusing SequenceExprSyntax.
