Emit expected cfg instruction in build.rs#1028
Emit expected cfg instruction in build.rs#1028mulkieran merged 1 commit intostratis-storage:masterfrom
Conversation
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 40 minutes and 28 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughConfiguration changes to the Rust compiler's cfg (configuration) handling system. The linting rules in Cargo.toml were simplified by removing explicit check-cfg entries while adding a priority level, and the build script was updated to emit rustc check-cfg registration directives alongside cfg definitions for devicemapper version configurations. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
build.rs (1)
18-27:⚠️ Potential issue | 🔴 CriticalSplit loops: unconditional rustc-check-cfg registration, conditional rustc-cfg enabling.
Both
rustc-check-cfgandrustc-cfgare currently emitted only inside thetake_whileloop (lines 18–27), which gates them by the detected libdm runtime version. This causes cfg names for higher versions to remain unregistered when the runtime libdm is older, triggeringunexpected_cfgs = deny(enabled in Cargo.toml) since all five cfg names (devicemapper41supported,devicemapper42supported,devicemapper437supported,devicemapper441supported,devicemapper46supported) are used unconditionally in source code attributes.Proposed fix
- for ver in DM_VERSIONS.iter().take_while(|ver_string| { - let iter_version = Version::parse(ver_string).expect("Could not parse version"); - version >= iter_version - }) { + for ver in DM_VERSIONS { let version_cfg = format!( "devicemapper{}supported", ver.split('.').take(2).collect::<Vec<_>>().join("") ); println!("cargo::rustc-check-cfg=cfg({version_cfg},)"); + } + + for ver in DM_VERSIONS.iter().take_while(|ver_string| { + let iter_version = Version::parse(ver_string).expect("Could not parse version"); + version >= iter_version + }) { + let version_cfg = format!( + "devicemapper{}supported", + ver.split('.').take(2).collect::<Vec<_>>().join("") + ); println!("cargo:rustc-cfg={version_cfg}"); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@build.rs` around lines 18 - 27, The build script currently emits both the rustc-check-cfg and rustc-cfg inside the take_while loop, causing higher-version cfg names to never be registered; change the logic so you first iterate DM_VERSIONS (use the DM_VERSIONS iterable and the same version_cfg computation) and unconditionally emit println!("cargo::rustc-check-cfg=cfg({version_cfg},)") for every entry, then separately run the existing take_while loop (using Version::parse and the same version comparison) to emit println!("cargo:rustc-cfg={version_cfg}") only for versions supported by the detected runtime; keep the version_cfg formatting logic and Version::parse usage identical so the same cfg names are produced in both passes.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@build.rs`:
- Around line 18-27: The build script currently emits both the rustc-check-cfg
and rustc-cfg inside the take_while loop, causing higher-version cfg names to
never be registered; change the logic so you first iterate DM_VERSIONS (use the
DM_VERSIONS iterable and the same version_cfg computation) and unconditionally
emit println!("cargo::rustc-check-cfg=cfg({version_cfg},)") for every entry,
then separately run the existing take_while loop (using Version::parse and the
same version comparison) to emit println!("cargo:rustc-cfg={version_cfg}") only
for versions supported by the detected runtime; keep the version_cfg formatting
logic and Version::parse usage identical so the same cfg names are produced in
both passes.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 2fcf9b89-32bd-49c0-8b00-2fbea0edbab9
📒 Files selected for processing (2)
Cargo.tomlbuild.rs
|
Congratulations! One of the builds has completed. 🍾 You can install the built RPMs by following these steps:
Please note that the RPMs should be used only in a testing environment. |
It is no longer necessary to use the temporary workaround in Cargo.toml of specifying the expected values in unexpected_cfgs table. Signed-off-by: the Mulhern <amulhern@amulhern.bos.csb>
2ce51ab to
4f2dd3e
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
Summary by CodeRabbit