So far, properties were allowed to raise Property_Error exceptions only:
other exceptions were considered as a low-level bug (i.e. assumed not
possible), which could corrupt the process state.
This commits allows language specs to allow additional kinds of
exceptions to be raised in property errors.
For #632
All tests which just check the presence/absence of errors when compiling
Lkt language specs have the same "test.py" script: put a reference
script in "python_support", create a new test driver to let tests use
it easily and migrate relevant tests to it.
For GitHub issue #622
When running all tests, restrict each test to a single core, otherwise
we end up running spamming the host with N*N subprocesses despite
--jobs=N passed to the testsuite. However, keep inner parallelism to N
when running few tests, for dev convenience.
The previous commit for this ticket added a Valgrind suppression file
assuming that the testsuite would automatically pick it up. It is not
the case, so explicitly use gnat.supp in tests when running Ada
programs.
TN: V221-024
We happen to use short name only in its lower case form. Switch to the
lower case form only to avoid breaking the "one word, starting upper
case" rule (for instance with LAL for Libadalang).
TN: V126-009
Remove errors from test material when they are not the errors that are
meant to be checked. An upcoming change will make these extra errors
visible: we do not want them to hide the ones meant to be checked.
TN: RA22-015
Now that cross-unit links between lexical envs are handled by the named
environments mechanism, we can get rid of this unsoundness without
breaking Libadalang.
TN: T320-010
Python's -O command-line option disableds the execution of "assert"
statements. In order for the generated Python bindings to work in such a
mode, we need to keep assertion logic only in "assert" statements. This
commit fixes statements that currently don't respect this principle.
Fixes GitHub issue #485
TN: U326-020
When enabled, this new option triggers the lexer engine to perform
"native" case insentivity and provides a default symbol canonicalizer
that just converts names to lower case.
TN: U118-054
The automatic trigger of PLE when synthetizing a node, while necessary
to get sound environments, creates nasty regressions in Libadalang,
which does not use the sound environment framework yet. Introduce a
switch that triggers the new behavior, and whose absence leaves the old
(and incorrect) behavior. This will allow us to continue working on
sound envs without creating regressions in LAL.
TN: TB19-017
As well as command line arguments to list/activate/deactivate them.
This will be useful for the railroad diagram pass, and can be
potentially reused for other optional passes.
Most importantly, this changes the parsing of common command line
options/flags, so that they must be passed *after* the subcommand. For
instance:
./manage.py --library-types=static make --no-gdb-hook
becomes:
./manage.py make --library-types=static --no-gdb-hook
Having some options before the subcommand and the others after have been
a serious source of confusion for both users and developpers.
This change also reorganizes subparser initialization code to reduce
code duplication in ManageScript derivations: dedicated
overridable "add_extra_subcommands" method (instead of the generic
__init__ override) and reusable "add_subbcommand" method (to create a
subcommand parser with the expected name, description and callback.
Finally, this makes it possible for some subcommands to accept unknown
arguments.
TN: T914-012
So far, ManageScript assumed that the lang_source_dir is the directory
that contains the Python source file which defines the ManageScript
subclass. This is wrong for testcases, as there is generally only one
ManageScript subclass, in the testsute/python_support/utils.py source
file.
Introduce a new "root_dir" ManageScript constructor argument to override
this behavior, and use it in the testsuite appropriately.
TN: T914-010
This commit stops considering Langkit_Support as a generated project:
* move the "langkit/support" directory to "support" (not
"langkit_support" for convenience with tab-completion);
* move the meat of the "langkit_support_gpr.mako" template to the static
"langkit_support.gpr" file, and remove the template;
* remove the "build-langkit_support.py" script and all the corresponding
libmanage.py/langkit_support.py code;
* enhance the top-level "manage.py" script to build/setenv
Langkit_Support and import the packaging tools from
"build-langkit_support.py".
From now on, Langkit_Support is a really a standalone library project,
and thus a "real" dependency for Langkit-generated libraries.
TN: T914-012