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

&'a T&'static T in safe code #118876

Closed
Jules-Bertholet opened this issue Dec 12, 2023 · 4 comments · Fixed by #118882
Closed

&'a T&'static T in safe code #118876

Jules-Bertholet opened this issue Dec 12, 2023 · 4 comments · Fixed by #118882
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

@Jules-Bertholet
Copy link
Contributor

Jules-Bertholet commented Dec 12, 2023

(Originally found here)

I tried this code:

fn extend<T>(input: &T) -> &'static T {
    struct Bounded<'a, 'b: 'static, T>(&'a T, [&'b (); 0]);
    let n: Box<dyn FnOnce(&T) -> Bounded<'static, '_, T>> = Box::new(|x| Bounded(x, []));
    n(input).0
}

fn extend_mut<'a, T>(input: &'a mut T) -> &'static mut T {
    struct Bounded<'a, 'b: 'static, T>(&'a mut T, [&'b (); 0]);
    let mut n: Box<dyn FnMut(&mut T) -> Bounded<'static, '_, T>> = Box::new(|x| Bounded(x, []));
    n(input).0
}

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

@Jules-Bertholet Jules-Bertholet added the C-bug Category: This is a bug. label Dec 12, 2023
@rustbot rustbot added needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. A-lifetimes Area: Lifetimes / regions I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-types Relevant to the types team, which will review and decide on the PR/issue. I-prioritize Issue: Indicates that prioritization has been requested for this issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 12, 2023
@Jules-Bertholet
Copy link
Contributor Author

Hmm… maybe this is just a duplicate of #114936?

@aliemjay aliemjay added NLL-sound Working towards the "invalid code does not compile" goal A-NLL Area: Non-lexical lifetimes (NLL) and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Dec 12, 2023
@compiler-errors
Copy link
Member

compiler-errors commented Dec 12, 2023

I went ahead and implemented the "hacky" fix in #114936 (comment): #118882

@aliemjay
Copy link
Member

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`
@apiraino
Copy link
Contributor

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

@rustbot rustbot added P-high High priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Dec 18, 2023
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`
@bors bors closed this as completed in db9591c Feb 14, 2024
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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants