Isolated crate compilation

tools and infrastructure cargo
1

Currently cargo seems to share a single config for all code when compiled. Specifically, I encountered two situations.

Suppose I have two repositories A and B, where A depends on B:

The first case is when B depends on serde_json. Then the method in serde_json causes A type inference to fail.

The second scenario is that my warehouse B uses a custom config.toml file to enable tokio_unstale. Then A did not enable tokio_unstable when compiling (but B was already enabled). resulting in failure.

For the first case, it looks like cargo copied all the code together, causing the type inference to fail.

For the second case, it looks like cargo completely ignores the compile command in repository B. That is, once B uses the code in tokio_unstale. Then all codes that depend on B also need to add --cfg tokio_unstable

2

Currently cargo seems to share a single config for all code when compiled.

This is intended behavior. Specifically, the broad classification is:

  • config.toml is for customizing the behavior of Cargo commands in largely the same ways as are possible through command-line arguments.
  • Per-package/crate configuration goes in Cargo.toml, the manifest for the package.
  • A limited exception exists in [profile], where Cargo.toml can specify some build options, globally and also per-package with profile overrides.

The amount of configuration you can do for specific crates in your dependencies is limited to what is in [profile]s. If you want to be able to control additional flags, you'd want to argue for extending the functionality of [profile].

But note also that the whole reason Tokio uses a --cfg instead of the usual Cargo features mechanism is to prevent an arbitrary dependency of your code from activating Tokio unstable features. The designers of Tokio intend that you have to set --cfg tokio_unstable in A, so that you are explicitly opting in to “A uses unstable dependencies and an ordinary cargo update might break them”.

For the first case, it looks like cargo copied all the code together, causing the type inference to fail.

It's unclear what's going on. Cargo definitely doesn't combine code from multiple crates. Can you say more about what you are observing — starting with the full text of the error message?

1 Like
3

I've had this bug issue years ago. Simply importing something from json or serde_json triggers this errror: rustexplorer. Core issue is a impl PartialEq<Number> for u8. playground

It is no surprise that a feature or cfg flag brings new impls into scope that impact type inference. In fact, type inference is (or at least: was) excluded from the stability guarantees

4

Although type inference is not covered by the stability guarantee, it still looks very strange that A fails to compile because B depends on serde_json. After all, A just depends on B, and has nothing to do with serde_json.

5

Well, it looks like this is a bug in Rust. Rust is already working on fixing it, I should have written a more concrete example to illustrate my problem to them.