-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
&'a T
→ &'static T
in safe code
#118876
Labels
A-lifetimes
Area: Lifetimes / regions
A-NLL
Area: Non-lexical lifetimes (NLL)
C-bug
Category: This is a bug.
I-unsound
Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness
NLL-sound
Working towards the "invalid code does not compile" goal
P-high
High priority
regression-from-stable-to-stable
Performance or correctness regression from one stable version to another.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-types
Relevant to the types team, which will review and decide on the PR/issue.
Comments
Hmm… maybe this is just a duplicate of #114936? |
I went ahead and implemented the "hacky" fix in #114936 (comment): #118882 |
Looks like an NLL regression. The following invalid example compiles in v1.63.0, where NLL is enabled by default: fn extend(s: &str, f: fn(&str) -> &'static &'_ ()) {
f(s);
} |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Dec 13, 2023
…=<try> Check normalized call signature for WF in mir typeck Unfortunately we don't check that the built-in implementations for `Fn*` traits are actually well-formed in the same way that we do for user-provided impls. Essentially, when checking a call terminator, we end up with a signature that references an unnormalized `<[closure] as FnOnce<...>>::Output` in its output. That output type, due to the built-in impl, doesn't follow the expected rule that `WF(ty)` implies `WF(normalized(ty))`. We fix this by also checking the normalized signature here. **See** boxy's detailed and useful explanation comment which explains this in more detail: rust-lang#114936 (comment) Fixes rust-lang#114936 Fixes rust-lang#118876 r? types cc `@BoxyUwU` `@lcnr`
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-high |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jan 22, 2024
…=<try> Check normalized call signature for WF in mir typeck Unfortunately we don't check that the built-in implementations for `Fn*` traits are actually well-formed in the same way that we do for user-provided impls. Essentially, when checking a call terminator, we end up with a signature that references an unnormalized `<[closure] as FnOnce<...>>::Output` in its output. That output type, due to the built-in impl, doesn't follow the expected rule that `WF(ty)` implies `WF(normalized(ty))`. We fix this by also checking the normalized signature here. **See** boxy's detailed and useful explanation comment which explains this in more detail: rust-lang#114936 (comment) Fixes rust-lang#114936 Fixes rust-lang#118876 r? types cc `@BoxyUwU` `@lcnr`
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jan 22, 2024
…=<try> Check normalized call signature for WF in mir typeck Unfortunately we don't check that the built-in implementations for `Fn*` traits are actually well-formed in the same way that we do for user-provided impls. Essentially, when checking a call terminator, we end up with a signature that references an unnormalized `<[closure] as FnOnce<...>>::Output` in its output. That output type, due to the built-in impl, doesn't follow the expected rule that `WF(ty)` implies `WF(normalized(ty))`. We fix this by also checking the normalized signature here. **See** boxy's detailed and useful explanation comment which explains this in more detail: rust-lang#114936 (comment) Fixes rust-lang#114936 Fixes rust-lang#118876 r? types cc `@BoxyUwU` `@lcnr`
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Feb 13, 2024
… r=lcnr Check normalized call signature for WF in mir typeck Unfortunately we don't check that the built-in implementations for `Fn*` traits are actually well-formed in the same way that we do for user-provided impls. Essentially, when checking a call terminator, we end up with a signature that references an unnormalized `<[closure] as FnOnce<...>>::Output` in its output. That output type, due to the built-in impl, doesn't follow the expected rule that `WF(ty)` implies `WF(normalized(ty))`. We fix this by also checking the normalized signature here. **See** boxy's detailed and useful explanation comment which explains this in more detail: rust-lang#114936 (comment) Fixes rust-lang#114936 Fixes rust-lang#118876 r? types cc `@BoxyUwU` `@lcnr`
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Feb 14, 2024
Rollup merge of rust-lang#118882 - compiler-errors:normalized-sig-wf, r=lcnr Check normalized call signature for WF in mir typeck Unfortunately we don't check that the built-in implementations for `Fn*` traits are actually well-formed in the same way that we do for user-provided impls. Essentially, when checking a call terminator, we end up with a signature that references an unnormalized `<[closure] as FnOnce<...>>::Output` in its output. That output type, due to the built-in impl, doesn't follow the expected rule that `WF(ty)` implies `WF(normalized(ty))`. We fix this by also checking the normalized signature here. **See** boxy's detailed and useful explanation comment which explains this in more detail: rust-lang#114936 (comment) Fixes rust-lang#114936 Fixes rust-lang#118876 r? types cc ``@BoxyUwU`` ``@lcnr``
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-lifetimes
Area: Lifetimes / regions
A-NLL
Area: Non-lexical lifetimes (NLL)
C-bug
Category: This is a bug.
I-unsound
Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness
NLL-sound
Working towards the "invalid code does not compile" goal
P-high
High priority
regression-from-stable-to-stable
Performance or correctness regression from one stable version to another.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-types
Relevant to the types team, which will review and decide on the PR/issue.
(Originally found here)
I tried this code:
I expected to see this happen: lifetime error,
'a
is not'static
Instead, this happened: compiles
Meta
Regression in nightly-2022-08-10
found 7 bors merge commits in the specified range
commit[0] 2022-08-08: Auto merge of #98863 - compiler-errors:projection-msg, r=estebank
commit[1] 2022-08-09: Auto merge of #100205 - cjgillot:noice-doc, r=camelid
commit[2] 2022-08-09: Auto merge of #100304 - matthiaskrgr:rollup-gs56vlw, r=matthiaskrgr
commit[3] 2022-08-09: Auto merge of #100089 - JakobDegen:no-invalidate-visitor, r=tmiasko
commit[4] 2022-08-09: Auto merge of #100318 - Dylan-DPC:rollup-18tzp6q, r=Dylan-DPC
commit[5] 2022-08-09: Auto merge of #99217 - lcnr:implied-bounds-pre-norm, r=lcnr
commit[6] 2022-08-09: Auto merge of #100150 - notriddle:notriddle/implementors-js, r=GuillaumeGomez
@rustbot label T-types T-compiler regression-from-stable-to-stable I-unsound A-lifetimes
The text was updated successfully, but these errors were encountered: