28 — Cargo Features

Answer: A — [features] section with logging = []

Explanation: Features are declared under a [features] table as name = [list-of-other-features-or-optional-deps-to-enable]; an empty list is valid for a "marker" feature used only in #[cfg(feature = "logging")] checks. [dependencies.logging] is wrong because features aren't dependencies unless tied to an optional crate. logging = true at the top level isn't valid TOML for Cargo's schema. [profile.*] tables configure compilation profiles (opt-level, debug info), not feature flags — a common mix-up for newcomers scanning Cargo.toml.

Answer: A — Cargo implicitly creates a feature named serde that enables the dependency

Explanation: Marking a dependency optional = true automatically creates an implicit feature of the same name; enabling that feature pulls in the crate. No manual [features] entry is required (though on the 2021 edition you can opt into requiring the explicit dep:serde syntax to suppress that implicit feature — see the dep: question later in this quiz). It doesn't compile unconditionally, and it has nothing to do with [build-dependencies], which is a separate dependency graph for build scripts.

Answer: A — cargo build --no-default-features

Explanation: --no-default-features opts out of whatever [features] default = [...] lists; you then opt back in to specific features with --features. --default-features=false is invalid CLI syntax (that phrasing only exists as a Cargo.toml dependency table key, not a top-level flag), --features=none just tries to enable a feature literally named none, and --minimal isn't a real Cargo flag.

Answer: A — Depend on reqwest with its own defaults disabled, enabling only the json feature

Explanation: default-features = false on a specific dependency entry opts that dependency out of its own default feature set (defined in its Cargo.toml), scoped only to that dependency — it has no effect on the current crate's own features or the workspace. features = ["json"] then explicitly turns on just that one. The two keys commonly appear together and are not mutually exclusive; there's nothing resembling "filtering at link time."

Answer: A — Only tls — Cargo unifies to the union of all requested features across the graph

Explanation: Safety/Idiom: Cargo compiles each version of a dependency exactly once per build graph, so it must reconcile every requester's feature request into a single set — it takes the union. B's default-features = false only says "don't turn on net-lib's own defaults for my request"; it can't retract a feature that A separately asked for. This is the classic "feature unification" footgun: you cannot rely on disabling defaults to shrink a dependency if any other crate in the graph re-enables them. There's no per-requester recompilation and no conflict error — features are required to be purely additive for exactly this reason.

Answer: A — The dep:regex syntax in [features], which suppresses the automatic implicit regex feature

Explanation: Since the 2021 edition's feature resolver, referencing an optional dependency as dep:regex inside any [features] entry suppresses the automatic implicit feature of the same name, letting you expose only search publicly while still gating the dependency internally. hidden = true isn't a real Cargo.toml key. Renaming via package = changes which crate is pulled in under a local name, it doesn't touch feature visibility. Before this mechanism existed, optional deps unavoidably created a same-named public feature — that's exactly the gap dep: was added to close.

Answer: A — Add a positive std feature; stay #![no_std] by default and gate on #[cfg(feature = "std")]

Explanation: Idiom: Cargo features must be additive/unification-safe — enabling a feature can only ever add capability, never remove it, because unification takes the union across the whole graph. A no_std feature that removes std support when turned on would break the instant two crates in the graph disagree (one wants std, one wants "not std" — unification would nonsensically enable both). The idiomatic pattern flips the polarity: the crate is minimal (no_std) by default, and an additive std feature unlocks more. default-features = false in [package] isn't a valid key — that phrasing only applies to dependency entries.

Answer: A — Cargo compiles successfully; it has no built-in concept of mutually exclusive features

Explanation: Safety: Cargo's feature system was designed to be purely additive so unification always has a well-defined answer (the union); it has no syntax for declaring two features as mutually exclusive, and it will happily enable both if any two crates in the graph disagree. If the crate author needs a hard failure, the idiom is to add compile_error!("backend-a and backend-b are mutually exclusive") inside a #[cfg(all(feature = "backend-a", feature = "backend-b"))] block so misuse fails loudly at compile time instead of silently misbehaving at runtime. Cargo does not pick a winner or auto-disable — that would violate the additive guarantee other tooling relies on.

Answer: A — Yes; the other dependency's request for defaults wins the union

Explanation: Performance: This is a widely-hit real-world footgun: default-features = false is a per-requester opt-out, not a graph-wide veto. Because unification takes the union of every requester's features, as soon as any crate in the graph asks for image's defaults, they're included in the single shared compilation — your own default-features = false only means "I personally don't require them," not "disable them globally." The only reliable fix is to get the other dependency changed (or patched/forked) to also opt out, or to avoid depending on the offending crate. There is no declaration-order tiebreak and no intersection semantics — it's always a union.

Answer: A — Neither; full is just an alias and must itself be requested

Explanation: A feature entry like full = ["net", "db", "compress"] defines a one-directional relationship: turning full on turns those three on. It says nothing about the reverse — enabling net alone has no effect on full, db, or compress. This trips people up because they expect feature "groups" to behave symmetrically; in reality full is nothing more than syntactic sugar for "enable these three together," requested independently like any other feature.

Answer: A — No; dev-dependencies are only available to tests, examples, and benchmarks

Explanation: [dev-dependencies] populate a separate graph used only when building test/bench/example targets (cargo test, cargo bench, cargo run --example); they are not linked into the library or binary artifact produced by a plain cargo build, and downstream consumers of your published crate never see them at all. This is why crates.io rejects a Cargo.toml where library source references a dev-only dependency — it simply won't resolve outside test builds. There's no feature-flag coupling and no debug/release distinction here; the separation is by target kind, not build profile.

Answer: A — Read the CARGO_FEATURE_JSON environment variable

Explanation: Debug: Cargo exposes each enabled feature to build.rs as an environment variable named CARGO_FEATURE_<FEATURE_NAME_UPPERCASE_WITH_UNDERSCORES> (e.g. json → CARGO_FEATURE_JSON), set to 1 when enabled and absent otherwise. #[cfg(feature = ...)] doesn't apply here because build.rs is compiled and run as a separate program before the crate itself, under a different cfg context — a mistake newcomers make constantly. There's no such cargo crate API for this, and manually parsing Cargo.toml is unnecessary and fragile since Cargo already does the resolution and hands you the answer via env vars.

Answer: A — Only items reachable under the crate's default feature set

Explanation: cargo doc builds documentation the same way cargo build compiles code: using whatever feature set is active for the invocation, which defaults to the default feature list. Items behind non-default #[cfg(feature = "...")] gates simply don't exist in that compilation and so never reach the doc generator. To document everything, maintainers run cargo doc --all-features (or docs.rs's [package.metadata.docs.rs] all-features = true config). Plain cargo doc does not fail on zero features, and there's no automatic strikethrough rendering for gated items.

Answer: A — Yes, feature unification applies across the whole workspace build by default

Explanation: When multiple workspace members share a dependency and are built together in one cargo build --workspace invocation, Cargo still compiles that shared dependency once, unified across every member being built in that command — exactly like unification across a single crate's transitive graph. This surprises people who expect workspace members to be isolated. The 2021 "feature resolver v2" (resolver = "2") narrows unification (notably separating host/target and dev-dependency feature sets) but does not eliminate cross-member unification for normal dependencies built together; it does not disable unification outright. Member order in [members] has no bearing on this.

Answer: A — Make tokio optional, gated behind a non-default async feature

Explanation: Idiom: This is the standard pattern seen across the ecosystem (e.g. reqwest, sqlx): mark the runtime dependency optional = true and expose it through an additive feature that consumers opt into, leaving it off of default so sync-only consumers pay zero cost. Depending on tokio unconditionally forces every consumer to compile and link it even if they never touch the async API — --no-default-features on the consumer's own crate does nothing to strip a dependency the library itself declared unconditionally. Vendoring or forking into duplicate crates massively increases maintenance burden for no benefit when Cargo already solves this cleanly.

Answer: A — Avoid it; behavior-changing features break the additive convention

Explanation: Safety: Because feature unification means "if anything in the dependency graph enables this feature, it's on for everyone," a feature that changes semantics (not just adds capability) can silently alter your crate's behavior based on an unrelated dependency three levels away enabling it for its own reasons — a notoriously hard bug to trace. The Cargo team's own guidance is that features should be strictly additive; behavior toggles are better expressed as separate crates, runtime configuration, or distinct type-level APIs. Documentation doesn't fix the unification hazard, making it default doesn't solve the underlying issue, and environment variables introduce their own non-reproducibility problems for library code (they're invisible to Cargo.lock and to downstream consumers reasoning about a crate's compiled behavior).

Answer: A — The dep_name?/feature_name weak-dependency-feature syntax

Explanation: Idiom: serde?/derive (the ? marks it "weak") means "if serde ends up enabled by someone in the graph, also turn on its derive feature — but don't turn serde on by yourself." This is exactly for the case in the question: contributing a feature to a dependency without forcing that dependency to exist. The non-? form serde/derive is the older, "strong" syntax that does implicitly enable serde as a side effect, which is the opposite of what's wanted here. [package] has no optional-features key.

Answer: A — To let consumers opt in explicitly and avoid unwanted transitive weight or unification surprises

Explanation: Idiom: Keeping default minimal (or empty) is a deliberate ecosystem convention for foundational crates so that consumers pay only for what they ask for, and so that unification doesn't quietly drag in heavy optional dependencies just because some crate in the graph forgot to pass default-features = false. This is purely a design choice, not a crates.io requirement — Cargo places no restriction on default content for publishing. cargo install respects defaults normally. And the last option is wrong in a subtle way: omitting [features] entirely means the crate has zero features at all (nothing to enable), whereas an explicit default = [] still allows other, non-default features to exist and be turned on individually — they're not identical when the crate defines additional optional features.

Answer: A — cargo hack --feature-powerset (or similar) to check every combination

Explanation: Idiom/Debug: --all-features on is a different compilation than any individual subset — a crate can easily compile fine with everything on (where conflicting #[cfg] branches never both trigger issues) yet fail to compile with only feature x on and not y, especially with mutually-referential #[cfg(feature = ...)] code. cargo-hack's --feature-powerset mode compiles every combination in turn and is the standard CI safeguard used by mature crates for exactly this reason. cargo test only runs whatever single feature set was active for that invocation, so it can't surface combination-specific breakage on its own, and there is no guarantee that "all features compiles" implies "every subset compiles" — the additive-features convention is a social contract enforced by testing, not something the compiler verifies for you.

Answer: A — Explicitly document that unstable-gated APIs are exempt from normal semver guarantees

Explanation: Idiom: Since Cargo has no built-in notion of "this feature's APIs don't count toward semver" (there is no automatic exemption — that part of option C is fabricated), crates that ship experimental surface behind a feature like unstable rely entirely on clear documentation (README, feature doc comment, changelog policy) stating that breaking changes there can land in any release, including patches. This is a widely used convention (e.g. in tokio, rand) precisely because publishing genuinely separate crates for every experimental API would fragment the ecosystem and versioning unnecessarily. Treating it like normal semver-bound code would freeze experimentation prematurely.