Skip to content

negative impls cause problems with type inference #74383

Closed
@lcnr

Description

@lcnr
Contributor
#![feature(negative_impls)]

struct Foo<T>(T);

impl !Send for Foo<()> {}

fn test<T>() -> T where Foo<T>: Send { todo!() }

fn main() {
    let _: u8 = test();
}

Fails with

error[E0277]: `Foo<_>` cannot be sent between threads safely
  --> $DIR/fk.rs:10:17
   |
LL | fn test<T>() -> T where Foo<T>: Send { todo!() }
   |                                 ---- required by this bound in `test`
...
LL |     let _: u8 = test();
   |                 ^^^^ `Foo<_>` cannot be sent between threads safely
   |
   = help: the trait `std::marker::Send` is not implemented for `Foo<_>`

Explicitly specifying test::<u8>() works though.

Activity

added
C-bugCategory: This is a bug.
requires-nightlyThis issue requires a nightly compiler in some way.
on Jul 15, 2020
eddyb

eddyb commented on Jul 15, 2020

@eddyb
Member

cc @nikomatsakis @matthewjasper (I suspect this might actually be expected, but I'm not sure)

lcnr

lcnr commented on Jul 16, 2020

@lcnr
ContributorAuthor

Treat negative impls as unimplemented, and reservation impls as ambiguity.

Seems like this is caused by a mixture of

// Auto implementations have lower priority, so we only
// consider triggering a default if there is no other impl that can apply.
if candidates.vec.is_empty() {
self.assemble_candidates_from_auto_impls(obligation, &mut candidates)?;
}

and
// Treat negative impls as unimplemented, and reservation impls as ambiguity.
fn filter_negative_and_reservation_impls(
&mut self,
candidate: SelectionCandidate<'tcx>,
) -> SelectionResult<'tcx, SelectionCandidate<'tcx>> {

We might be able to deal with this by also updating candidate_should_be_dropped_in_favor_of.
Let's see if the current behavior is expected before looking deeper into this.

nikomatsakis

nikomatsakis commented on Jul 16, 2020

@nikomatsakis
Contributor

Hmm I don't think this is expected, though I still don't quite understand how it happens.

lcnr

lcnr commented on Jul 21, 2020

@lcnr
ContributorAuthor

closing as intended behavior, see #74525 (comment) for more details

It looks to me like preventing the impl for Foo<()> is directly tracked in #13231.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-inferenceArea: Type inferenceC-bugCategory: This is a bug.F-negative_impls#![feature(negative_impls)]requires-nightlyThis issue requires a nightly compiler in some way.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @eddyb@nikomatsakis@lcnr

      Issue actions

        negative impls cause problems with type inference · Issue #74383 · rust-lang/rust