Tests are not supposed to write outside of their working space, so dune
should not use a cache in the home directory: because of this, OCaml
tests currently fail when the Secure Control Plane is enabled. Disable
the Dune Cache to avoid this.
Introduce the testsuite `--with-langkit-python` option so that it is
possible to have:
* one interpreter with the e3 distribution (to run the testsuite),
* one interpreter with Langkit installed (to run lkm and the various
scripts using Langkit modules),
* one bare interpreter to import Langkit-generated libraries.
The upcoming revamp of Lkt modules will make it impossible to have
multiple Lkt source files share common declarations (`common_*.lkt`)
with bi-directional references: the individual sources can import
entities from the definite `common_*` modules, but the common modules
do not have a specific module for their own imports.
To overcome this, extend the `lkt_compile.py` script so that it
considers `test.lkt` sources in test subdirectories, and arrange for the
Lkt source path to make the top-level directory available: this will
allow test files to all have the same name (they will be in separate
directories), and so the common files will have a specific module name
to use for imports.
This is a requirement following making Lankit nodes, analysis units and
tokens Truffle objects (and depending at runtime on the 'truffle-api'
module).
Including 'truffle-api' in a shaded JAR breaks its compatibility with
the 'native-image' tool, causing tests to fail. We now package Java
bindings dependencies in the '<build_dir>/java/target/lib' directory.
This solution is currently the one used by the Langkit generic LSP and
LKQL JIT.
Now that the Python DSL is retired, it no longer makes any sense to call
`langkit.diagnostics.extract_location_from_traceback`, as no traceback
frame will even contain location information that is meaningful for the
DSL. Replace it with explicit `location` constructor arguments instead.
Remove the `lexer` and `grammar` arguments for `CompileCtx.__init__` as
well as the `types_from_lkt` config setting, and make the `lkt_spec`
config entry mandatory: all aspects of language specs now have to come
from Lkt source code.
For some commands, like "lkm setenv" or "lkm run", it is not possible to
determine whether direct access to C headers will be needed eventually,
so unconditionally give access to them. Since the only C header present
in the generated sources is the language-specific header, this should
not be a problem in practice.
This new command line tool has the same CLI as current manage.py
scripts, but automatically loads "langkit.yaml" files configurations, so
that language specs do not have to write Python code to subclass
ManageScript.
The root directory is always supposed to be inferred from the context
(where manage.py or langkit.yaml files are located): do not allow the
YAML configuration to initialize it.
Also rework lkt_compile and lkt_build_and_run test drivers so that the
language spec configuration bits are stored in the testcase's test.yaml
file directly: no need to add glue code in various places (test driver,
lkt_compile.py/lkt_build_and_run.py scripts) to support a new kind of
language spec configuration.
Replace the messy collection of arguments for CompileCtx.__init__ and
CompileCtx.create_all_passes with better organized dataclasses in the
new langkit.config module. Update the codebase to use these data
structures.
Add a --charset argument that the unparse main uses to decode the source
files to reformat, and to encode the reformatted content. Also enhance
the lkt_build_and_run driver so that it can run mains with heterogeneous
encodings (one that outputs UTF-8 and another that outputs ISO-8859-1,
for instance).
