RFC: --crate-attr
#3791
RFC: --crate-attr
#3791
Conversation
text/0000-crate-attr.md
Outdated
| # Unresolved questions | ||
| [unresolved-questions]: #unresolved-questions | ||
|
|
||
| How should this interact with doctests? Does it apply to the crate being tested or to the generated test? |
There was a problem hiding this comment.
after thinking about this, i think this should always apply to the crate being tested. to apply to the generated test people can use --crate-attr=doc(test(attr(...))) (which is a bit of a mouthful, but, at least it's unambiguous.)
| 3. Tools that require a specific attribute can pass that attribute automatically. | ||
|
|
||
| Each of these corresponds to a different set of stakeholders. The first corresponds to developers writing Rust code. For this group, as the size of their code increases and they split it into multiple crates, it becomes more and more difficult to configure attributes for the whole workspace; they need to be duplicated into the root of each crate. Some attributes that could be useful to configure workspace-wide: | ||
| - `no_std` |
There was a problem hiding this comment.
One of the potential routes for build-std is that the Cargo.toml has metadata for which std crates are used which means Cargo would need to be able to tell rustc about #[no_std]. Unsure if there would have been another way to do it but this looks like it would allow that!
|
|
||
| Additionally, some existing CLI options could have been useful as attributes. This leads to the second group: Maintainers of the Rust language. Often we need to decide between attributes and flags; either we duplicate features between the two (lints, `crate-name`, `crate-type`), or we make it harder to configure the options for stakeholder group 1. | ||
|
|
||
| The third group is the authors of external tools. The [original motivation][impl] for this feature was for Crater, which wanted to enable a rustfix feature in *all* crates it built without having to modify the source code. Other motivations include the currently-unstable [`register-tool`], which with this RFC could be an attribute passed by the external tool (or configured in the workspace), and [custom test frameworks]. |
There was a problem hiding this comment.
Looking at custom test frameworks, I'm not quite following how this would be useful.
Note that the current plan for custom test frameworks is very different than #2318, see rust-lang/testing-devex-team#2
ehuss
added
the
T-compiler
Rendered
cc rust-lang/rust#138287