I’m not sure when I’ll triage this myself, but here’s some results to look at. If somebody else wants to triage and post bugs, the process is written down here.
cookie-0.6.2 is caused by note: #[deny(unused_macros)] implied by #[deny(warnings)]
How many are affected by that? I’d love to rg the results files for the regression, is there an easy way to do that?
ttf-noto-sans is caused by the following errors in petgraph:
error[E0034]: multiple applicable items in scope
--> /Users/jdm/.cargo/registry/src/github.com-1ecc6299db9ec823/petgraph-0.2.9/src/graph.rs:421:17
|
421 | assert!(Ix::max().index() == !0 || NodeIndex::end() != node_idx);
| ^^^^^^^ multiple `max` found
|
note: candidate #1 is defined in the trait `graph::IndexType`
--> /Users/jdm/.cargo/registry/src/github.com-1ecc6299db9ec823/petgraph-0.2.9/src/graph.rs:31:5
|
31 | fn max() -> Self;
| ^^^^^^^^^^^^^^^^^
= help: to disambiguate the method call, write `graph::IndexType::max(...)` instead
note: candidate #2 is defined in the trait `std::cmp::Ord`
= help: to disambiguate the method call, write `std::cmp::Ord::max(...)` instead
error[E0034]: multiple applicable items in scope
--> /Users/jdm/.cargo/registry/src/github.com-1ecc6299db9ec823/petgraph-0.2.9/src/graph.rs:458:17
|
458 | assert!(Ix::max().index() == !0 || EdgeIndex::end() != edge_idx);
| ^^^^^^^ multiple `max` found
|
note: candidate #1 is defined in the trait `graph::IndexType`
--> /Users/jdm/.cargo/registry/src/github.com-1ecc6299db9ec823/petgraph-0.2.9/src/graph.rs:31:5
|
31 | fn max() -> Self;
| ^^^^^^^^^^^^^^^^^
= help: to disambiguate the method call, write `graph::IndexType::max(...)` instead
note: candidate #2 is defined in the trait `std::cmp::Ord`
= help: to disambiguate the method call, write `std::cmp::Ord::max(...)` instead
Since petgraph has 23 dependent crates, this suggests that this may be a significant source of the regressions. This has already been fixed in the most recent release of petgraph: https://github.com/bluss/petgraph/pull/154
The euclid failure is a manifestation of https://github.com/servo/heapsize/issues/82 - cargobomb is building euclid 0.11.3, which uses an old version of heapsize. euclid’s master tests fine; how are versions for cargobomb chosen? This is the same reason for the heapsize failure.
hashconsing failure only occurs when building an old version (0.3.0); the most recent release does not display that problem and contains commits with names like “fixed extremely stupid problem” and “fixed serious problems”. It’s also in the blacklist for “flakiness”.
It picks the most recent version and, in cases where they aren't the same, the most dependend-on version. So I imagine that's a popular revision of euclid and the most recent is in the green tab.