enabling optional dependencies

[hdhoang]

crates are craterred with default features only, thus broken optional dependencies are not reported (case in point: rust-lang/rust#49799 breaks ocl-0.15.0 and clfft-0.3.1, but not basic_dsp_vector-0.5.2 which optionally uses those with use_gpu enabled).

A big hammer like --all-features could be a start, then we can configure mutually-exclusive features for each crate?

[Mark-Simulacrum]

I don't think the optional dependency problem is actually a problem -- we still test all of crates.io. However, it is true that code changes with various features enabled/disabled so it'd be nice to test that, but I think unfeasible today: doing so would have a large increase in time per run as each feature would produce a exponential(?) increase in times we'd need to compile it.

[hdhoang]

Hm yes, I share your concern about extended build time.

Looking at this from another angle, since crater already has crates.io metadata, can we enumerate downstream crates for each failure, and pre-emptively mark them regressed? I imagine it could work like this for a check-only run:

1. On encountering a BuildFail, mark the $crate-$version that fails as Regressed (the precise $crate-$version can be seen in the log, either in the registry's source such as github.com-1ecc6299db9ec823/ocl-0.15.0/src/, or the crate's own info when the failing file starts with src/)
2. From the metadata info, mark dependent crates as will-regress/fallout due to $crate-$version, and skip building them

If the metadata also tracks optional dependencies & the features used to enable them, step 2 could give us the necessary info without having to actually build with features, and maybe even report "will-regress when $feature is enabled".

With dependency-tracking, we should be able to report multiple upstream breakages for a given crate too, eg something using both glib 0.1 and rusqlite 0.13.

(also: I apologize for calling you a bot the other day!)

[pietroalbini]

With run-graph (and some changes that will soon be merged) most of the code to automatically mark dependent crates as regressed is already in place. The only two things that needs to be done is change the code that builds the build graph to account for dependencies, and change the code that propagate failures downstream to also propagate regressions.

[pietroalbini]

And also, the dependencies thing is a duplicate of #119.

[hdhoang]

Do run-graph connect optional dependency edges? I haven't seen that mentioned yet in the relevant issues. If it already does, this issue can be closed.

[pietroalbini]

run-graph doesn't connect dependencies at all right now, but it can be implemented easily :) The rest of the code (the graph, marking child nodes as failed) already exists.