Transition all relevant testcases to it. In the process, port
docstrings/comments from test.py files to expected_concrete_syntax.lkt
(now test.lkt) sources and fix stylechecks issues there.
(cherry picked from commit e1c4fe5804)
This makes the convention consistent with the DSL, and avoids
workarounds for conflicts with Lkt keywords: in Libadalang, the Null
token can stay Null, instead of null_tok (no API breakage needed).
That'll allow us to go from (thin_symbol, sym_table) to symbol, and vice
versa, where with the old representation there was no other way to go
from symbol to thin than redoing a full-lookup.
That'll help us transition to thin-symbol storage everywhere.
Future work on Lkt will use this compiled type so that properties can
return precisely located errors on string literals.
Note that the exposition of this new compiled type to the OCaml and Java
APIs is incomplete, and is deferred to future developments.
Merge the @external, @uses_envs and @uses_entity_info annotations into a
single one: @external(uses_envs=true, uses_entity_info=true). This makes
sense, as uses_envs and uses_entity_info are never legal for
non-external properties.
With the current low-tech approach to typing/validity checking for Lkt,
it is not possible to infer whether N designates a bare node type or an
entity type. Introduce a different syntax for entity types to avoid this
problem.
By default, make App instances print parsing errors for all requested
units on the standard output, and let subclasses override this behavior
if needed.
Also extend the Python playground so that parsing errors fit nicely into
the prompt header.
Add flushing close to places that deal with exceptions so that the order
of lines in the output reflect the order of execution for the
corresponding print statements.
The actual buffering behavior differs depending on the Python
interpreter version used, which led to spurious diffs with older
versions.
TN: W306-034
Depending on the Python interpreter version that is used to exercise
generated libraries, the line number, and thus the quoted line of source
code that is present in baselines can vary. Introduce an output refiner
to hide these discrepancies and use them in tests where it is relevant.
TN: W306-034
