laminaria-rust-nim-toolchain

LAMINARIA (Rust Nim Unified Toolchain) est un projet de recherche et développement explorant un modèle computationnel et une chaîne d'outils unifiés pour Rust et Nim. Plutôt que de traiter Cargo, rustc, Nimble, Nim, LLVM, LTO, les linkers et l'outillage WebAssembly comme des commandes opaques collées par un script de build externe, il décompose le chemin de la source à l'exécutable en un graphe d'actions explicite : Source Graph → Compiler Pipeline → Unified Program Graph → Variant / Artifact Graph → Backend Pipeline Graph → Action Graph → Nim Planning Kernel → Rust Runtime Scheduler Le projet étudie les étapes du compilateur Rust telles que HIR, MIR, la monomorphisation, les unités de codegen, rustc_codegen_ssa, les backends LLVM, Cranelift et GCC, LTO, la génération d'objets et le linking, parallèlement au frontend Nim, au traitement sémantique, à la génération de code backend, à la compilation native et au linking. LLVM est traité comme une route de génération de code sélectionnable parmi plusieurs plutôt que comme un fondement fixe, et WebAssembly est modélisé comme un pipeline cible (génération de code, wasm-ld, optimisation post-link, WIT/adapters, componentization) plutôt que comme une valeur de backend. La version du compilateur est gérée comme une dimension de graphe de premier ordre. La conception vise à supporter plusieurs toolchains Rust exactes ainsi que Nim 2 et Nim 3/Nimony, résolvant les contraintes de packages et de workspaces vers une toolchain sélectionnée tout en préservant l'identité du compilateur producteur dans les décisions d'exécution, d'action, d'artéfact, de cache et de compatibilité. Parce que l'espace des variantes internes peut être vaste, le projet met l'accent sur des Validated Toolchain Profiles basés sur des preuves, tels que recommended, latest-validated, long-term et preview, avec des alias de profil résolvant vers des révisions de bundles immuables et exactes, ainsi que des préréglages d'intention et des contraintes de graphe expertes. L'utilisabilité de l'outil est elle-même définie comme un objectif du projet : le chemin normal prévu est d'abord la résolution et l'élagage des contraintes, suivis d'un petit ensemble classé de plans viables basés sur des preuves, puis l'exécution, les incompatibilités connues étant conservées comme connaissances négatives structurées afin que des échecs équivalents n'aient pas à être redécouverts. L'exploration brute et large est destinée à rester un mode de recherche explicite plutôt que l'expérience par défaut. Architecturalement, la division se fait par responsabilité plutôt que par langage : un Nim Planning Kernel gère la normalisation du graphe, la résolution de contraintes, la résolution combinatoire, la propagation de la demande d'artéfacts, l'élagage et l'analyse du chemin critique, tandis qu'un Rust Runtime Scheduler gère le CLI, la découverte de toolchains, l'interaction avec l'OS, l'exécution des processus, la comptabilité des ressources, le cache/CAS, les services de démon, la mesure, le traçage et l'ordonnancement. Ce qui existe aujourd'hui dans le dépôt est la couche d'identité de l'environnement et de la toolchain. Un verrou multi-toolchain appartenant au dépôt (toolchains.lock.toml) est résolu par une commande doctor en enregistrements EnvironmentFingerprint et ToolchainFingerprint exacts : scripts/bootstrap.sh signale les outils manquants par rapport au fichier lock ; --install les installe également (macOS/Homebrew plus rustup). Le script de bootstrap préfère des sources exactes, hors gestionnaire de paquets système lorsque possible (toolchains rustup avec llvm-tools, choosenim pour des versions exactes de Nim, cargo install --version pour les outils CLI purement Rust), ne revenant à un gestionnaire de paquets système que pour les outils sans alternative, tels que clang/llvm-config et wasm-opt de Binaryen. cargo run -p laminaria-cli -- doctor imprime un rapport d'environnement lisible par l'homme, et --json émet les fingerprints lisibles par machine. Un docker/bootstrap.Dockerfile exécute la même pile dans un conteneur pour des vérifications de bootstrap reproductibles ; selon la documentation de mesure, ceci est uniquement pour la reproduction de la correction, et doctor enregistre environment_class = "container" afin que les exécutions en conteneur ne soient pas silencieusement comparées aux baselines natives. La documentation est fournie en anglais et en japonais, couvrant l'UX de toolchain orientée agent et la planification bornée, les profils de toolchain validés et la configuration progressive, la politique multi-version des toolchains Rust/Nim, le fondement de la mesure et la stratégie d'environnement/trace, l'ouverture du pipeline backend, les fondements de la recherche, le programme de recherche et la politique de preuve, le linking natif Rust–Nim, la politique de recherche axée sur les métriques, un plan d'issues et une proposition de projet. La licence est double : Apache License 2.0 ou MIT, au choix de l'utilisateur, les composants tiers restant sous leurs propres licences. Le README présente le travail comme un programme de recherche établissant une colonne vertébrale de mesure avant l'optimisation, donc les revendications de capacités ici reflètent l'intention de conception et l'outillage d'identité d'environnement actuellement commis plutôt que des performances de build vérifiées.