-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
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
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
gburgessiv
added a commit
to gburgessiv/rust
that referenced
this issue
Feb 25, 2023
Part of the resolution to rust-lang#105107
GrigorenkoPV
pushed a commit
to GrigorenkoPV/rust
that referenced
this issue
Jun 26, 2024
Part of the resolution to rust-lang#105107
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.
The following UB compiles: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=4cc89e9d4c133a6398f297e6f56e07f2
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:@rustbot label C-bug T-types I-unsound requires-nightly F-type_alias_impl_trait
The text was updated successfully, but these errors were encountered: