Printing features when needed

1

If I try to use tokio::process::Command without enabling the process feature on the tokio crate, it would be nice if the error message would state that the process namespace is behind a process feature.

Are there any reasons that this could not be done?

(Or rather, the error would show what cfg violations caused access to fail).

2

Hmm... So Rust actually does this, but not always? I wrote the original post because I ran into a situation where it didn't, but I just ran into another situation where it does?

It says:

note: found an item that was configured out

.. and:

note: the item is gated behind the `conf` feature

I'm a little confused.

3

Maybe you could share your code? Just naively writing out tokio::process::Comand does give me an error message about said feature

error[E0433]: failed to resolve: could not find `process` in `tokio`
   --> src/main.rs:3:12
    |
3   |     tokio::process::Command;
    |            ^^^^^^^ could not find `process` in `tokio`
    |
note: found an item that was configured out
   --> /home/frank/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.43.0/src/lib.rs:514:13
    |
514 |     pub mod process;
    |             ^^^^^^^
note: the item is gated behind the `process` feature
   --> /home/frank/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.43.0/src/lib.rs:513:1
    |
513 | / cfg_process! {
514 | |     pub mod process;
515 | | }
    | |_^
    = note: this error originates in the macro `cfg_process` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this module
    |
1   + use std::process;
    |
help: if you import `process`, refer to it directly
    |
3   -     tokio::process::Command;
3   +     process::Command;
    |

for completeness, perhaps compiler version and the version of tokio might also be relevant.

4

Unfortunately not; it occurred in a client project -- but I'll try to see if I can create self-contained minimized variant that exhibits the issue.

I also encountered my very rust rustc ICE earlier today. Same problem -- it happens in client code. This one triggers reliably when a lifetime is omitted from a certain spot. I did spend some time trying to create a minimal reproducible example, but couldn't get the minimized variant to throw an ICE.

The first issue occurred with 1.85.0, while the second one happened with 1.84.1.

Just out of curiosity, regarding the ICE. Let's say I can't find a way to create a reproducible minimal example, and my client does not allow me to share the code. Is it still worth reporting? (I can give a pretty detailed explanation, and - although I don't know the compiler internals - the stack dump does look kind of helpful).

5

Ah, I thought just the parts that contribute in how Command is mentioned are sufficient.

E.g. what’s the path being used – probably not a fully-qualified literal tokio::process::Command which was what I tried… or is it? I mean, it would be interesting nonetheless, if there are cases where it ends up not working like that – but I wouldn’t be surprised if it instead involved some use statement, too; perhaps even re-exports…

…ah well, I guess I’m describing the process for “how to create a minimized variant”. Except that it would also seem worth sharing even if your minimization attempt leads to the issue disappearing, as long as it still gives some hints of the usage pattern.

for comparison, my error message came from testing simply something like

fn main() {
    tokio::process::Command;
}

Yes, I think it definitely is worth reporting. You can of course start out by searching for the error message (or parts of it) in existing issues, perhaps you already find one that seems structurally similar enough that it’s probably the same problem.[1] So yeah… feel free to open an issue, as long as you’re fine with the possibility that those people familiar with the compiler internals end up saying “I don’t know what the bug is, a reproducing example would help a lot” anyways – i.e. there’s the possibility that you spend some time trying to reduce/reproduce, and trying to explain the best you can, and the issue might remain unsolved nonetheless.

Heck, recently we were even successful in solving – not an ICE but – a compiler performance regression issue with closed-source code, but very cooperative reporters.

  1. in which case, you can save your repro somewhere and come back to it once that other issue is solved to test if it solved the ICE for your code, too ↩︎

6

have you tried using GitHub - langston-barrett/treereduce: A fast, parallel, syntax-aware test case reducer based on tree-sitter grammars ?

2 Likes
7

In general, conditional compilation is a terrible way to subset stuff. If something's cfgd off, it might not even parse -- at least if the module is cfged off -- so there's no way to even know what it does.

It would be nice if we could move these things into the type system instead, so the declarations were "still there", just with an impossible where clause so they can't be used. Then they'd have to parse, so rustdoc and diagnostics could still see them.

1 Like