As `ASTMangler` crashes when called on `ModuleDecl`, we simply use
its name.
This might probably not work reliably in a scenario where multiple
modules are compiled with the same name (like `main`), but this is left
for future work. At the moment this cannot create DB inconsistencies.
The `getName` in `Type.qll` was issuing a warning in other generated
classes having a `getName` from a `name` property in `schema.yml`.
To fix the possible inconsistency, `diagnostic_name` is being renamed to
`name` in the schema. Despite the scary doc comment on
`swift::Type::getString` (namely `for use in diagnostics only`), that
seems to be the right generic naming mechanism for types, and it
coincides with the name we were extracting on types with an explicit
`name` property.
In case we find a case where `Type::getString` gives something wrong,
we can probably just patch it on that specific type class.
It turns out the threshold of 5 lines for stub modification detection
was too strict: in case of a long class name the QL formatter will put
the closing brace of the empty class definition on a new line, leading
to codegen fail with an error thinking the stub was modified.
On the other side of things, also adding a base to a stub class was not
being detected as a modification.
Now the modification test is slightly smarter. If the stub still marked
as generated and
* has more than 6 lines, or
* the contents does not match a regexp aproximation of a plain stub
then codegen will abort. The test will still avoid reading the whole
contents of all the stubs.
If one modifies a QL stub but forgets to remove the `// generated`
header comment, codegen will now abort with an error rather than
silently reverting the change.
This is based on the rough heuristic of just counting the lines. If any
change is done to the stub class, the number of lines is bound to be
5 or more.
This new class encompasses both `AbstractFunctionDecl` and
`AbstractClosureExpr`, together with their common parts (namely
parameters and the body).
`ClosureExpr` and `AutoClosureExpr` got ported to structured C++
generated translation in the process.
This adds:
* a base `README.md` file to `codegen`
* module docstrings for the modules in `generators`
* help strings on all command line flags
Moreover some unneeded command line flags (`--namespace`,
`--include-dir` and `--trap-affix`) have been dropped.
Python code was simplified, and now a `--generate` option can be used
to drive what can be generated.
The extractor pack creation now will use an internally generated
dbscheme. This should be the same as the checked in one, but doing so
allows `bazel run create-extractor-pack` and `bazel run codegen` to be
run independently from one another, while previously the former had to
follow the latter in case of a schema change. This is the change that
triggered the above simplification, as in order for the two dbscheme
files to be identical, the first `// generated` line had to state the
same generator script.
