Allow `check-cfg` to take a regex config name and values about rust HOT 3 CLOSED

@rustbot label -needs-triage +C-feature-request +F-check-cfg +T-compiler

from rust.

That's an interesting idea, but I'm not sure how valuable it would be given the implementation challenges and the small number of potential users.

However regarding the "leads to noisy logs" part you can already significantly reduce the number of --check-cfg args by factorizing them by their values:

To avoid repeating the same set of values, use this form:

rustc --check-cfg 'cfg(name1, ..., nameN, values("value1", "value2", ... "valueN"))'

Which in your case would be something like: cfg(__ashldi3, __ashlsi3, __ashrdi3, ..., __aarch64_swp8_acq_rel, values("optimized-c")); this would already reduce significantly the number of arguments based on the logs you gave us.

One thing we should on our end, is using a dedicated argument file to pass all the --check-cfg arguments at once, rust-lang/cargo#13941.

from rust.

However regarding the "leads to noisy logs" part you can already significantly reduce the number of --check-cfg args by factorizing them by their values:

To avoid repeating the same set of values, use this form:
rustc --check-cfg 'cfg(name1, ..., nameN, values("value1", "value2", ... "valueN"))'

Which in your case would be something like: cfg(__ashldi3, __ashlsi3, __ashrdi3, ..., __aarch64_swp8_acq_rel, values("optimized-c")); this would already reduce significantly the number of arguments based on the logs you gave us.

I didn't know that was an option, thanks for the pointer.

One thing we should on our end, is using a dedicated argument file to pass all the --check-cfg arguments at once, rust-lang/cargo#13941.

That would be even better, and would solve the biggest problem I have here. With that open, I agree that regex probably wouldn't have many users.

from rust.