Closed kotlarmilos closed 1 month ago
I've converted this PR to draft as we plan to have additional iterations before another review. @stephen-hawley thank you for your contribution. Here are some thoughts:
TypeEnv
, MethodEnv
, and ArgumentEnv
. I think we should operate with a single source of truth, which should be the declarations. Do you see anything missing in the declarations?{Name}Emitter
?FieldDecl
instead of ArgumentDecl
?ModuleEmitter
and be invoked from Program.cs
.IFactory
. The codegen might bloat with such generics usage, and we may try to simplify it. I imagine that in most cases, we would rely on string representation and not actual generic types in the IFactory
implementations.Let's integrate your changes and add comments, documentation, and more test cases.
I strongly recommend that you take TypeSpecParser, TypeSpecTokenizer, TypeSpecToken, and `TypeSpec (and its subclasses). This represents a very compact recursive descent parser than can handle whatever the swift compiler can generate.
Let's add them in a follow-up PR as this one is already ~+5k loc. What is the difference between TypeDecl
and TypeSpec
?
Merging this PR. Any additional feedback will be addressed in follow-up work.
Description
This PR implements basic support for frozen structs. It refactors the tooling, including the type database and declarations, to manage recursive dependencies. It introduces Swift metadata projections and type registrar system for mapping between Swift and C#. Additionally, it updates the parser and emitter to interact with the type database and registrar, and implement basic type filtering. Tests are added for non-generic nested frozen structs with primitive properties.