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

with_negative_coherence fails to prevent coherence_leak_check overlap error #117986

Closed
Jules-Bertholet opened this issue Nov 16, 2023 · 1 comment · Fixed by #117994
Closed

with_negative_coherence fails to prevent coherence_leak_check overlap error #117986

Jules-Bertholet opened this issue Nov 16, 2023 · 1 comment · Fixed by #117994
Assignees
Labels
A-coherence Area: Coherence C-bug Category: This is a bug. F-negative_impls #![feature(negative_impls)] requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Jules-Bertholet
Copy link
Contributor

Jules-Bertholet commented Nov 16, 2023

I tried this code:

#![forbid(coherence_leak_check)]
#![feature(negative_impls, with_negative_coherence)]

pub trait Marker {}

impl<'a, T: ?Sized> !Marker for &'a T {}

trait FnMarker {}

impl<T: ?Sized + Marker> FnMarker for fn(T) {}
impl<T: ?Sized> FnMarker for fn(&T) {}

I expected to see this happen: Compiles successfully

Instead, this happened:

error: conflicting implementations of trait `FnMarker` for type `fn(&_)`
  --> src/lib.rs:11:1
   |
10 | impl<T: ?Sized + Marker> FnMarker for fn(T) {}
   | ------------------------------------------- first implementation here
11 | impl<T: ?Sized> FnMarker for fn(&T) {}
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `fn(&_)`
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #56105 <https://github.com/rust-lang/rust/issues/56105>
   = note: this behavior recently changed as a result of a bug fix; see rust-lang/rust#56105 for details
note: the lint level is defined here
  --> src/lib.rs:1:11
   |
1  | #![forbid(coherence_leak_check)]
   |           ^^^^^^^^^^^^^^^^^^^^

Meta

rustc --version:

1.76.0-nightly (2023-11-15 6b771f6b5a6c8b03b632)

@rustbot label A-coherence F-negative_impls requires-nightly T-compiler

@Jules-Bertholet Jules-Bertholet added the C-bug Category: This is a bug. label Nov 16, 2023
@rustbot rustbot added needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. A-coherence Area: Coherence F-negative_impls #![feature(negative_impls)] requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 16, 2023
@compiler-errors
Copy link
Member

👀

I'll look into it

@compiler-errors compiler-errors self-assigned this Nov 16, 2023
@compiler-errors compiler-errors removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Nov 16, 2023
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Nov 17, 2023
…-in-coherence, r=lcnr

Ignore but do not assume region obligations from unifying headers in negative coherence

Partly addresses a FIXME that was added in rust-lang#112875. Just as we can throw away the nested trait/projection obligations from unifying two impl headers, we can also just throw away the region obligations too.

I removed part of the FIXME that was incorrect, namely:
> Given that the only region constraints we get are involving inference regions in the root, it shouldn't matter, but still sus.

This is not true when unifying `fn(A)` and `for<'b> fn(&'b B)` which ends up with placeholder region outlives from non-root universes. I'm pretty sure this is okay, though it would be nice if we were to use them as assumptions. See the `explicit` revision of the test I committed, which still fails.

Fixes rust-lang#117986

r? lcnr, feel free to reassign tho.
TaKO8Ki added a commit to TaKO8Ki/rust that referenced this issue Nov 18, 2023
…-in-coherence, r=lcnr

Ignore but do not assume region obligations from unifying headers in negative coherence

Partly addresses a FIXME that was added in rust-lang#112875. Just as we can throw away the nested trait/projection obligations from unifying two impl headers, we can also just throw away the region obligations too.

I removed part of the FIXME that was incorrect, namely:
> Given that the only region constraints we get are involving inference regions in the root, it shouldn't matter, but still sus.

This is not true when unifying `fn(A)` and `for<'b> fn(&'b B)` which ends up with placeholder region outlives from non-root universes. I'm pretty sure this is okay, though it would be nice if we were to use them as assumptions. See the `explicit` revision of the test I committed, which still fails.

Fixes rust-lang#117986

r? lcnr, feel free to reassign tho.
compiler-errors added a commit to compiler-errors/rust that referenced this issue Nov 18, 2023
…-in-coherence, r=lcnr

Ignore but do not assume region obligations from unifying headers in negative coherence

Partly addresses a FIXME that was added in rust-lang#112875. Just as we can throw away the nested trait/projection obligations from unifying two impl headers, we can also just throw away the region obligations too.

I removed part of the FIXME that was incorrect, namely:
> Given that the only region constraints we get are involving inference regions in the root, it shouldn't matter, but still sus.

This is not true when unifying `fn(A)` and `for<'b> fn(&'b B)` which ends up with placeholder region outlives from non-root universes. I'm pretty sure this is okay, though it would be nice if we were to use them as assumptions. See the `explicit` revision of the test I committed, which still fails.

Fixes rust-lang#117986

r? lcnr, feel free to reassign tho.
compiler-errors added a commit to compiler-errors/rust that referenced this issue Nov 20, 2023
…-in-coherence, r=lcnr

Ignore but do not assume region obligations from unifying headers in negative coherence

Partly addresses a FIXME that was added in rust-lang#112875. Just as we can throw away the nested trait/projection obligations from unifying two impl headers, we can also just throw away the region obligations too.

I removed part of the FIXME that was incorrect, namely:
> Given that the only region constraints we get are involving inference regions in the root, it shouldn't matter, but still sus.

This is not true when unifying `fn(A)` and `for<'b> fn(&'b B)` which ends up with placeholder region outlives from non-root universes. I'm pretty sure this is okay, though it would be nice if we were to use them as assumptions. See the `explicit` revision of the test I committed, which still fails.

Fixes rust-lang#117986

r? lcnr, feel free to reassign tho.
@bors bors closed this as completed in 40a781b Nov 20, 2023
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Nov 20, 2023
Rollup merge of rust-lang#117994 - compiler-errors:throw-away-regions-in-coherence, r=lcnr

Ignore but do not assume region obligations from unifying headers in negative coherence

Partly addresses a FIXME that was added in rust-lang#112875. Just as we can throw away the nested trait/projection obligations from unifying two impl headers, we can also just throw away the region obligations too.

I removed part of the FIXME that was incorrect, namely:
> Given that the only region constraints we get are involving inference regions in the root, it shouldn't matter, but still sus.

This is not true when unifying `fn(A)` and `for<'b> fn(&'b B)` which ends up with placeholder region outlives from non-root universes. I'm pretty sure this is okay, though it would be nice if we were to use them as assumptions. See the `explicit` revision of the test I committed, which still fails.

Fixes rust-lang#117986

r? lcnr, feel free to reassign tho.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-coherence Area: Coherence C-bug Category: This is a bug. F-negative_impls #![feature(negative_impls)] requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
3 participants