Type inference regression and ICE in nightly 2020-10-06

[mattico]

I tried this code:

FluenTech/embedded-time@521569d

I expected to see this happen:

Successful compilation. This works with stable, and nightly 2020-10-05.

Instead, this happened:

https://github.com/FluenTech/embedded-time/pull/77/checks?check_run_id=1218050695

error[E0284]: type annotations needed: cannot satisfy `<<Clock as Clock>::T as Div<_>>::Output == <Clock as Clock>::T`
Error:    --> src/instant.rs:183:66
    |
183 |         if add_ticks <= (<Clock::T as num::Bounded>::max_value() / 2.into()) {
    |                                                                  ^ cannot satisfy `<<Clock as Clock>::T as Div<_>>::Output == <Clock as Clock>::T`

Meta

rustc --version --verbose:

rustc 1.49.0-nightly (98edd1fbf 2020-10-06)
binary: rustc
commit-hash: 98edd1fbf8a68977a2a7c1312eb1ebff80515a92
commit-date: 2020-10-06
host: x86_64-pc-windows-msvc
release: 1.49.0-nightly
LLVM version: 11.0

[mattico]

#73905 looks suspicious?

[mattico]

Minimal repro: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=55f8795c91867fec5550107d789a60f8

(at time of writing the playground does not have the affected nightly yet)

[tesuji]

Yeah, bisecting it's indeed 08e2d46 or #73905 .
However, that PR is a significant improvement that we may don't want to revert.
But I will cc @matthewjasper for their information.

[mstallmo]

Assigning P-critical as discussed as part of the Prioritization Working Group procedure and removing I-prioritize

[gnunicorn]

(at time of writing the playground does not have the affected nightly yet)

that playground link now fails with the error described above.

[bkchr]

Hey, so I tried porting our code to compile with latest nightly and I almost got it working but ultimately it ended with an internal compiler error:

error: internal compiler error: compiler/rustc_trait_selection/src/traits/codegen/mod.rs:121:9: Encountered errors `[FulfillmentError(Obligation(predicate=TraitPredicate(<dyn sc_client_api::PrunableStateChangesTrieStorage<sp_runtime::generic::Block<sp_runtime::generic::Header<u32, sp_runtime::traits::BlakeTwo256>, sp_runtime::OpaqueExtrinsic>> as sp_state_machine::changes_trie::Storage<sp_runtime::traits::BlakeTwo256, u32>>), depth=0),Unimplemented)]` resolving bounds after type-checking

thread 'rustc' panicked at 'Box<Any>', compiler/rustc_errors/src/lib.rs:945:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.49.0-nightly (98edd1fbf 2020-10-06) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type lib

note: some of the compiler flags provided by cargo are hidden

error: aborting due to previous error

error: could not compile `node-testing`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

I created a branch that fails with this or a similar ICE when you run cargo test --all. You can find it here: https://github.com/paritytech/substrate/tree/bkchr-fix-for-latest-nightly

[tarcieri]

I'm curious if this issue is related to a type inference regression we're experiencing on nightly-2020-10-06 which was NOT present on nightly-2020-10-05:

cometbft/tendermint-rs#584 (comment)

Our particular problem can be reproduced with:

$ git clone https://github.com/RustCrypto/signatures.git
$ cd signatures/ecdsa
$ cargo build --all-features

On nightly-2020-10-05, it compiles. On nightly-2020-10-06, we get:

error[E0277]: cannot multiply `&elliptic_curve::scalar::NonZeroScalar<C>` to `<C as ProjectiveArithmetic>::ProjectivePoint`
  --> ecdsa/src/sign.rs:90:58
   |
90 |             public_key: (C::ProjectivePoint::generator() * &self.secret_scalar).to_affine(),
   |                                                          ^ no implementation for `<C as ProjectiveArithmetic>::ProjectivePoint * &elliptic_curve::scalar::NonZeroScalar<C>`
   |
   = help: the trait `Mul<&elliptic_curve::scalar::NonZeroScalar<C>>` is not implemented for `<C as ProjectiveArithmetic>::ProjectivePoint`

Note that NonZeroScalar<C> has a Deref impl with a target type that has the Mul impl. If we explicitly deref the value with *value, the code compiles.

[lqd]

This might be related: both embedded-time and some Parity crates did appear in the crater run for that PR in the crates with "Ambiguous projection bounds" section

[mattico]

@lqd that crater report is great, thanks.

I figured that the type inference changes might be an intentional bugfix, I'll try to fix embedded-time.

[mattico]

Can someone help me understand this? This fixed the problem:

    pub fn checked_add<Dur: Duration>(self, duration: Dur) -> Option<Self>
    where
        Dur: FixedPoint,
-        Clock::T: TryFrom<Dur::T>
+        Clock::T: TryFrom<Dur::T> + ops::Div<Output=Clock::T>

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=55f8795c91867fec5550107d789a60f8

But that bound seems redundant because Clock::T: TimeInt and TimeInt: ops::Div<Output = Self>. Is the Self just any TimeInt and not necessarily the specific type?

[lqd]

Reduced the playground above to remove the dependency on num:

use core::ops::Div;

trait CheckedDiv: Sized + Div<Self, Output = Self> {}

trait Bounded {
    fn max_value() -> Self;
}

struct Fraction;

trait TimeInt: Bounded + CheckedDiv + Div<Fraction, Output = Self> {}
trait Clock {
    type T: TimeInt;
}

trait FixedPoint {
    type T: TimeInt;
}
struct Instant<Clock: crate::Clock> {
    ticks: Clock::T,
}
impl<Clock: crate::Clock> Instant<Clock> {
    pub fn checked_add<Dur: FixedPoint>(self, duration: Dur) {
        let _ = <Clock::T as Bounded>::max_value() / 2.into();
    }
}

playground

(It could probably be reduced further to a MCVE mostly involving the two Div bounds, but at least this is closer to the OP's repro)

[iliekturtles]

I believe uom ran into a similar issue introduced by the same PR noted here (reported at iliekturtles/uom#210, error first occurs in nightly-2020-10-07, rustc 1.49.0-nightly (98edd1fbf 2020-10-06)). See the following playground. The example works on stable and beta but fails on nightly unless line 14 is uncommented.

[matthewjasper]

The uom issue is fallout from fixing #27675

The really minimal example of this is

use std::ops::Add;

trait A {
    type U: Add<i64> + Add<u64>;
}

fn f<T: A>(t: T::U) {
    let x = t + Default::default();
}

on stable the compiler will arbitrarily decide to use the Add<u64> impl for +. Some of the changes from #73905 meant that there wasn't a good way to keep this behaviour, so this is now reported as ambiguous (which it is).

[tavianator]

@matthewjasper Oh awesome, that means you fixed #72582 (and a few of its duplicates). Should I add a regression test?

[matthewjasper]

There should already be some tests in #73905, if you can find anything not covered by the tests added there then please add some.

[tavianator]

Looks like https://github.com/rust-lang/rust/pull/73905/files#diff-9930232eb2ce0b857a7afb6bc22d8fc8 should cover it. Thanks!

[Aaron1011]

Can this issue be closed?

[mattico]

@Aaron1011 Since it seems that these regressions were already known about when #73905 was merged, I suppose they were intentional. Additionally, @matthewjasper saw this and hasn't said anything to the effect of these being issues that need to be fixed so I'm going to close.