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
@@ -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.
|
||||
Reference in new issue
Block a user