9b50336e47
This introduces a `MethodRefExpr` node synthesized out of `DotSyntaxCallExpr` under the `LookupExpr` hierarchy. This means that much like ```free_function(1, 2)``` is a `CallExpr` with `getFunction` giving a `DeclRefExpr`, ```foo.method(1, 2)``` is now a `CallExpr` with `getFunction` giving a `MethodRefExpr`. `ApplyExpr::getStaticTarget` has been made work with it (as well as `ConstructorRefCallExpr` which for the moment has been left where it is), a new `MethodApplyExpr` has been introduced deriving from it, and control and data flow libraries have adapted. A small but was fixed in `qlgen` where the default constructor for DB types was not correctly subtracting derived IPA types depending on the order of definitions in `schema.yml`. There are still some occurrences of `DotSyntaxCallExpr`, and as already mentioned the other `SelfApply` class (`ConstructorRefCallExpr`) was left alone. Their treatment is left for a future PR.
Code generation suite
This directory contains the code generation suite used by the Swift extractor and the QL library. This suite will use
the abstract class specification of schema.yml to generate:
- the
dbschemefile (seedbschemegen.py) - the QL generated code and when
appropriate the corresponding stubs (see
qlgen.py) - C++ tags and trap entries (see
trapgen.py) - C++ structured classes (see
cppgen.py)
Usage
By default bazel run //swift/codegen will update all checked-in generated files (dbscheme and QL sources). You can
append -- followed by other options to tweak the behaviour, which is mainly intended for debugging.
See bazel run //swift/codegen -- --help for a list of all options. In particular --generate can be used with a comma
separated list to select what to generate (choosing among dbscheme, ql, trap and cpp).
C++ code is generated during build (see swift/extractor/trap/BUILD.bazel). After a
build you can browse the generated code in bazel-bin/swift/extractor/trap/generated.
Implementation notes
The suite uses mustache templating for generation. Templates are
in the templates directory, prefixed with the generation target they are used for.
Rather than passing dictionaries to the templating engine, python dataclasses are used as defined
in the lib directory. For each of the four generation targets the entry point for the implementation is
specified as the generate function in the modules within the generators directory.
Finally, codegen.py is the driver script gluing everything together and specifying the command line
options.
Unit tests are in the test directory and can be run via bazel test //swift/codegen/test.
For more details about each specific generation target, please refer to the module docstrings
in the generators directory.