rustc options don't really differentiate between "benign" options --deny, --allow, --verbose etc and options which affect interpretation/output --codegen, --edition etc. One of the ways this ends up affecting upstream tools is that flags like RUSTFLAGS in cargo have difficulty deciding whether an option is benign since it requires parsing the command line and knowledge of each command implementation in the compiler.
This makes it difficult to set benign flags on dependencies, since the RUSTFLAGS for the top-level is always used because it may contain options which are not actually benign, and code-gen options must be in accord between dependencies.
One way rustc could alleviate this, is by specifying a flag internally for each option. Then add an option for grouping arguments, e.g. --start-option-mode=benign --verbose --foo --end-option-mode=benign.
Which forces for the duration of the option mode only benign commands to be interpreted otherwise causing an error.
Downstream rustc invokers like cargo could then implement things like RUSTFLAGS_BENIGN just by wrapping the variable contents in a start/end option-mode. Then RUSTFLAGS_BENIGN can in theory be more broadly changed since it does not need to be consistently the same across all crates in a dependency chain. (Not imply that we should implement this for cargo, but it would make it feasible to implement where-as without it it would be a bit painful.)
Setting --deny, --allow and --verbose for dependencies doesn't have any effect. Cargo forcefully disables all lints for dependencies without any way to opt in even through --forbid.--verbose doesn't have any effect when there are no errors afaik.
When I looked it seemed like there isn't really a mechanism for setting them besides RUSTFLAGS/conf, so they never even get passed to rustc. Allowing them to be passed causes problems since they can also affect codegen so I believe that they never actually get passed to rustc?
Anyhow, I wasn't sure they weren't sure if it isn't allowed because there is no mechnism in place to make it behave nicely. Or if there is no mechanism because of all the drama that ensues when someone wants to lint dependencies?
FWIW I'm actually wanting this supported in rustc rather than cargo, because i'm not calling rustc from cargo as normal, but through something else, where linting dependencies is something I would like to support...
Cargo passes --cap-lints allow to rustc for dependencies, which overrides every method to enable linting of the crate. It does so to ensure that new lints added to rustc never cause a compilation error/warning you can't fix without modifying dependencies. This means we can add new lints without fear that it will break existing code, unlike in the C world where -Wall -Werror is common.
Sure when compiling a crate, but when you want to run a lint on all crates in the dependency graph to see if it catches anything. It is quite inconvenient to download and compile each crate in the dependency graph individually in order to apply lints. I don't see that these things need to be mutually exclusive.
I assume the main point of this is that these "benign" arguments will not be part of Cargo's input-hash, so even when they change it can reuse previously cached compiler output? Though, Cargo also caches the stdout/stderr which flags like --verbose do affect.
Yes, that was at least part of the thought, besides giving rustc invoking tools a good mechanism to pass non-codegen affecting arguments without having to know about the any specifics of rustc.
That is helpful for lint authors, but for developers who want to lint their dependencies it seems overkill, and difficult to put in the hands of a package author that just wants to lint things that affect their crates.
Edit: Anyhow, I kind of give up, this was for a tool that I am writing which invokes rustc directly and every response is about cargo or some other tool which invokes rustc, so I'm a bit frustrated but I should have anticipated that and made it more clear.