Skip to content

TAIT shouldn't constrain impl generics #108425

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