regression: int_roundings conflicts with existing APIs

[Mark-Simulacrum]

Crater run for 1.56 detected a considerable amount of breakage due to int_roundings on nightly. We have some support in the compiler to avoid stable breakage due to unstable features, but it does not work for this case (@cuviper theorized this is due to "the self inherent method is resolved before the &self trait method is considered at all."

There are:

• 236 regressed crates
• 580 regressed github repositories
• Roughly ~20 roots, but some may be masked by other errors, some examples:
  • https://crater-reports.s3.amazonaws.com/beta-1.56-2/beta-2021-09-12/reg/tract-data-0.15.3/log.txt
  • https://crater-reports.s3.amazonaws.com/beta-1.56-2/beta-2021-09-12/reg/num-integer-0.1.44/log.txt
  • https://crater-reports.s3.amazonaws.com/beta-1.56-2/beta-2021-09-12/reg/symbolic_polynomials-0.1.0/log.txt
  • https://crater-reports.s3.amazonaws.com/beta-1.56-2/beta-2021-09-12/reg/gaia_quadtree-0.1.7/log.txt

This is a level of breakage significant enough that it seems prudent to back this out or rename the functions, to avoid breaking a good portion of the ecosystem.

cc:

• Tracking Issue for int_roundings #88581
• Recent PRs break lots of nightly builds #88878
• https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/possible.20semi-breaking.20change.20in.20next.20release

[cuviper]

This may be a nitpick on what is defined as a root cause, but num-integer itself shouldn't be failing to compile as a dependency. The direct log errors you show are only in its tests, fixed in rust-num/num-integer#44 but not yet published. Other crate errors come from use of its Integer trait, so it is a root cause in that sense, but I can't fix that in num-integer.

[cuviper]

I know it's not a blame game or anything, but I think the distinction matters when considering how many places have to be fixed to deal with this change.

[Mark-Simulacrum]

Yeah, unfortunately, with this scope of breakage the number of root causes may not be terribly important -- many of those need somewhat manual intervention for the .lock bumps, in practice, which can take time.

[joshtriplett]

These are unstable methods, so can we come up with reasonable names to rename them to, knowing that we don't have to commit to those names long-term if we come up with better ones before stabilization?

[joshtriplett]

Conclusion from the libs-api meeting: let's temporarily rename these to something non-conflicting that we know we don't want to use long-term; for instance, let's prefix them with unstable_.

[m-ou-se]

Discussed in the libs-api meeting. We'll rename them for now and beta-backport that.

[m-ou-se]

Race condition.

[joshtriplett]

Long-term fix:

• We should fix the unstable-vs-stable resolution here: if the compiler finds an inherent method that's unstable and not opted into, and we're going to error out anyway, keep going and see if we find a stable method we can use.
• We could potentially do autoderef here, since the type is Copy.

[joshtriplett]

#89184