Merge origin/main (0.7.1) into the #622 branch; the collection becomes 0.8.0

Author: Sunrisepeak

.github/workflows/ci.yml

@@ -894,7 +894,16 @@ jobs:
         run: |
           "$MCPP" build
           "$MCPP" run | tee run.log
-          grep -q '^scale.slang: magic=07230203' run.log
+          # TWO SHADERS, AND THE ENTRY POINT'S NAME IS THE MEASUREMENT.
+          #
+          # `-fvk-use-entrypoint-name` reaches slangc through
+          # `options::extra_args` and makes the module carry the function's
+          # name instead of `main`; `-DOFFSET_ENTRY` reaches ONE shader through
+          # `options::per_file` and switches its name again. The consumer reads
+          # both names out of the SPIR-V bytes, and `scale.slang` would report
+          # `wrongMain` if the per-file macro had leaked to it.
+          grep -q '^scale.slang: magic=07230203 .* entry=computeMain ok' run.log
+          grep -q '^offset.slang: magic=07230203 .* entry=offsetMainDefined ok' run.log
           grep -q '^all ok' run.log
           if grep -rn 'scale\.h\|\.inc"' src/; then
             echo "FAIL: a consumer source names a generated file"
@@ -904,6 +913,51 @@ jobs:
             target/.build-mcpp/out/slang/slang_consumer.shaders.cppm
           echo "ok: a Slang shader reached through the same surface as a GLSL one"
 
+      # THE NEGATIVE LEG. A `per_file` key that names no shader must refuse the
+      # build and list what it could have named; a rule that applied nothing
+      # and built anyway would hand the project a module it believes carries
+      # the option. Without this half the table could silently become a no-op
+      # and every positive assertion above would still pass.
+      - name: rules-slang refuses a per_file key that names no shader
+        working-directory: tests/slang-consumer
+        run: |
+          cp build.mcpp /tmp/build.mcpp.bak
+          sed -i 's|shaders/offset.slang|shaders/offest.slang|' build.mcpp
+          if "$MCPP" build > refused.log 2>&1; then
+            cp /tmp/build.mcpp.bak build.mcpp
+            echo "FAIL: a mistyped per_file key built anyway"; cat refused.log; exit 1
+          fi
+          cp /tmp/build.mcpp.bak build.mcpp
+          grep -q 'per_file. names .shaders/offest.slang., and no shader' refused.log
+          grep -q '^    shaders/offset.slang' refused.log
+          echo "ok: refused by name, and the shaders it could have named were listed"
+
+      # THE THIRD STORAGE, FOR SLANG. `options::storage` is new in 0.7.0; before
+      # it the rule embedded unconditionally. The consumer's source is the one
+      # `slang-consumer` has minus the per-file assertions, and the reverse leg
+      # is the point of the storage, as `spirv-sidecar` records.
+      - name: rules-slang with sidecar storage
+        working-directory: tests/slang-sidecar
+        run: |
+          "$MCPP" build
+          "$MCPP" run | tee run.log
+          grep -q '^magic=07230203' run.log
+          grep -q '^all ok' run.log
+          test -f target/.build-mcpp/out/slang/scale.spv
+          if grep -q 'source-embed' target/*/*/build.ninja; then
+            echo "FAIL: sidecar storage still asked slangc to embed"; exit 1
+          fi
+          bin=$(ls target/*/*/bin/slang-sidecar)
+          bin=$(cd "$(dirname "$bin")" && pwd)/$(basename "$bin")
+          if (cd /tmp && "$bin" > away.log 2>&1); then
+            echo "FAIL: the sidecar program succeeded from the wrong directory"
+            cat /tmp/away.log
+            exit 1
+          fi
+          grep -q 'sidecar payload was not found' /tmp/away.log \
+            || { echo "FAIL: it failed for some other reason"; cat /tmp/away.log; exit 1; }
+          echo "ok: a Slang payload found from the package root, reported missing from elsewhere"
+
       # A tool, not a rule: the header is written while the build program runs,
       # so there is no action to schedule. The second build is the measurement
       # that matters -- editing the data file must reach the binary, which is

README.md

@@ -6,7 +6,7 @@ imports each one from `build.mcpp` under the module name the member declares.
 
 ```toml
 [build-dependencies.mcpp]
-plugins = { version = "0.7.0", features = ["rules-spirv"], host-module = true }
+plugins = { version = "0.8.0", features = ["rules-spirv"], host-module = true }
 ```
 
 `[build-dependencies]`, not `[dependencies]`. The two keys answer separate
@@ -66,7 +66,7 @@ engine's own module family and is not used here.
 | `rules-ascendc` | `mcpp.rules.ascendc` | 2026.9.6.6 | `[build] accel = "ascend8.5+{dav-c220}"`, a constrained glob for `*.asc`. Compiles with BiSheng in MIXED mode, so the object carries the device binary and a host-callable launcher and joins the ordinary link -- no registration file and no device-link step. Its own engine needs are `.asc` in the device-source table and `mcpp::link_flag` for the `-rpath-link` the toolkit's shared libraries require, both 2026.9.6.5 |
 | `rules-cuda` | `mcpp.rules.cuda` | 2026.9.6.6 | `[build] accel = "cuda…"`, a constrained glob for `*.cu`; the clang route with an LLVM toolchain, the nvcc route with a GCC one |
 | `rules-hip` | `mcpp.rules.hip` | 2026.9.6.6 | `[build] accel = "hip, cuda12.9+{sm_89}"`, a constrained glob for `*.hip`. On the NVIDIA platform HIP is a header layer over the CUDA runtime, so the compiler is the project's own clang and there is no ROCm on the machine |
-| `rules-slang` | `mcpp.rules.slang` | 2026.9.7.1 | `[build] accel = "vulkan1.2"`, a constrained glob for `*.slang`. Slang is a different language from GLSL rather than a second driver for it -- its own module system, generics, and targets beyond SPIR-V -- so it is a rule of its own. `.slang` is **not** in the engine's device-source table: this feature declares `device_extensions = [".slang"]` and `rule_module = "mcpp.rules.slang"`, and the engine routes it from there. That is the criterion for the whole arrangement -- a new device language costs no engine release |
+| `rules-slang` | `mcpp.rules.slang` | 2026.9.7.1 | `[build] accel = "vulkan1.2"`, a constrained glob for `*.slang`. Slang is a different language from GLSL rather than a second driver for it -- its own module system, generics, and targets beyond SPIR-V -- so it is a rule of its own. `.slang` is **not** in the engine's device-source table: this feature declares `device_extensions = [".slang"]` and `rule_module = "mcpp.rules.slang"`, and the engine routes it from there. That is the criterion for the whole arrangement -- a new device language costs no engine release. Since 0.7.0 it has the same `options::storage` axis as `rules-spirv` (header / object / sidecar), `options::extra_args` for the arguments the rule has no field for, and `options::per_file` for what one shader gets that the others do not -- a project with a `-fvk-use-gl-layout` and one shader needing `-emit-spirv-via-glsl` writes both without leaving one `compile()` call |
 | `rules-spirv` | `mcpp.rules.spirv` | 2026.9.6.6 | `[build] accel = "vulkan1.2"`, a constrained glob for the shader stages; compiles each shader through a `role = "source"` action and states which of the two compilers produced it |
 | `rules-sycl` | `mcpp.rules.sycl` | 2026.9.6.6 | `[build] accel = "sycl"` or `"sycl, cuda12.9+{sm_89}"`, a constrained glob for `*.sycl`, and `compat:sycl-runtime` so the artifact can reach `libsycl.so.9` at run time. Its own engine need is `.sycl` in the device-source table, 2026.9.6.1 |
 | `tools-embed` | `mcpp.tools.embed` | 2026.9.5.4 | nothing beyond mcpp: it reads a file and writes a header while the build program runs. The floor is the release whose fast path compares a declared file input, without which an edit to the data does not reach the binary |
@@ -83,7 +83,7 @@ A project names the rule and nothing else:
 
 ```toml
 [build-dependencies.mcpp]
-plugins = { version = "0.7.0", features = ["rules-cuda"], host-module = true }
+plugins = { version = "0.8.0", features = ["rules-cuda"], host-module = true }
 ```
 
 The payloads each rule drives are declared **here**, under the feature that
@@ -167,6 +167,15 @@ looks harmless.
 0.5.0, 0.5.1 and 0.5.2 do not move it. Naming an island's entry points is a
 change to what this package generates, not to what it asks the engine for.
 
+0.7.1 does not move it either, and records a compiler rather than an engine:
+under MSVC 14.52 (36629 and 36725, measured on xrgui's CI) a module that has
+instantiated `std::filesystem::path`'s iterator poisons every importer that
+touches `path` again -- `filesystem(1572): error C2801: '_Path_iterator<...>::operator =='
+must be a non-static member`. Nothing in this package instantiates that
+iterator now: the lib root reads paths apart as strings
+(`mcpp::plugins::names::components`), and the members' relative-path
+arithmetic is `mcpp::plugins::names::relative_to`.
+
 The previous shared floor was 2026.9.7.1, the release that reads
 `device_extensions` and `rule_module`, reports `[language] modules` and the
 package's own name to a build program, writes the build program a declared rule
@@ -324,8 +333,8 @@ consumer compiled either way is the same source.
 relative to the working directory, so the program finds its payloads when run
 from the package root and does not when run from elsewhere -- which is why it is
 not the default, and why `mcpp pack` of such a program has something further to
-collect. `tests/spirv-sidecar` asserts both halves: found from the root, and
-reported missing from `/tmp`.
+collect. `tests/spirv-sidecar` and `tests/slang-sidecar` assert both halves: found
+from the root, and reported missing from `/tmp`.
 
 **The default follows the project.** `[language] modules = true` gives the
 module surface, `false` gives a header with the same declarations. mcpp reports

dist/appimage.cppm

@@ -361,8 +361,8 @@ inline plan plan_for(options opt = {}) {
         p.reason = "no launcher in the staged tree";
         return p;
     }
-    const auto launcher_rel =
-        std::filesystem::path(launcher).lexically_relative(stage).generic_string();
+    // Strings, not `lexically_relative`: see `mcpp::plugins::names::relative_to`.
+    const auto launcher_rel = mcpp::plugins::names::relative_to(launcher, stage);
 
     // ── The three files AppImage requires, written into the staged tree ────
     const std::string name = app_name_for(opt);

mcpp.toml

@@ -1,7 +1,7 @@
 [package]
 name        = "plugins"
 namespace   = "mcpp"
-version     = "0.7.0"
+version     = "0.8.0"
 description = "Official mcpp build plugins: rule packages under mcpp.rules.*, build-time utilities under mcpp.tools.*, each member selected by a feature"
 license     = "Apache-2.0"
 authors     = ["mcpp-community"]