Repository navigation
2026.9.27.1: a member reached as a path dependency of the workspace root's package cannot use workspace = true #725
Description
Since 2026.9.27.1 (#714), a workspace member reached as a path dependency of the workspace root's own package can no longer use workspace = true: the build fails with "no workspace declares" the dependency, although the root's [workspace.dependencies] declares it and [workspace].members lists the member. 2026.9.26.1 builds the same tree.
Reproduction
root/
mcpp.toml
src/main.cpp import a; int main() { return a_value() - 1; }
a/mcpp.toml
a/src/a.cppm export module a; export int a_value() { return 1; }
root/mcpp.toml:
[workspace]
members = ["a"]
[workspace.dependencies]
cmdline = "0.0.2"
[package]
name = "root"
version = "0.1.0"
[dependencies]
a = { path = "a" }root/a/mcpp.toml:
[package]
name = "a"
version = "0.1.0"
[targets.a]
kind = "lib"
[dependencies]
cmdline.workspace = true
[lib]
path = "src/a.cppm"mcpp build in root/:
- 2026.9.26.1:
Compiling a (path)…Finished. - 2026.9.27.1:
error: dependency 'a': <root>/a/mcpp.toml: [dependencies] cmdline = { workspace = true }, but no workspace declares 'cmdline'.
`workspace = true` is resolved against the [workspace.dependencies] of the workspace whose `members` list this package.
fix: list this package in that workspace's [workspace] members, or state the dependency's version, path or git source here.
a is listed in that workspace's members, so the fix the message suggests is already in place. Building inside root/a/ works with 2026.9.27.1; mcpp build -p a at the root answers workspace member 'a' not found in [workspace].members.
Impact
Sunrisepeak/mcpp-language-server is laid out this way (root package = the server, modules/base and modules/platform are members it depends on by path, each using openkal-llvm-runtime.workspace = true), and does not build with 2026.9.27.1. Its CI pins 2026.9.26.1, so this shows up first in its nightly run against the latest mcpp.
Activity
speak-agent commentedon Sep 27, 2026
Implemented in 2026.9.28.1 (#727). The triage is in
.agents/docs/2026-09-27-eight-reports-by-home-and-one-optimisation-plan.md§2.[package]and[workspace]) now carries its context to a member reached through the root's own[dependencies]path entry. The member inherits[workspace.package]and[workspace.build]and resolvesworkspace = trueagainst[workspace.dependencies], as SPEC-004 §9 item 1 states.[toolchain],[target.<triple>]and[indices]stay the root's.-p, --package <NAME>resolves by package identity. One resolver (resolve_member_dir) answers in this order: the qualified name, the package name, then the member's path or directory name. Paths are compared as paths. A package name that two namespaces share is refused, with both qualified names given. A value that is one member's package name and another member's directory selects the package, with a warning.Verification of the published release. A fresh SubOS sandbox (
xlings subos use <name> --sandbox) with the CN mirror configured for both xlings and mcpp installedmcpp@2026.9.28.1through the index and ran one script over the published binary:13 ok, 0 failed(the Windows-only items are reported as not run). The same script in a second sandbox againstmcpp@2026.9.27.1reads5 ok, 8 failed, so each assertion below measures this change rather than the setup it runs in.[workspace.build]flags;mcpp.lockrecords the pinnedcmdline0.0.1, not 0.0.2missing required field 'package.version'-p wsaselects the member whose package iswsain directoryaworkspace member 'wsa' not founde2e 805 and 806 carry the same properties in the suite.