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

TAIT shouldn't constrain impl generics #108425

Closed
aliemjay opened this issue Feb 24, 2023 · 0 comments · Fixed by #114742
Closed

TAIT shouldn't constrain impl generics #108425

aliemjay opened this issue Feb 24, 2023 · 0 comments · Fixed by #114742
Assignees
Labels
C-bug Category: This is a bug. F-type_alias_impl_trait `#[feature(type_alias_impl_trait)]` I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness requires-nightly This issue requires a nightly compiler in some way. T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@aliemjay
Copy link
Member

aliemjay commented Feb 24, 2023

The following UB compiles: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=4cc89e9d4c133a6398f297e6f56e07f2

#![feature(type_alias_impl_trait)]
use core::fmt::Display;

type Opaque<'a> = impl Sized + 'static;
fn define<'a>() -> Opaque<'a> {}

trait Trait {
    type Assoc: Display;
}
impl<'a> Trait for Opaque<'a> {
    type Assoc = &'a str;
}

// ======= Exploit =======

fn extend<T: Trait + 'static>(s: T::Assoc) -> Box<dyn Display> {
    Box::new(s)
}

fn main() {
    let val = extend::<Opaque<'_>>(&String::from("blah blah blah"));
    println!("{}", val);
}

The impl is invalid because the lifetime parameter 'a appears unconstrained in the impl header. It should be rejected for the same reason that projection types doesn't constraint impl generics:

impl<'a> Trait for <Opaque<'a> as Trait>::Assoc {
//~^ ERROR the lifetime parameter `'a` is not constrained
    type Assoc = &'a str;
}

@rustbot label C-bug T-types I-unsound requires-nightly F-type_alias_impl_trait

@rustbot rustbot added C-bug Category: This is a bug. F-type_alias_impl_trait `#[feature(type_alias_impl_trait)]` I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness requires-nightly This issue requires a nightly compiler in some way. T-types Relevant to the types team, which will review and decide on the PR/issue. labels Feb 24, 2023
@oli-obk oli-obk self-assigned this Feb 24, 2023
gburgessiv added a commit to gburgessiv/rust that referenced this issue Feb 25, 2023
@bors bors closed this as completed in e81522a Aug 14, 2023
GrigorenkoPV pushed a commit to GrigorenkoPV/rust that referenced this issue Jun 26, 2024
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 16, 2024
Add a test for rust-lang#107975

The int is zero. But also not zero. This is so much fun.

This is a part of rust-lang#105107.

Initially I was going to just rebase rust-lang#108445, but quite a few things changed since then:
* The [mcve](rust-lang#105787 (comment)) used for rust-lang#105787 got fixed.[^upd2]
* You can't just `a ?= b` for rust-lang#107975 anymore. Now you have to `a-b ?= 0`. This is what this PR does. As an additional flex, it show that three ways of converting a pointer to its address have this issue:
  1. `as usize`
  2. `.expose_provenance()`
  3. `.addr()`
* rust-lang#108425 simply got fixed. Yay.

As an aside, the naming for `addr_of!` is quite unfortunate in context of provenance APIs. Because `addr_of!` gives you a pointer, but what provenance APIs refer to as "address" is the `usize` value. Oh well.

UPD1: GitHub is incapable of parsing rust-lang#107975 in the PR name, so let's add it here.

[^upd2]: UPD2: [The other mcve](rust-lang#105787 (comment)) does not work anymore either, saying "this behavior recently changed as a result of a bug fix; see rust-lang#56105 for details."
tgross35 added a commit to tgross35/rust that referenced this issue Jul 17, 2024
Add a test for rust-lang#107975

The int is zero. But also not zero. This is so much fun.

This is a part of rust-lang#105107.

Initially I was going to just rebase rust-lang#108445, but quite a few things changed since then:
* The [mcve](rust-lang#105787 (comment)) used for rust-lang#105787 got fixed.[^upd2]
* You can't just `a ?= b` for rust-lang#107975 anymore. Now you have to `a-b ?= 0`. This is what this PR does. As an additional flex, it show that three ways of converting a pointer to its address have this issue:
  1. `as usize`
  2. `.expose_provenance()`
  3. `.addr()`
* rust-lang#108425 simply got fixed. Yay.

As an aside, the naming for `addr_of!` is quite unfortunate in context of provenance APIs. Because `addr_of!` gives you a pointer, but what provenance APIs refer to as "address" is the `usize` value. Oh well.

UPD1: GitHub is incapable of parsing rust-lang#107975 in the PR name, so let's add it here.

[^upd2]: UPD2: [The other mcve](rust-lang#105787 (comment)) does not work anymore either, saying "this behavior recently changed as a result of a bug fix; see rust-lang#56105 for details."
tgross35 added a commit to tgross35/rust that referenced this issue Jul 17, 2024
Add a test for rust-lang#107975

The int is zero. But also not zero. This is so much fun.

This is a part of rust-lang#105107.

Initially I was going to just rebase rust-lang#108445, but quite a few things changed since then:
* The [mcve](rust-lang#105787 (comment)) used for rust-lang#105787 got fixed.[^upd2]
* You can't just `a ?= b` for rust-lang#107975 anymore. Now you have to `a-b ?= 0`. This is what this PR does. As an additional flex, it show that three ways of converting a pointer to its address have this issue:
  1. `as usize`
  2. `.expose_provenance()`
  3. `.addr()`
* rust-lang#108425 simply got fixed. Yay.

As an aside, the naming for `addr_of!` is quite unfortunate in context of provenance APIs. Because `addr_of!` gives you a pointer, but what provenance APIs refer to as "address" is the `usize` value. Oh well.

UPD1: GitHub is incapable of parsing rust-lang#107975 in the PR name, so let's add it here.

[^upd2]: UPD2: [The other mcve](rust-lang#105787 (comment)) does not work anymore either, saying "this behavior recently changed as a result of a bug fix; see rust-lang#56105 for details."
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 17, 2024
Add a test for rust-lang#107975

The int is zero. But also not zero. This is so much fun.

This is a part of rust-lang#105107.

Initially I was going to just rebase rust-lang#108445, but quite a few things changed since then:
* The [mcve](rust-lang#105787 (comment)) used for rust-lang#105787 got fixed.[^upd2]
* You can't just `a ?= b` for rust-lang#107975 anymore. Now you have to `a-b ?= 0`. This is what this PR does. As an additional flex, it show that three ways of converting a pointer to its address have this issue:
  1. `as usize`
  2. `.expose_provenance()`
  3. `.addr()`
* rust-lang#108425 simply got fixed. Yay.

As an aside, the naming for `addr_of!` is quite unfortunate in context of provenance APIs. Because `addr_of!` gives you a pointer, but what provenance APIs refer to as "address" is the `usize` value. Oh well.

UPD1: GitHub is incapable of parsing rust-lang#107975 in the PR name, so let's add it here.

[^upd2]: UPD2: [The other mcve](rust-lang#105787 (comment)) does not work anymore either, saying "this behavior recently changed as a result of a bug fix; see rust-lang#56105 for details."
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 18, 2024
Add a test for rust-lang#107975

The int is zero. But also not zero. This is so much fun.

This is a part of rust-lang#105107.

Initially I was going to just rebase rust-lang#108445, but quite a few things changed since then:
* The [mcve](rust-lang#105787 (comment)) used for rust-lang#105787 got fixed.[^upd2]
* You can't just `a ?= b` for rust-lang#107975 anymore. Now you have to `a-b ?= 0`. This is what this PR does. As an additional flex, it show that three ways of converting a pointer to its address have this issue:
  1. `as usize`
  2. `.expose_provenance()`
  3. `.addr()`
* rust-lang#108425 simply got fixed. Yay.

As an aside, the naming for `addr_of!` is quite unfortunate in context of provenance APIs. Because `addr_of!` gives you a pointer, but what provenance APIs refer to as "address" is the `usize` value. Oh well.

UPD1: GitHub is incapable of parsing rust-lang#107975 in the PR name, so let's add it here.

[^upd2]: UPD2: [The other mcve](rust-lang#105787 (comment)) does not work anymore either, saying "this behavior recently changed as a result of a bug fix; see rust-lang#56105 for details."
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 18, 2024
Add a test for rust-lang#107975

The int is zero. But also not zero. This is so much fun.

This is a part of rust-lang#105107.

Initially I was going to just rebase rust-lang#108445, but quite a few things changed since then:
* The [mcve](rust-lang#105787 (comment)) used for rust-lang#105787 got fixed.[^upd2]
* You can't just `a ?= b` for rust-lang#107975 anymore. Now you have to `a-b ?= 0`. This is what this PR does. As an additional flex, it show that three ways of converting a pointer to its address have this issue:
  1. `as usize`
  2. `.expose_provenance()`
  3. `.addr()`
* rust-lang#108425 simply got fixed. Yay.

As an aside, the naming for `addr_of!` is quite unfortunate in context of provenance APIs. Because `addr_of!` gives you a pointer, but what provenance APIs refer to as "address" is the `usize` value. Oh well.

UPD1: GitHub is incapable of parsing rust-lang#107975 in the PR name, so let's add it here.

[^upd2]: UPD2: [The other mcve](rust-lang#105787 (comment)) does not work anymore either, saying "this behavior recently changed as a result of a bug fix; see rust-lang#56105 for details."
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 20, 2024
Add a test for rust-lang#107975

The int is zero. But also not zero. This is so much fun.

This is a part of rust-lang#105107.

Initially I was going to just rebase rust-lang#108445, but quite a few things changed since then:
* The [mcve](rust-lang#105787 (comment)) used for rust-lang#105787 got fixed.[^upd2]
* You can't just `a ?= b` for rust-lang#107975 anymore. Now you have to `a-b ?= 0`. This is what this PR does. As an additional flex, it show that three ways of converting a pointer to its address have this issue:
  1. `as usize`
  2. `.expose_provenance()`
  3. `.addr()`
* rust-lang#108425 simply got fixed. Yay.

As an aside, the naming for `addr_of!` is quite unfortunate in context of provenance APIs. Because `addr_of!` gives you a pointer, but what provenance APIs refer to as "address" is the `usize` value. Oh well.

UPD1: GitHub is incapable of parsing rust-lang#107975 in the PR name, so let's add it here.

[^upd2]: UPD2: [The other mcve](rust-lang#105787 (comment)) does not work anymore either, saying "this behavior recently changed as a result of a bug fix; see rust-lang#56105 for details."
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. F-type_alias_impl_trait `#[feature(type_alias_impl_trait)]` I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness requires-nightly This issue requires a nightly compiler in some way. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants