mirror of
https://github.com/CatalaLang/catala.git
synced 2024-11-08 07:51:43 +03:00
b9156bb60e
Previously we had some heuristics in the backends trying to achieve this with a lot of holes ; this should be much more solid, relying on `Bindlib` to do the correct renamings. **Note1**: it's not plugged into the backends other than OCaml at the moment. **Note2**: the related, obsolete heuristics haven't been cleaned out yet **Note3**: we conservatively suppose a single namespace at the moment. This is required for e.g. Python, but it forces vars named like struct fields to be renamed, which is more verbose in e.g. OCaml. The renaming engine could be improved to support different namespaces, with a way to select how to route the different kinds of identifiers into them. Similarly, customisation for what needs to be uppercase or lowercase is not available yet. **Note4**: besides excluding keywords, we should also be careful to exclude (or namespace): - the idents used in the runtime (e.g. `o_add_int_int`) - the dynamically generated idents (e.g. `embed_*`) **Note5**: module names themselves aren't handled yet. The reason is that they must be discoverable by the user, and even need to match the filenames, etc. In other words, imagine that `Mod` is a keyword in the target language. You can't rename a module called `Mod` to `Mod1` without knowing the whole module context, because that would destroy the mapping for a module already called `Mod1`. A reliable solution would be to translate all module names to e.g. `CatalaModule_*`, which we can assume will never conflict with any built-in, and forbid idents starting with that prefix. We may also want to restrict their names to ASCII ? Currently we use a projection, but what if I have two modules called `Là` and `La` ? |
||
|---|---|---|
| .. | ||
| arithmetic | ||
| array | ||
| backends | ||
| bool | ||
| date | ||
| dec/good | ||
| default | ||
| enum | ||
| exception | ||
| func | ||
| io | ||
| literate/good | ||
| metadata/good | ||
| modules | ||
| money | ||
| monomorphisation | ||
| name_resolution | ||
| parsing/bad | ||
| proof | ||
| scope | ||
| struct | ||
| tuples/good | ||
| typing | ||
| variable_state | ||
| .ocamlformat | ||
| README.md | ||
Catala test suite
This folder contains Catala source files designed to test the features of the language.
Tests are declared inside plain Catala files with the following format:
```catala-test-inline
$ catala ARGS
... output from the catala command ...
```
In addition to the normal Catala commands, you can write catala test-scope SCOPE.
This will behave like catala Interpret -s SCOPE, but allows to further
customise the flags applied to it (so that the same test can be used to check
with optimisations enabled or disabled, with the lcalc interpreter, and so on)
Workflow for adding new tests
- Create a new test file in
foo/{good,bad}/bar.catala_<language>(pick the right directory and an informative name for your test) - Write your test, and pick a toplevel scope
Ato run. - Add the following section to your file:
```catala-test-inline $ catala test-scope A ``` - Run
clerk test tests/foo/{good,bad}/bar.catala_<language> --resetfrom the root of the Catala repository. This will update the test with the actual output of the catala command. - Don't forget to
git addthe test file.
Workflow for fixing regressions
- Run
clerk testfrom the root of the Catala repository, if a test fails you should see something likeFAILED: foo/{good,bad}/bar.catala_<language>followed by the diff between the expected output and the current output of the command. - Debug the compiler and the test and repeat. Run
clerk test tests/foo/{good,bad}/bar.catala_<language>to check the test again. - When you're finished debugging, if you are positive that a change in the test
output is legitimate, record the new outputs with
clerk test tests/foo/{good,bad}/bar.catala_<language> --reset. - Re-run
make testsfrom the root of the Catala repository to check that everything passes. - Run
git diffto double-check your changes to the test outputs are expected. If necessary, justify them in your commit message.
If a compiler change causes a lot of regressions (error message formatting changes
for instance), you can mass-reset the expected outputs with
clerk test --reset.
git diff will then allow to check all the changes at once.
Caution: It's your responsability to check all the changes before committing them.
Tips
-
Running a single test-file just to check changes when tweaking either the compiler or the test file itself, but without updating or diffing with the reference can be useful when debugging. The following command outputs the result to
stdoutand can be used from within text editors:clerk runtest test-file.catala_en # Or, to use the current build artefacts, wrap with `dune exec`: dune exec -- clerk runtest test-file.catala_en