TrustLang - A Trusted Programming Language

Rework of the project's code base with a name change (NewLang -> TrustLang).

TrustLang is a high-level general-purpose programming language for safe (trusted) development. It is implemented as a transpiler to C++, providing safe memory management without a garbage collector and detecting memory management errors and data race conditions at compile time.

The TrustLang supports tensor computations (LibTorch), rational numbers with unlimited precision, static and dynamic typing, and named and optional function parameters. It also provides one-dimensional arrays via literals [1,2,3,] / [...]:Type (→ std::vector<Elem>), index access a[i], the :Array(...) constructor, and array methods (count, at, first, push_back, ...); multi-dimensional arrays (tensors) are reserved for the LibTorch backend.

It supports deep integration with the C/C++ ecosystem, including direct function calls, C++ code embedding, and use of the C++ standard library.

The project is under active development and is developed with the help of AI agents.

Testing

Tests are registered with CTest and run via:

cmake -B _build && cmake --build _build
ctest --test-dir _build --output-on-failure   # all tests

Test layout:

• unit/ - C++ unit tests (test/unit/), a single unit_tests executable registered as one CTest test; ctest --output-on-failure prints the full GTest report (with failing test names) when the suite fails.
• lit/ - LIT integration tests (test/lit/), registered as the lit_tests CTest test (run through the trust CLI + FileCheck).
• vscode/ - VSCode extension tests (test/vscode/), registered as vscode_unit, vscode_dap and vscode_lsp CTest tests.

make run_tests (alias cmake --build _build --target run_tests) builds the test binaries (unit_tests, trust, trust-dap, trust-lsp) and then runs the same CTest suite.

Runtime linking (--link-runtime)

Runtime-backed types (e.g. Rational) need the trust runtime library, which is built both as a dynamic library (trust-runtime.so) and a static one (trust-runtime.a). When compiling an executable, the pipeline links the runtime according to --link-runtime (default static):

• static - the runtime code is linked into the executable from trust-runtime.a; the resulting binary is self-contained and runs without trust-runtime.so.
• shared - the executable links trust-runtime.so dynamically and resolves it at run time via LD_LIBRARY_PATH / the launch directory.

Diagnostics options (-W<name>[=status])

Severity-options control compile-time diagnostics (status: ignore/warning/error/fatal):

• -Wembed=ignore - silence the warning about the very fact that a {% ... %} C++ embed block is used (independent of the names inside; default warning).
• -Wsigil=ignore - silence the warning about normalizing a simple local variable declared without the $ sigil into a local $x (default warning).
• -Wformat=ignore|warning|error - controls compile-time type checking of arguments against a printf format string for native functions marked with @[format("printf", ...)] (default error).

Generated C++ files

Every generated .cppt (and the _main.cppt entry file) starts with an autogenerated header (first line: project name, full compiler version, and generation date/time). The LICENSE file is copied into the build directory next to the generated Makefile/build.conf (the license text itself is not embedded into the generated C++ files).

Building a distribution archive

The package target produces a gzipped tar archive for installation/distribution:

cmake --build _build --target package

The archive is also built automatically as part of the default build (cmake --build _build) - independently of running the tests (test binaries and ctest are not required). The archive (and the .vsix package, when built) are placed in a dedicated _build/dist/ directory. The archive name encodes the build attributes:

trust-lang-<version>-<git-hash>-<os>-<arch>.tar.gz

where <os> derives from CMAKE_SYSTEM_NAME (e.g. linux) and <arch> from CMAKE_SYSTEM_PROCESSOR (e.g. x86_64). The archive contains the compiler (trust), the language servers (trust-lsp, trust-dap), the runtime libraries (trust-runtime.so and trust-runtime.a), VERSION/LICENSE, and a manifest.txt with the build metadata (version, git hash, OS, arch, date). The public runtime headers and the stdlib sources are not copied separately: their contents are embedded into the runtime libraries / the compiler and stay version-synced with them.

Because the toolchain (clang-22, LLVM, GMP, bison/flex, lit) and the pipeline are POSIX/ELF-based, the recommended way to build on a Windows host is WSL2, where the environment is a native Linux and the archive is produced as a linux-<arch> package. A fully native Windows build requires separating the embedded-header storage from ELF sections and replacing the make-based pipeline - a separate task.