Verbose runs should show which features were enabled in the crate versions being tested
obi1kenobi opened this issue · comments
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.
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.
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.
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