Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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