[swift2objc] Support optionals #1742
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Optionals in Swift are essentially the same as nullables in Dart. This PR adds support for them by parsing them into the new
OptionalTypeclass.The parsing side of this is pretty complicated, because unlike classes, structs, and primitives, optional types aren't presented in the symbolgraph as a single token with a type ID. Instead we get a "?" token that comes after the type token. So now we have to write a parser.
I wrote a pretty general parser architecture, because we're also going to need it for closures, tuples, and arrays, which also appear as a sequence of tokens. I used a Pratt parser, but without any precedence, so it ends up being pretty simple and readable. The entire parser is in
parse_type.dart, and the entrypoint isparseType.One extra complexity is that sometimes some of the tokens are concatenated. For example, you'd expect
foo(bar: Int?)to be tokenized as["foo", "(", "bar", ": ", "Int", "?", ")"], but actually the"?"and")"get merged:["foo", "(", "bar", ": ", "Int", "?)"]. So we also need a preprocessing stage that splits up all the known cases where this happens. This is handled by theTokenListclass.Other changes
parseInitializerParamsto use the newparseTypefunction, but it ends up being simpler and more readable.idandnamefromReferredType, since not all types have a name or ID.idbased have been migrated to the newsameAsmethod.namenow prints theswiftType.FunctionDeclaration'sreturnTypenon-nullable. Not specifying the return type of a function just means it'sVoidin Swift, so there's no point making this field nullable. Making it non-null simplifies some stuff.pase_function_declaration.darttoparse_function_declaration.darttest/unit/parse_initializer_param_input.jsonbecause it isn't actually used by the test.Optional primitives aren't supported atm: #1743