[prabhu]

Follow-up to #129 from an adversarial review of it. The headline: the rusi compiler backend does not build on any Rust 1.100 toolchain — today's beta, and stable from mid-November — and on 1.100+ it drops every leaf of use a::{b, c} from its imports. Both are fixed here, along with the review's other findings.

What was wrong, and what changed

1. The rustc_private version gate could not work (rusi, high). #129 selected the wrapper's API shape with one cfg set when the toolchain reports ≥ 1.101. Nightlies carry the version of the release they lead to, and the three forks landed on different days:

Change	Upstream	First nightly
ProjectionElem::PhantomDeref	rust-lang/rust#159103	2026-08-29 (1.100)
HIR UseTree / UseKind::Nested	rust-lang/rust#161349	2026-09-26 (1.100)
run_compiler → compiler_entrypoint	rust-lang/rust#163647	2026-10-03 (1.101)

On main, rustc 1.100.0-beta.7 and nightly-2026-09-29 fail either way: E0023/E0004 without the cfg, E0432 with it. The wrapper now has a build.rs that compiles a tiny probe per fork against the RUSTC cargo provides and sets one cfg each. The driver no longer injects RUSTFLAGS, which also stops it overriding cargo-config build.rustflags/target.*.rustflags on new toolchains. Standalone builds need no flags. The build script also adds <sysroot>/lib to the link path when the LLVM library lives only there, so the macOS -L workaround the README asked for is gone.

2. use a::{b, c} lost its leaves on 1.100+ (rusi, high). The new HIR keeps a whole use tree in one item with relative nested prefixes. The wrapper read only the top prefix, so it reported stems like std and std::collections as imports and dropped the rest. It now walks the tree, records each leaf at its own span, and folds self. The old shape also stops emitting empty-path ListStem imports. A new use-tree-app fixture pins identical leaf imports and positions on both shapes.

3. CI never exercised the forked code (CI, medium). The compiler-backend job now has three legs: the pinned nightly (Linux and Windows), beta (the leg that would have caught 1.100), and a rolling-nightly canary that is allowed to fail. Beta and the canary are named through RUSI_TEST_TOOLCHAIN, which the driver's ignored tests now honor as the CLI tests already did. The new import test refuses to pass on a stub fallback when a toolchain is pinned that way.

4. The runtime-symbol scan was easy to evade (rusi, medium). Each case below was checked against rustc 1.99.1:

• #[no_mangle] #[export_name = "exit"] now reports exit; export_name wins wherever it appears, as in rustc.
• #[export_name = concat!("mem", "set")] is now evaluated.
• Exports under cfg_attr(..) are now seen, including the common cfg_attr(not(test), no_mangle).
• #[no_mangle] associated functions are now reported. rustc doesn't lint them, but they still interpose.
• macro_rules! bodies that spell out an export are now read from their tokens, with medium confidence.
• POSIX symbols are no longer flagged in Windows-only code. rustc lints them only on unix-like targets; the six core memory symbols are still flagged everywhere.

5. Relative cache roots (rusi and cdxrs, low). rusi compiles and runs the materialized wrapper tree, but it accepted relative RUSI_CACHE_DIR, XDG_CACHE_HOME and HOME/LOCALAPPDATA, so a relative value could place that tree inside the repository being analyzed. A relative RUSI_CACHE_DIR is now an error; the other relative values are ignored. cdxrs now applies the same rule to HOME, LOCALAPPDATA and USERPROFILE, judged by the target platform's rules.

6. Unknown schema formats pass silently (cdxrs, medium). #129's idn-email regression came from jsonschema treating a format it doesn't know as valid. Validators are now built with should_ignore_unknown_formats(false). To check it, I built without the idna feature: the suite fails with Unknown format: 'idn-email' instead of validating less. get_validator also compiles each schema once per process; before, it recompiled on every call even though its doc comment said it cached.

7. gradlew.bat was always dirty (low). *.bat text eol=crlf means LF in the index and CRLF on checkout, but the blob was stored as CRLF, so every fresh clone showed the file as modified. It is renormalized; checkouts still get CRLF.

Looked at and left unchanged

• PhantomDeref → Deref. Deref and Opaque are equivalent to the flow engine (both only feed is_indirect), and treating it as a deref keeps the flow, which is the conservative choice.
• cdxui lockfile adds stacker/psm/cc. They aren't in the resolved build graph for any target (cargo tree -i psm --target all is empty); they are lockfile entries for an inactive optional pest dependency. All 8 zigbuild release targets of cdxui and cdxrs build with zig 0.17.0.

Verification

• 8 toolchains on macOS: 1.98.1, nightly-2026-08-21, nightly-2026-09-01, 1.100.0-beta.7, nightly-2026-09-29, nightly-2026-10-05, 1.99.1 and nightly-2026-10-15. On each:
  • wrapper clippy -D warnings and tests pass;
  • the probes select the expected shape;
  • rusi analyze --backend compiler on use-tree-app produces byte-identical imports.
• Emulated CI legs: the pinned nightly, beta and canary legs each pass 12 CLI and 6 driver ignored tests with the real embedded backend.
• Stable suites: rusi 335 tests and cdxrs 145 tests pass; clippy and fmt are clean.
• Cross-builds: cdxui and cdxrs zigbuild release builds pass for all 8 targets.
• Windows 11 ARM64 VM (MSVC):
  • cdxrs, cdxui and rusi stable tests, clippy and fmt pass.
  • Wrapper clippy and tests pass on 1.99.1, nightly-2026-08-21, 1.100.0-beta.7 and nightly-2026-10-18, with the expected probes.
  • The pinned-nightly, beta and rolling-nightly ignored suites pass: 12 CLI and 6 driver tests each, with the import test in strict mode.
  • A fresh worktree checks out clean, gradlew.bat included.
• CI: Rust 1.99.1 toolchain + crates to latest; wrapper through nightly 1.101; Windows CI legs #129 recorded no GitHub Actions runs, so this PR's run is the first time the Windows legs and the new beta and canary legs execute on hosted runners.

Not in this repo: cdxgen's JS validator (ajv-formats with strict: false) still accepts any idn-email, so cdxgen and cdxrs now disagree on contact emails. cdxgen's resolveCacheDirFor has the same relative-root gap. Both belong in a cdxgen PR.