Verbose runs should show which features were enabled in the crate versions being tested

[Predrag Gruevski]

Recently, a user had an issue where there was some confusion over which features were being enabled. The user submitted the verbose log (--verbose) of their run, but that still did not indicate which features were being enabled.

As a result, the user couldn't easily tell if the feature in question was enabled or not in their run. This is something we should fix.

Often, crates have many features, and the feature names may be long. So it might not be appropriate to output all the enabled features by default. But a --verbose run should definitely output which features were selected, both in the baseline and in the current version.

[jw013]

If the following sample output looks reasonable I can push up a PR

     Parsing enum_missing v0.1.0 (current)
   features: ["foo"]
      Parsed [   1.469s] (current)
     Parsing enum_missing v0.1.0 (baseline)
   features: []
      Parsed [   0.648s] (baseline)
    Checking enum_missing v0.1.0 -> v0.1.0 (no change)
    Starting 68 checks, 0 unnecessary on 4 threads
        PASS [   0.013s]       major        auto_trait_impl_removed
        PASS [   0.002s]       major        constructible_struct_adds_field
... 

This is just using Debug formatting, basically a one-line change.

[Predrag Gruevski]

Sorry, I'm traveling at the moment. I'm without my laptop until the end of next week, so my feedback is going to be very sporadic and not particularly well formatted. Thanks for looking into this issue! Here are a few stream of consciousness thoughts. At a glance, it feels a bit confusing to see the features on a new line. The "features:" text doesn't quite match the other text in that left column, and it's a bit strange to see the crate name and version separately from the features. Could you see if you can come up with a reasonable way to put the features on the same line that names the crate and version? Does cargo ever print features for a crate? If so, that format might be good to match. I also feel like we probably could avoid the quotes in the feature list, to save a few characters.

…

On Fri, Mar 22, 2024, 9:41 PM jw013 ***@***.***> wrote: If the following sample output looks reasonable I can push up a PR Parsing enum_missing v0.1.0 (current) features: ["foo"] Parsed [ 1.469s] (current) Parsing enum_missing v0.1.0 (baseline) features: [] Parsed [ 0.648s] (baseline) Checking enum_missing v0.1.0 -> v0.1.0 (no change) Starting 68 checks, 0 unnecessary on 4 threads PASS [ 0.013s] major auto_trait_impl_removed PASS [ 0.002s] major constructible_struct_adds_field ... This is just using Debug formatting, basically a one-line change. — Reply to this email directly, view it on GitHub <#711 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAR5MSWKANBDOS4NAMB72TLYZT2WFAVCNFSM6AAAAABE6YH3ICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGMZTCMZVGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jw013]

One place I could think of where cargo prints features is cargo add. If we follow that style, the output would be multi-line and look like

     Parsing enum_missing v0.1.0 (current)
             Features:
             + foo
             + bar
      Parsed [   1.469s] (current)
     Parsing enum_missing v0.1.0 (baseline)
      Parsed [   0.648s] (baseline)
    Checking enum_missing v0.1.0 -> v0.1.0 (no change)
    Starting 68 checks, 0 unnecessary on 4 threads
        PASS [   0.013s]       major        auto_trait_impl_removed
        PASS [   0.002s]       major        constructible_struct_adds_field
...

Another possibility is cargo tree -f '{p} {f}'. Following that single-line style would look like

     Parsing enum_missing v0.1.0 (current) foo,bar
      Parsed [   1.469s] (current)
     Parsing enum_missing v0.1.0 (baseline)
      Parsed [   0.648s] (baseline)
    Checking enum_missing v0.1.0 -> v0.1.0 (no change)
    Starting 68 checks, 0 unnecessary on 4 threads
        PASS [   0.013s]       major        auto_trait_impl_removed
        PASS [   0.002s]       major        constructible_struct_adds_field
...

The single line format looks worse if the feature list is long enough to wrap but is otherwise more compact most of the time. Let me know which one you prefer.

[Predrag Gruevski]

Nice bit of research! I didn't know about that cargo tree command.

I agree the single-line format looks more compact and better overall unless the list wraps.

I'm a bit worried that the features listed after the version number and the (current) or (baseline) indicator might look confusing:

     Parsing enum_missing v0.1.0 (current) foo,bar
...
     Parsing enum_missing v0.1.0 (baseline, cached) foo,bar

What do you think about a possible hybrid version:

     Parsing enum_missing v0.1.0 (current)
             Features: foo, bar
      Parsed [   1.469s] (current)
     Parsing enum_missing v0.1.0 (baseline)
             Features: foo, bar
      Parsed [   0.648s] (baseline)
    Checking enum_missing v0.1.0 -> v0.1.0 (no change)
    Starting 68 checks, 0 unnecessary on 4 threads