feat: publish Dever core with project scaffolding and versioned AI skills
This commit is contained in:
Antigravity committed
1 parent
70fa73cdc2
commit
ac458ffa7f
960 files changed
+221319
-1163
No files matched your search
Whitespace-only changes.
Whitespace-only changes.
@@ -0,0 +1,72 @@
|
||||
# Dever 私有编译器与公开发行边界
|
||||
|
||||
## Goal
|
||||
|
||||
让用户只接触 Dever 语言、工具链和发行物，不接触或依赖 Rust/Cargo/rustc；Rust 仅作为私有仓库中的首代引导实现，不进入公开源码、安装流程、命令输出或用户运行环境。
|
||||
|
||||
## Background
|
||||
|
||||
- 当前 `/data/project/dever` 没有配置 Git 远端，Cargo workspace、Rust 源码、测试和 README 尚未提交，因此没有证据表明实现已经对外发布。
|
||||
- 当前仓库及 Git 历史包含 Rust 实现信息，不能直接转换为公开仓库。
|
||||
- 当前 `deverc run/build` 调用用户环境中的 `rustc`，并在临时目录生成 Rust 源码；这不符合对外隐藏实现和免 Rust 工具链的要求。
|
||||
- 二进制实现无法可靠抵抗专业逆向识别。本任务隐藏正常产品表面和源码实现，不承诺不可逆向。
|
||||
- 当前 Rust 编译器及计划使用的 LLVM 后端都有必须合规审查的第三方许可证；不能通过删除或伪造法定声明隐藏实现。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Repository Boundary
|
||||
|
||||
- 当前编译器仓库保持私有，不向公开仓库推送现有 Git 历史、Cargo 文件、Rust 源码或内部设计资料。
|
||||
- 对外发行使用一个没有当前仓库历史的新仓库或等价的独立公开渠道。
|
||||
- 公开内容只包含 Dever 用户需要的文档、`.dever` 示例、安装入口和构建后的发行物，不包含编译器实现源码。
|
||||
|
||||
### Product Surface
|
||||
|
||||
- 用户只使用正式的 `dever` 命令和 `.dever` 源码，不需要了解 Cargo、Rust、rustc 或内部生成语言。
|
||||
- 公开文档、安装器、帮助文本、普通诊断、日志和临时文件不得暴露 Rust/Cargo/rustc 实现细节。
|
||||
- `dever check/run/build` 不要求用户安装 Rust 工具链，也不得调用用户 PATH 中的 `rustc` 或 `cargo`。
|
||||
- `dever build` 生成的程序可独立运行，不依赖 Cargo、Rust 工具链或私有编译器源码。
|
||||
- 更换公开发行边界和原生后端不得改变已经确认的 `.dever` 表面语法、诊断位置或当前可执行语义。
|
||||
|
||||
### Native Backend
|
||||
|
||||
- Rust 可以继续用于私有编译器本身，但用户侧原生编译路径必须由随 `dever` 交付的内置后端完成。
|
||||
- 不采用“把 rustc 改名或静默捆绑”来满足隐藏要求；底层工具链不能作为可观察的用户侧子进程或安装前置条件。
|
||||
- 编译必须在用户本机离线完成，不上传 `.dever` 源码或中间表示，也不依赖远程构建节点。
|
||||
- 不采用云端编译来回避本地后端，因为这会额外引入源码上传、网络依赖和服务可用性边界。
|
||||
|
||||
### Initial Platform Boundary
|
||||
|
||||
- 首版支持 Linux、Windows 和 macOS；所有编译均在用户本机离线完成。
|
||||
- Linux、Windows 和 macOS 均提供 x86_64 与 ARM64 版 `dever`。
|
||||
- 任一受支持宿主上的 `dever build` 都必须能够离线生成 Linux、Windows 和 macOS 的 x86_64/ARM64 程序，形成 6 个宿主发行物到 6 个目标的完全对称矩阵。
|
||||
- 生成跨平台程序不能依赖远程构建节点或上传源码及中间表示。
|
||||
- 目标后端、链接能力和 Dever 平台运行时随发行物提供，不能要求用户另行安装目标平台编译器或 SDK。
|
||||
- `dever build` 为 macOS 目标生成平台运行所需的离线 ad-hoc 链接签名；它不代表开发者身份，也不能通过 Gatekeeper 分发验证。
|
||||
- Developer ID 身份签名和 Apple 公证是独立的可选发布阶段，不属于 `dever build`；Developer ID 安全时间戳和 Apple 公证均允许并必然需要联网。
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] 从一台没有 `cargo` 和 `rustc` 的目标机器安装公开发行物后，可以执行当前里程碑对应的 `dever check/run/build`。
|
||||
- [ ] 安装、帮助、正常运行、普通错误和构建临时目录中均不出现 Rust、Cargo、rustc 或 `.rs` 源码。
|
||||
- [ ] `dever build` 的输出是可独立运行的目标平台程序，并保持当前 `.dever` 示例的可观察行为。
|
||||
- [ ] 公开仓库或公开发行包不包含当前私有仓库的 Git 历史、Cargo metadata、Rust 源码或私有 Trellis 资料。
|
||||
- [ ] 自动检查能够证明公开构建路径没有启动 `cargo` 或 `rustc`，并覆盖没有 Rust 工具链的干净环境。
|
||||
- [ ] 断网且未安装 Windows 编译工具链的 Linux 环境可以生成 Windows 程序，并在真实 Windows 环境验证其行为。
|
||||
- [ ] 断网且未安装 Xcode 或 Apple SDK 的受支持环境可以生成 macOS 程序，并在真实 Intel Mac 和 Apple Silicon Mac 上验证其行为。
|
||||
- [ ] 六个宿主发行物分别能够生成六个目标程序，36 种宿主到目标组合使用同一命令合同并通过确定性产物检查；每个目标程序均在对应真实系统与架构上执行验证。
|
||||
- [ ] macOS ARM64 产物包含可离线生成的有效 ad-hoc 链接签名；编译不访问开发者身份或公证服务。
|
||||
- [ ] 单独的发布流程明确区分 ad-hoc 链接签名、需要联网安全时间戳的 Developer ID 身份签名和需要联网的 Apple 公证。
|
||||
- [ ] 私有仓库仍可维护和验证 Rust 引导编译器，公开边界不迫使内部源码改名或制造重复实现。
|
||||
|
||||
## Out Of Scope
|
||||
|
||||
- 阻止专业人员通过反汇编、二进制指纹或运行时特征推断实现语言。
|
||||
- 为隐藏实现而混淆、加壳或伪造二进制来源。
|
||||
- 在本任务中实现 HTTP、JSON、数据库、CRUD 或完整 Dever 语言路线。
|
||||
- 公开编译器源代码或建立外部贡献者的编译器开发环境。
|
||||
- 在 `dever build` 中管理用户的 Developer ID 凭据、执行身份签名或隐式提交 Apple 公证。
|
||||
|
||||
## Open Question
|
||||
|
||||
- 是否允许依法必须提供的第三方许可证清单提及 Rust；如果不允许，则 Rust 引导编译器只能作为私有 seed，Dever 自举编译器必须成为首次公开发行的前置条件？
|
||||
@@ -0,0 +1,35 @@
|
||||
# Linux Host Cross-Compilation
|
||||
|
||||
## Confirmed Toolchain Facts
|
||||
|
||||
- LLVM is designed as a cross-compiler, but target code generation alone is insufficient. A complete build also needs target-specific headers, libraries, linker behavior and usually a sysroot: <https://clang.llvm.org/docs/CrossCompilation.html>.
|
||||
- LLD supports ELF, Windows PE/COFF and macOS Mach-O. Its PE/COFF port is described as complete; Mach-O support exists but is listed after ELF and PE/COFF in completeness: <https://lld.llvm.org/>.
|
||||
- Microsoft publishes the PE/COFF executable and object format specification, so a Linux-hosted backend can produce Windows artifacts without invoking a Windows compiler: <https://learn.microsoft.com/en-us/windows/win32/debug/pe-format>.
|
||||
- Apple's documented universal-binary workflow requires Xcode on a Mac and uses Apple target tooling. Distributed macOS software also has Developer ID signing and notarization requirements: <https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary> and <https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution>.
|
||||
- Apple exposes a Notary REST API, so submission need not use `notarytool`, but this does not remove SDK, linking, signing or real-device validation concerns: <https://developer.apple.com/documentation/NotaryAPI>.
|
||||
|
||||
## Product Consequences
|
||||
|
||||
### Linux to Windows
|
||||
|
||||
This is a practical offline target. A target-neutral Dever frontend can feed an embedded native backend, then a PE/COFF linker can combine generated code with a versioned Dever Windows runtime and required import libraries. The resulting `.exe` still needs validation on real x86_64 and ARM64 Windows systems.
|
||||
|
||||
### Linux to macOS
|
||||
|
||||
Generating x86_64 or ARM64 instructions and a Mach-O file on Linux is technically possible. Treating that file as a supported macOS product is harder: platform libraries, minimum OS versions, Mach-O signing details, Developer ID distribution, notarization and testing remain Apple-platform concerns. Redistributing an Apple SDK inside the Linux compiler also introduces a licensing boundary and must not be assumed acceptable.
|
||||
|
||||
For the current Text/println subset, a self-contained Dever runtime and purpose-built Mach-O path could avoid most SDK use. That shortcut does not establish a maintainable path for the planned HTTP, TLS, files, database and other system integrations.
|
||||
|
||||
Local compilation and public distribution are separate contracts. Once the target backend and versioned Dever macOS runtime are installed, `dever build` can remain offline. Apple Silicon requires every executable to be signed, so the linker must create an identity-free ad-hoc signature as part of offline output: <https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-universal-apps-release-notes>. Developer ID distribution signing requires the developer's identity and an online secure timestamp: <https://developer.apple.com/documentation/technotes/tn3161-inside-code-signing-certificates>. Apple's notarization service then requires uploading the signed artifact. Apple exposes a REST API for non-macOS notarization clients, but the service is necessarily online: <https://developer.apple.com/documentation/NotaryAPI>.
|
||||
|
||||
## Recommended Boundary
|
||||
|
||||
- Keep parsing, checking, HIR and target selection shared.
|
||||
- Support offline Linux-to-Windows cross-build as a normal target once the embedded backend exists.
|
||||
- Keep all first-release compilation local and offline; do not transfer source or intermediate representations to a build service.
|
||||
- Include macOS as an offline compilation target without introducing controlled Mac build infrastructure. Treat Developer ID signing and Apple notarization as separate optional publishing stages, and require real Intel and Apple Silicon validation for supported Mach-O output.
|
||||
- Implement each target through small ABI/runtime/object-format adapters rather than duplicating compiler flows.
|
||||
|
||||
## Open Product Decision
|
||||
|
||||
Resolved: the first release uses a fully symmetric Linux, Windows and macOS x86_64/ARM64 host-to-target matrix. Six host distributions must each produce all six targets locally and offline.
|
||||
@@ -0,0 +1,23 @@
|
||||
# Distribution Licensing And Implementation Disclosure
|
||||
|
||||
## Confirmed Facts
|
||||
|
||||
- The Rust project and standard library are distributed under `MIT OR Apache-2.0`: <https://rust-lang.org/policies/licenses/> and <https://github.com/rust-lang/rust/blob/main/COPYRIGHT>.
|
||||
- A public compiler binary built from the current Rust implementation can contain Rust standard-library code. Its exact notice obligations require a release-license audit; the project must not assume that deleting all Rust attribution is permitted.
|
||||
- LLVM is `Apache-2.0 WITH LLVM-exception`. LLVM states that binaries including LLVM must reproduce its copyright notice, while permitting closed-source and commercial use: <https://llvm.org/docs/DeveloperPolicy.html#copyright-license-and-patents>.
|
||||
- Apple licenses prohibit separately using Apple SDKs or running Apple Software on non-Apple-branded hardware, and generally prohibit redistributing Apple Software in whole or part without permission: <https://www.apple.com/legal/sla/docs/xcode.pdf>.
|
||||
|
||||
## Consequences
|
||||
|
||||
Hiding Cargo files, symbols and implementation-specific diagnostics is a product-surface concern. Required third-party notices are a separate compliance concern and must remain truthful.
|
||||
|
||||
There are two viable disclosure boundaries:
|
||||
|
||||
1. Ship the Rust bootstrap compiler initially. Normal product surfaces mention only Dever, but a compliant third-party notice may identify Rust and LLVM. Professional binary identification is already outside the task scope.
|
||||
2. Never ship the Rust bootstrap compiler publicly. Use it only as the private stage-1 seed, complete enough Dever language and runtime capabilities to build a stage-2 compiler, and publicly distribute the verified stage-2/stage-3 Dever compiler. LLVM attribution can remain if LLVM is embedded, but Rust is absent from the public executable and notices.
|
||||
|
||||
The second boundary matches a strict “no public Rust trace” requirement but makes self-hosting a release prerequisite rather than a later roadmap item. It materially expands the first public release.
|
||||
|
||||
## Rule
|
||||
|
||||
Do not use renamed tools, stripped license files, misleading notices, obfuscation or packaging tricks as a substitute for the chosen disclosure boundary.
|
||||
+104
@@ -0,0 +1,104 @@
|
||||
# Native Backend Options
|
||||
|
||||
## Required Properties
|
||||
|
||||
- Consume checked Dever HIR without changing `.dever` syntax or semantics.
|
||||
- Generate x86_64 and ARM64 ELF, PE/COFF and Mach-O on every supported host.
|
||||
- Run fully offline without Cargo, rustc, a target SDK or a remote build service.
|
||||
- Preserve direct native calls, concrete value layouts and the existing native performance direction.
|
||||
- Keep generated IR, objects and link details private, owned temporary artifacts.
|
||||
- Avoid six target-specific compiler implementations.
|
||||
|
||||
## Options
|
||||
|
||||
| Option | Strengths | Blocking weaknesses | Decision |
|
||||
| --- | --- | --- | --- |
|
||||
| Pinned LLVM code generation plus LLD | Mature optimization; x86_64/ARM64; ELF, PE/COFF and Mach-O; supports in-process use | Large host binaries, native integration boundary, mandatory LLVM notices, target runtimes still required | Recommended |
|
||||
| Cranelift plus LLD | Safe Rust-facing library, fast compilation, x86_64/ARM64 | Still needs a cross-format linker and target runtimes; optimization quality creates risk against the native performance contract | Keep as fallback only if measured LLVM integration cost is unacceptable |
|
||||
| Custom machine-code and executable writers | Full control and small artifacts for the current subset | Reimplements two ISAs, three formats, relocation, unwind and linking; duplicates platform logic and does not scale to the language roadmap | Reject |
|
||||
| WebAssembly or a bytecode VM inside native launchers | Simple portable execution model | Changes the AOT/runtime architecture, adds a production VM and jeopardizes native performance requirements | Reject for production build/run |
|
||||
| Generated Rust plus bundled or renamed rustc | Reuses current implementation | Exposes the forbidden toolchain, produces Rust temporary source and makes offline target support depend on Rust sysroots/linkers | Replace completely |
|
||||
|
||||
LLVM's cross-compilation documentation still requires target-specific sysroots/libraries beyond machine-code generation: <https://clang.llvm.org/docs/CrossCompilation.html>. LLD supports the three required executable formats and can be embedded for compiler-owned trusted objects: <https://lld.llvm.org/> and <https://lld.llvm.org/NewLLD.html>.
|
||||
|
||||
## Proposed Ownership
|
||||
|
||||
```text
|
||||
dever-core
|
||||
checked, target-neutral HIR and source diagnostics
|
||||
|
||||
dever-native
|
||||
fixed target catalog
|
||||
HIR -> LLVM lowering
|
||||
object emission
|
||||
LLD integration
|
||||
target-pack selection
|
||||
owned temporary artifacts
|
||||
|
||||
dever-runtime
|
||||
Dever-owned ABI and runtime behavior
|
||||
six release-built target packs
|
||||
|
||||
dever-cli
|
||||
--target parsing, host/default selection, output and process adaptation
|
||||
```
|
||||
|
||||
`dever-native` is one justified private workspace boundary: it isolates the large native dependency and target mechanics from parsing/checking. It is not a public backend plugin API. Target variation uses one explicit catalog and small data/config adapters, not inheritance or a registry.
|
||||
|
||||
## Build Data Flow
|
||||
|
||||
```text
|
||||
.dever -> check -> typed HIR -> specialize reachable program
|
||||
-> shared LLVM lowering -> target object in memory
|
||||
-> fixed target specification + versioned Dever runtime pack
|
||||
-> embedded LLD driver -> new executable output
|
||||
```
|
||||
|
||||
- LLVM IR and object files are never public output formats.
|
||||
- `dever build` creates a new output and keeps the current no-overwrite contract.
|
||||
- `dever run` always builds the host target and runs it; cross-target execution/emulation is not added.
|
||||
- A cross-target `build` only generates an artifact. Real target runners validate it in release CI.
|
||||
|
||||
## Target Catalog
|
||||
|
||||
The public catalog has exactly six initial targets:
|
||||
|
||||
```text
|
||||
linux-x86_64
|
||||
linux-arm64
|
||||
windows-x86_64
|
||||
windows-arm64
|
||||
macos-x86_64
|
||||
macos-arm64
|
||||
```
|
||||
|
||||
Each target definition owns its LLVM triple, CPU baseline, object format, calling convention, executable suffix, runtime pack and deterministic linker settings. Shared OS and architecture helpers remove repetition; target entries remain explicit and reviewable.
|
||||
|
||||
## Runtime Packs
|
||||
|
||||
Generated code must use a Dever-owned ABI rather than Rust's unstable ABI or Rust `String` layout. Each target pack contains only Dever-owned startup/runtime objects and permitted platform import metadata. It must not contain Rust standard-library objects, Apple SDK files or target compiler binaries.
|
||||
|
||||
The current `dever-runtime` source is a behavior reference, not a stable native ABI. The first backend milestone defines the minimal Text slice, result/fault and `println` ABI once, then supplies six compiled implementations or target-specific adapters behind that contract. Future collections, numbers, HTTP, TLS and storage extend this ABI deliberately rather than reaching into host-language layouts.
|
||||
|
||||
## Determinism And Matrix Verification
|
||||
|
||||
- Pin one LLVM/LLD source revision and runtime-pack version for all six host builds.
|
||||
- Remove timestamps, absolute build paths, random UUID inputs and host-dependent ordering.
|
||||
- Each of six host compilers builds all six targets, producing 36 artifacts.
|
||||
- Artifacts for the same target and source should be byte-identical across hosts. Hash equality reduces execution validation to one artifact per target; all six target artifacts still run on real matching systems.
|
||||
- Offline checks deny network access and remove Cargo, rustc, Xcode, Visual Studio, GCC and target SDKs from PATH.
|
||||
|
||||
## Release And License Gates
|
||||
|
||||
- LLVM permits proprietary distribution but requires its copyright notice in binaries that include it: <https://llvm.org/docs/DeveloperPolicy.html#copyright-license-and-patents>.
|
||||
- No Apple SDK file may enter a target pack. Apple's agreement prohibits separately using SDKs on non-Apple hardware and redistributing Apple Software in part: <https://www.apple.com/legal/sla/docs/xcode.pdf>.
|
||||
- Before implementation commits to the macOS target, prove that both Mach-O targets can link the minimal Dever runtime without redistributed Apple SDK material and pass real-machine execution.
|
||||
- The public-compiler Rust attribution decision in `distribution-licensing.md` remains a product gate.
|
||||
|
||||
## Rejected Shortcuts
|
||||
|
||||
- Do not rename or conceal rustc, Cargo, LLD or license files.
|
||||
- Do not special-case the hello example or patch prebuilt executable templates.
|
||||
- Do not implement one backend per OS.
|
||||
- Do not upload source or HIR when local target support is missing.
|
||||
- Do not silently fall back to a VM, host execution or another target.
|
||||
@@ -0,0 +1,28 @@
|
||||
{
|
||||
"id": "private-compiler-distribution",
|
||||
"name": "private-compiler-distribution",
|
||||
"title": "Dever 私有编译器与公开发行边界",
|
||||
"description": "隐藏 Rust 引导实现并建立不依赖 Rust 工具链的公开发行路径",
|
||||
"status": "planning",
|
||||
"dev_type": null,
|
||||
"scope": null,
|
||||
"package": null,
|
||||
"priority": "P2",
|
||||
"creator": "Antigravity",
|
||||
"assignee": "Antigravity",
|
||||
"createdAt": "2026-09-06",
|
||||
"completedAt": null,
|
||||
"branch": null,
|
||||
"base_branch": "main",
|
||||
"worktree_path": null,
|
||||
"commit": null,
|
||||
"pr_url": null,
|
||||
"subtasks": [],
|
||||
"children": [
|
||||
"09-28-shared-toolchain"
|
||||
],
|
||||
"parent": null,
|
||||
"relatedFiles": [],
|
||||
"notes": "",
|
||||
"meta": {}
|
||||
}
|
||||
Reference in new issue
Block a user