Skip to content

False negative for "the trait bound K: Ord is not satisfied" #88244

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
cbarrick opened this issue Aug 22, 2021 · 8 comments
Closed

False negative for "the trait bound K: Ord is not satisfied" #88244

cbarrick opened this issue Aug 22, 2021 · 8 comments
Labels
A-associated-items Area: Associated items (types, constants & functions) C-bug Category: This is a bug. F-const_trait_impl `#![feature(const_trait_impl)]` requires-nightly This issue requires a nightly compiler in some way.

Comments

@cbarrick
Copy link
Contributor

I tried this code:

#![feature(const_btree_new)]

use std::collections::BTreeMap;

trait Proto: Ord {
    const DEFAULT: Self;
}

#[derive(Clone, Debug, Eq, Ord, PartialEq, PartialOrd)]
struct Map<K, V>(BTreeMap<K, V>);

impl<K: Proto, V: Proto> Proto for Map<K, V> {
    const DEFAULT: Map<K, V> = Map(BTreeMap::new());
}

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

I expected it to compile.

Instead I get the error:

   Compiling playground v0.0.1 (/playground)
error[E0277]: the trait bound `K: Ord` is not satisfied
   --> src/lib.rs:13:36
    |
13  |     const DEFAULT: Map<K, V> = Map(BTreeMap::new());
    |                                    ^^^^^^^^^^^^^^^
    |                                    |
    |                                    expected an implementor of trait `Ord`
    |                                    help: consider borrowing here: `&BTreeMap::new()`
    |
note: required by `BTreeMap::<K, V>::new`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `playground` due to previous error

It complains that K: Ord is not satisfied.

But K: Proto and Proto: Ord therefore K: Ord.

The code also fails if I explicitly add the K: Ord trait bound to the impl.

Meta

I tried using the most recent nightly on macOS 11.3 (Big Sur) and on the playground.

$ rustc --version --verbose
rustc 1.56.0-nightly (d3e2578c3 2021-08-21)
binary: rustc
commit-hash: d3e2578c31688619ddc0a10ddf8543bf4ebcba5b
commit-date: 2021-08-21
host: x86_64-apple-darwin
release: 1.56.0-nightly
LLVM version: 13.0.0
@cbarrick cbarrick added the C-bug Category: This is a bug. label Aug 22, 2021
@jonas-schievink jonas-schievink added the F-const_trait_impl `#![feature(const_trait_impl)]` label Aug 22, 2021
@cbarrick
Copy link
Contributor Author

I should add that this used to compile. I noticed the error after updating my compiler.

I did not record the old version number, but it was very old. Maybe 1.51 or so.

@steffahn
Copy link
Member

The code example will (most likely) compile again once #88040 is merged. However the underlying issue isn’t addressed; that PR just removes the K: Ord bound from BTreeMap::new entirely.

@steffahn
Copy link
Member

searched nightlies: from nightly-2021-08-14 to nightly-2021-08-22
regressed nightly: nightly-2021-08-15
searched commits: from 5a19ffe to 8007b50
regressed commit: 136eaa1

bisected with cargo-bisect-rustc v0.6.0

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --access github --regress error 

@steffahn
Copy link
Member

@fee1-dead

I’m not sure I quite understand the description of #87375

Is the code in this issue working as intended or is this a bug?

@steffahn
Copy link
Member

Okay, if I understand this correctly, there’s currently a K: Ord and not a K: ?const Ord bound on BTreeMap::new, so this is expected breakage, right? If so, we can close this issue. (Also in this case, it is a BTreeMap-specific issue after all, and #88040 will fix the problem for good.)

@steffahn
Copy link
Member

@rustbot label A-associated-items, requires-nightly

@rustbot rustbot added A-associated-items Area: Associated items (types, constants & functions) requires-nightly This issue requires a nightly compiler in some way. labels Aug 27, 2021
@fee1-dead
Copy link
Member

So #88328 just got merged, and that means instead of inferring bounds on const fns to be const, we now require an opt-in for those bounds. The latest nightly should work again.

@cbarrick
Copy link
Contributor Author

I can confirm this works again in the playground.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-associated-items Area: Associated items (types, constants & functions) C-bug Category: This is a bug. F-const_trait_impl `#![feature(const_trait_impl)]` requires-nightly This issue requires a nightly compiler in some way.
Projects
None yet
Development

No branches or pull requests

5 participants